Decision architecture
We map the decisions, logic, authority, and operating context the system must understand.
Decision architecture
We start with how
the operation
decides.
We turn operational knowledge, rules, and human judgment into agentic AI systems that improve decisions across complex organizations.
Airlines Logistics Industrial operations Finance Complex services
Who decides · an airline example
How to read thisEach square is a decision, placed by its consequence and the system’s confidence. The lines mark who may decide. Switch between Normal operations and Disruption to watch authority move.
How we do it
One system, three disciplines.
Most AI work splits these across separate teams and separate engagements. We hold them together, because each is only as good as the other two.
Research & decision science
We establish the evidence base, analyze operational data, test assumptions, and define how performance will be measured.
AI engineering
We turn the architecture into working systems, with the controls, integrations, and human oversight required for real operations.
The premise
The model is not the system.
A powerful model still does not know how your operation works. It does not inherently know which objective wins when goals conflict, which constraint cannot bend, when a routine case becomes an exception, or when uncertainty is high enough to stop.
01
Operational reasoning
How changing conditions become governed decisions and actions over time.
02
Ontology
How the system represents the entities, relationships, states, constraints, and sources that define the operating world.
03
Logic mapping
Which decisions belong to deterministic rules, probabilistic models, optimization, or human judgment.
04
Decision rights
What an agent may inform, recommend, draft, execute in bounds, escalate, or refuse.
05
Human authority
How accountability, review, override, escalation, and governance remain real rather than ceremonial.
Agentic AI becomes operational when the organization can make its own reasoning explicit enough for machines to participate in it.
The architecture
Make the operation legible.
The work is not to automate every decision. It is to represent the operating world well enough to assign each part of the decision to the right form of intelligence, then bound that intelligence with explicit authority.
Operating reality
EventsAssetsPeopleCustomersStateConstraints
Representation
EntitiesRelationshipsAuthoritative sourcesProvenance
Reasoning
RulesOptimizationModelsHuman judgment
Decision rights
InformRecommendDraftExecute in boundsEscalateRefuse
Governed action
OperatorAgentManagerControl systemExternal system
The forms of intelligence each decision is assigned to
Where the system hands the decision back to a person
→Built in order: each step depends on the one before
Decision architecture in motion
Same architecture. Different operation.
Change the operating world or the character of the situation. The architecture does not force autonomy. It changes what the system is permitted to do.
Illustrative reasoning pattern · not a production system
Airline operations
Change the situation
Where we enter
Situations that bring us in.
Most agentic initiatives stall at the same ceiling, for the same five reasons. The model is rarely one of them.
Hover or tap a number to see where it sits on the curve.
- 1An agentic initiative has stalled between prototype and operations.
- 2Critical operating logic still lives inside experienced people.
- 3Multiple systems see pieces of the problem, but none sees the decision.
- 4An AI system needs permission to act, but nobody has clearly defined its authority.
- 5Leadership wants greater autonomy without surrendering control.
How the work unfolds
From tacit judgment to buildable system.
We begin with the operating decision, not a preferred model or platform. The output is a working architecture that product and engineering teams can build, test, govern, and improve.
01
Discovery
Understand the operation
Surface the outcomes, people, systems, information, rules, workarounds, handoffs, and exceptions through which the work actually gets done — and where it currently fails.
02
Discovery
Model the decisions
Define the decisions that drive the outcome and the ontology they depend on. Separate hard rules from model judgment and optimization, and assign decision rights by consequence, reversibility, and confidence.
03
Discovery
Establish the evidence
Analyze operational data, test the assumptions the design rests on, and set the baselines and measures the system will be judged against.
04
First build
Build the system
Turn the architecture into working software: agent roles, orchestration, integrations, interfaces, human review, escalation, controls, and evidence trails. We build it with our engineers, yours, or a partner’s.
05
Ongoing
Evaluate performance
Test against known and adversarial cases, measure outcomes against the baseline, and revise the architecture as the operation changes.
Where this matters
Operations where the whole matters more than the task.
The strongest use cases sit where decisions cross systems, functions, time horizons, and competing objectives. That is where simple automation stops being enough.
01
Airlines
Network decisions where aircraft, crews, passengers, maintenance, gates, weather, regulation, and downstream schedules interact.
Disruption recovery · reaccommodation · crew legality · maintenance tradeoffs · network control
02
Logistics
Decisions across routes, inventory, capacity, carriers, service commitments, exceptions, and network economics.
Rerouting · capacity allocation · exception management · service recovery · control towers
03
Industrial operations
Environments where production, quality, maintenance, safety, throughput, and supply constraints compete in real time.
Production recovery · maintenance prioritization · quality holds · scheduling · resource allocation
04
Energy, telecom & infrastructure
High-consequence systems that must balance continuity, safety, field conditions, regulation, and constrained assets.
Outage response · field operations · production and maintenance planning · network restoration · reliability
05
Financial operations
Decision environments shaped by policy, risk limits, evidence quality, exceptions, auditability, and approval authority.
Underwriting support · exception routing · fraud operations · servicing · compliance workflows
06
Complex services
Operations where expert judgment, fragmented information, regulation, and customer consequence make rigid workflows inadequate.
Case operations · field service · claims · regulated service delivery · professional workflows
The team
Operational thinking, carried through to the product.
We bring decision architecture, research and decision science, and AI engineering together in one engagement, with a bench of specialists (researchers, data analysts and senior AI engineers) assembled around each problem, so the same operating logic carries from discovery through evidence, build, and evaluation.
Every engagement centers on the problem agentic AI now faces: decisions made across incomplete information, competing objectives, and real operational consequence.
Decision architectureOperating model, ontology, logic mapping, decision rights, governance.
Research & decision scienceEvidence base, operational data analysis, assumption testing, performance measurement.
AI engineeringAgents, orchestration, retrieval, integrations, interfaces, controls, evaluation, and delivery from pilot to scale.
Selected thinking
Ideas behind the work.
Our point of view is public. The resources below explain the architecture, the reasoning method, and the questions we use to determine whether an AI initiative is ready to become an operating system.
Primer
AI System Design
Organizing intelligence around operational reasoning, ontology, logic mapping, decision rights, and human authority.
Read the primer↗First step
The Minimum Viable Pilot
Start with the decision, not the model: why the narrowest set of related decisions is the fastest route from pilot to operations.
Read the essay↗Diagnostic
Is there a system around the model?
A structured diagnostic for testing whether an AI initiative has the representation, logic, authority, and controls required for real work.
Run the diagnostic↗Bring us a decision that matters.
A disrupted network. A constrained resource. A cross-functional exception. A judgment that still lives in experienced people. If AI is going to participate in the decision, we should design the architecture around it first.
How an engagement starts. Every engagement begins with Discovery, on one decision set: a single decision, or a few closely related ones. We size the first phase to the problem, agree what success, adjustment and stopping look like before we begin, and report on evidence, not promises. How we scope a first engagement →
Start a conversation ↗