A difficult investigation should make the next one easier. OODAL is the architecture I'm exploring for an AI-native organization to do that. It uses a shared graph of experience and fast, bounded decision models to handle familiar situations, bringing in slower reasoning or a human when the evidence isn't enough. The runtime controls the process, policies gate actions, and people review proposed learning before it changes the organization's knowledge. The aim is to make hard-won judgment reusable, so routine decisions become cheaper and faster while unfamiliar problems still get the attention they need.
A common agent design pairs a large language model with tools and keeps calling the model until it decides it's done.
That puts a lot of responsibility into each model call. The model has to notice what matters, retrieve relevant knowledge, propose options, judge them, and act. When something goes wrong, the transcript may show the choice without giving us a reliable account of how it was made. Learning from the result is often left to a separate process, if it happens at all.
In an organization, those responsibilities are usually spread across people and processes. A support team investigates a complaint, engineering chooses a fix, and someone checks whether the customer is still having trouble. What the organization retains from that experience determines how well it handles the next complaint.
I've been thinking about what an AI-native organization would look like. How would it respond to a problem, and what would it learn from the result? That seems fundamental, so I started breaking the process into responsibilities that software could handle. OODAL is a useful shorthand:
Observe -> Orient -> Decide -> Act -> Learn
It builds on John Boyd's OODA loop: Observe, Orient, Decide, Act. OODAL adds an explicit Learn step that observes the outcome of an action and uses the experience to improve future orientation. Boyd's loop already incorporates feedback; I'm giving learning a defined responsibility in the software.
I didn't coin OODAL. Shelli Friess, James A. Crowder, and Michael Hirsch explicitly use the acronym in their 2021 SANDI chapter, which develops an artificial cognitive architecture using nervous and limbic system concepts. A separate 2021 study by Zou, Zhang, and Bai uses the related notation OODA-L, making learning explicit in a framework for autonomous swarm simulation.
Those are earlier applications of the learning loop, not the same organizational design. My emphasis is on how an organization can share what it learns across functions and decide when to spend more effort on a problem. A graph holds its experience. A bounded decision model judges the possibilities recall retrieves, while a generative model proposes new ones when needed. Human escalation and reviewed updates to the graph are part of the workflow. The goal is for each investigation to leave behind knowledge that makes a similar situation easier to handle.
The loop
Each step has a distinct responsibility:
- Observe - record a change or a new observation.
- Orient - identify possible explanations and responses using what's currently known.
- Decide - choose a response with an explicit measure of confidence.
- Act - carry out the authorized action.
- Learn - observe the outcome, compare it with what was expected, and propose reusable knowledge from the experience.
Restarting a worker is an action. The error rate dropping from 12% to 0.2% afterward is an outcome. Learn checks that result before drawing a lesson; a successful restart alone doesn't prove the problem was fixed.
The experience record includes the starting state, the options considered, the choice, the action, and its outcome. Learn uses that record to propose changes to what the organization knows. Keeping an incident log alone doesn't provide that conversion.
Orientation
Boyd emphasized orientation, and it's where most of OODAL's design work sits.
Orientation answers a specific question:
Given what I currently know, what possibilities deserve consideration?
If the right explanation never enters the candidate set, the decision step can't choose it. Considering every imaginable explanation isn't practical either. Orientation needs to find a useful set within the time and resources available.
To build that candidate set, I separate orientation into five operations:
- Recall - What do we already know that might be relevant here?
- Intuit - Of the possibilities we know about, which deserve attention first?
- Explore - What cheap evidence could tell these possibilities apart?
- Expand - What might we not be considering yet?
- Escalate - When do we need a human's judgment?
Recall retrieves candidates from organizational knowledge. Graph traversal, semantic search, or rules could sit behind the same interface.
Intuit uses a bounded decision model. Given an explicit set of possibilities, it returns a probability distribution over them. It can't add candidates.
Explore gathers evidence that could distinguish candidates. If checking queue depth would help separate two hypotheses, the system checks it, updates its state, and runs orientation again.
Expand asks a generative model for new possibilities when the known ones don't explain the situation. Its proposals need evaluation, and its calls have a cost. I don't want to invoke an LLM for every problem.
Escalate asks a human to review the situation with the evidence gathered so far.
Orientation repeats as new evidence arrives, within a defined budget for steps, expansions, and observations. It stops when the system has enough confidence to decide or needs to escalate. If the budget runs out, the system hands the record to a human rather than forcing a choice.
The Adaptive Orientation Graph
I'm calling the structure that supports recall the Adaptive Orientation Graph. It holds concepts, hypotheses, observations, actions, experiences, outcomes, capabilities, goals, and policies. Typed relationships connect them:
ApiLatency
|-- may_indicate --> QueueBacklog
|-- may_indicate --> DeploymentRegression
|-- investigated_by --> CheckQueueDepth
CustomerCancellation
|-- may_indicate --> ProductProblem
|-- may_indicate --> PricingProblem
|-- investigated_by --> ReviewCustomerHistory
These relationships let orientation follow a situation across departments. A customer complaint might lead through:
Customer complaint
-> Product behavior
-> Engineering defect
-> Contractual obligation
-> Financial consequence
-> Approval authority
Engineering, support, product, finance, and compliance belong in the graph rather than being hard-coded into OODAL's core. The same traversal can follow an engineering defect into a contractual obligation or an approval requirement.
For building knowledge from existing documents, Microsoft's GraphRAG is a useful reference. It extracts entities and relationships from text, groups them into communities, and uses the graph and community summaries to support retrieval. That could help surface relevant evidence from an organization's records. OODAL would still need to represent its actions, outcomes, and policies explicitly, and review proposed knowledge before accepting it into the graph.
Once an investigation establishes a useful connection, recall should be able to retrieve it when a similar observation arrives. That gives the decision model something concrete to evaluate.
The decision model: judgment without invention
With candidates in hand, the next question is how to judge them. A new generation of decision-focused models is designed for this kind of work. Jev, from TypeSafe, returns typed decisions and probabilities from natural-language and image inputs. TypeSafe calls it a System One model and trains it for calibrated judgments.
OpenAI's Decisions API, currently using gpt-6-luna, offers a similar interface: estimate whether a condition is true, choose from supplied options, or score an input against defined levels.
An LLM normally generates a sequence of tokens, whether we're asking for an explanation or code. It can also generate structured JSON, but a valid schema doesn't tell us whether its confidence estimates are useful. These decision interfaces focus on a narrower task: we supply the evidence and define the answer space, and the model returns a typed judgment with probabilities. Our code can use that result without parsing prose or asking the model to choose its next tool call.
We still have to test those judgments. Calibration describes how well probabilities match outcomes across many predictions; it doesn't guarantee that an individual answer is right.
In OODAL, the decision model gets the current state and a fixed candidate set:
Cognitive state
+ Bounded candidate set
|
v
Decision model
|
v
Probability distribution + selected candidate
It answers: given these possibilities, which deserves attention? The distribution lets the runtime distinguish a clear preference from a close call. The interface has one firm constraint:
The decision model must not invent candidates.
Expansion supplies new candidates separately. That lets us evaluate the quality and cost of generating options independently of judging them. The decision model's cost and latency advantage needs to be measured on our workload, alongside its error rate.
UNKNOWN is a first-class answer
Every decision space in OODAL includes one extra candidate:
Deployment regression 0.10
Dependency outage 0.11
Database saturation 0.08
Queue backlog 0.06
UNKNOWN 0.65
UNKNOWN represents the possibility that the current candidates don't adequately explain the situation. Without it, the model has to favor a listed explanation even when none fits.
When UNKNOWN dominates, the runtime knows it needs more investigation instead of a forced choice.
System One for the common case
TypeSafe's name refers to the distinction Daniel Kahneman popularized in Thinking, Fast and Slow. System One describes fast, intuitive judgment; System Two describes slower, deliberate thought. I'm borrowing that distinction for the architecture, without assuming these models reproduce human cognition.
OODAL's System One path starts with recall and bounded judgment. If stored knowledge supplies a familiar explanation and the decision meets the application's confidence and policy requirements, the runtime can act without calling a generative reasoning model. Keeping routine cases on that short path is how I expect to reduce cost and latency. Retrieval has costs too: a GraphRAG query that invokes an LLM would need to be accounted for rather than treated as a free lookup.
If the evidence is ambiguous or UNKNOWN dominates, the runtime switches to a System Two path. It gathers discriminating evidence and, when needed, asks a reasoning LLM to develop new hypotheses. Those hypotheses go back through bounded evaluation. Slower reasoning helps extend the candidate set; it doesn't take ownership of the loop.
For example, a familiar queue backlog might need only a quick check and an authorized response. Conflicting evidence would trigger investigation of another failure mode. If the slower path still can't support a decision, the system asks a human.
Asking a human
Human intervention is an expected part of the process. It can follow an inconclusive investigation, but a policy may also require it immediately for a high-stakes action. The runtime doesn't have to spend the entire reasoning budget before recognizing that someone needs to make the call.
The person may gather more evidence, consider explanations the system missed, or choose an action. The system gives them the investigation's context and records their contribution along with the outcome. That record becomes input to learning.
Learning from an investigation
The design rests on a hypothesis:
Experience can progressively compress expensive deliberation and human judgment into reusable knowledge and bounded probabilistic intuition.
An unfamiliar situation might need substantial investigation:
Recall -> Intuit -> Explore -> Expand -> Human -> Resolution -> Learn
A person spends time investigating a problem the system hasn't encountered before.
A later occurrence could take a shorter path:
Recall -> Intuit -> Explore -> Resolution -> Learn
Recall can now supply the explanation and the observation that helped confirm it. A case that once required System Two reasoning or a human may become a System One decision. Learn still checks the outcome and can propose revisions if the familiar explanation stops matching the evidence.
The learning target includes which possibilities the system considers, as well as which actions it takes.
Graph changes require review. A learner, human or model, examines a completed experience and proposes updates. A human accepts or rejects them before they become available as organizational knowledge. This keeps a single incident or a mistaken interpretation from automatically changing future decisions.
Who owns the loop?
In OODAL, the runtime owns the control loop. It replaces the model-directed pattern:
LLM -> tool -> LLM -> tool -> LLM -> tool
A deterministic runtime orchestrates the operations described above. Each emits a structured trace event. The completed trace records the observations, retrieved knowledge, candidates and their scores, expansions, human involvement, actions, outcomes, and proposed learning changes.
This lets us test control flow without live models. Every primitive has a deterministic mock, so a test can assert the complete trace without a network connection, API key, or database. For example, given a particular state and candidate set, a decision result of UNKNOWN at 0.70 should route to expansion.
Authorization remains a separate, policy-driven step. A high confidence score doesn't grant permission to act. The runtime must check whether the action is allowed, even when the decision model recommends it.
Where this stands
I'm building the prototype in C#/.NET. Its core is independent of any particular model provider, graph database, or business domain. A small simulated organization exercises the same operations across different situations to explore how well they generalize. The bounded decision model currently uses a mock. Jev and OpenAI's Decisions API are candidates for that interface; I haven't evaluated them in the prototype yet. GraphRAG is a reference for the retrieval design, not an existing integration.
What I do not know yet:
- Which kinds of judgment can be captured in graph knowledge and a bounded model, and which will continue to need a human?
- How should the system choose observations that distinguish competing hypotheses? Identifying a useful check is harder than executing it.
- How much review will proposed graph changes need, and when will that review become a bottleneck?
The prototype should help me find out where this approach works and where it still needs human judgment. The useful test is whether what it learns from one investigation makes the next one easier to resolve.