One of the great challenges facing organizations seeking greater value in an age of agentic systems is this: how do I allow autonomous software to manage the state of my business without introducing great risk. I mean, as it is, the human organizations we have relied on since the dawn of computing have often failed to maintain a clean digital record of even simple operations. How can software with the freedom to make non-deterministic decisions do any better?
In the world of agentic AI, there is a trick you can use to assure not only is data captured in a consistent, reliable way, but that it is being reviewed and updated constantly as the organization learns more about itself, its customers, and its markets.
It begins with building a reliable ontology that not only captures meaning, but evolves it as the business engages with the world around it. And that evolution depends on repetitively comparing what is known with what is being observed whenever action is taken. One method of doing exactly this is known as the OODA loop.
A Short History of The OODA Loop
Many of you may be well aware of what an OODA loop is and how it is used in software development. You can probably skip this section. However, for those who are not familiar with this concept, the best way to describe it is to put it in the context of how it was created.
John Boyd was a fighter pilot in the Vietnam War. He was also very focused on learning absolutely everything he could to gain an advantage against an unpredictable opponent. Over the course of several years, he developed a practice that he called the OODA loop, which he used to great effect in winning dogfights and later training the best of the best in aerial combat.
(The loop as John drew it is pictured below. You can learn a lot more about the details of how it was created in Boyd: The Fighter Pilot Who Changed The World by Robert Coram (Back Bay Books, 2002)).
From Wikipedia under a Creative Commons 3.0 Unported license
The OODA loop consists of four steps:
- Observe: Gather as much information as possible about the world around you in this moment
- Orient: Align that information with your understanding of the state of the world in the past, as well as your experience with the subject at hand
- Decide: Choose an action you should take in light of that information and knowledge
- Act: Take that action and immediately begin the process again
Any of these steps can force a reversion to any previous step if required to achieve the best outcome. This is the power of this concept. It is a constant loop driving intelligent action as fast as possible without sacrificing the ability to adapt as conditions change.
Since the early 2010’s, the OODA loop has been used by many in the software development community. It is still one of the most concise ways of describing the decision making process that great software teams use to build software in fast, agile environments. It is also applied to operations processes, requirements gathering, and a number of other product and engineering tasks.
The OODA Loop and Data
The OODA loop is also a great model for integrating AI with enterprise data and processes. The idea of making decisions quickly with the right context is exactly what AI agents and applications are all about. Let’s explore how you might apply OODA to AI data usage. You can think of this as how it applies to an agent, but in reality it applies to AI-human interaction, as well.
Observe: The Right Data
Making smart decisions starts with what you know. For an agentic system, this is going to be a combination of past outcomes, new events, and stored data. It is critical that your agents have access to as much of this information as possible to make a good decision, so the agent’s environment has to enable such access.
Of course, it is not always appropriate for agents (or the humans they are working for) to have access to all the data they may want. So when an agent requests data, it is important that the environment (such as an AI orchestration system like Kamiwaza) works with the owners of data to manage who can see what, when. This is how you can trust arbitrary agents to run in your environment without inappropriately using data.
Orient: The Right Context
Having access to data is not the same as using data wisely, however. The next step of the process is to collect the right data for the task at hand, and to build context for the AI models to use for inference as efficiently as possible.
AI orchestration can help here, too. Give your agents access to data through platforms that help models understand exactly what data to request, and validates any data retrieved against the intent of a prompt. This enables context to be much more efficient than it would be with a system that grabs more than it needs, or fails to grab enough (both of which can lead to hallucinations or other unsatisfactory responses.)
Kamiwaza uses both semantic and ontological indexing to help AI models determine exactly what data to request in order to satisfy a prompt. When inference happens, the Kamiwaza Inference Mesh may choose to forward that request to a node where the data resides, and where the inference process can determine exactly what data to include in response to that request.
The result is both efficient context building, as well as the safety of knowing that access to that data is allowed for the party or parties involved. You will also know that any data sovereignty policy is satisfied, and that the key steps of that process were logged and available for audit.
Decide: The Right Result
With the context built, the model can determine what to deliver as a response to the prompt in question. The model that is used to do so—including how many parameters and what weights are used to build a response—is a key factor in the trustworthiness of that response. We prove this regularly in our ongoing work with Signal65 to evaluate and score models on their agentic trustworthiness.
Even as a response is being built, it is useful to make sure that everything has been validated and flagged for concerns. This gives agents the opportunity to reject the response or request a correction before taking action. LLMs can return inaccurate results, so a good checks-and-balances architecture is critical. Kamiwaza does some of this even as context is being built, but in any agentic architecture, agents acting as circuit breakers or critics are critical to driving accuracy.
Act: The Right Outcome
With a result you trust, the agent can now choose what to do with it. This is often driven by code or skills that exactly map out the action to be taken: a call to an API, storage of result data into shared memory, or perhaps even another AI prompt. Regardless, at this point it is critical to validate that the right outcome is a) possible, and b) verifiable.
Kamiwaza doesn’t dictate how your agent should do any of these things. As an orchestration platform focused on data usage, its only requirement is that it handles data access and inference. Everything else is something that your coding agent of choice can decide with your guidance.
Feedback Loops
You can get some sense of how feedback is initiated in some of the steps described above, but let me be explicit about some of the particulars. For example, there are decision points during any significantly complex agentic process that should trigger various forms of handing the process back to earlier steps before continuing. This is part of that checks-and-balances flow I just described.
It is not always obvious when such feedback is necessary and how it is accomplished. I think this is one of the areas where Kamiwaza helps immensely, but good agentic systems architecture is also critical.
So, let’s just walk through a hypothetical example and see where feedback is triggered and why. Pay attention to the ways it can be used to not only detect when things go off track, but also to prevent it from doing so in the first place.
Imagine an agent responsible for keeping inventory balanced for a global retailer. Nothing exotic—just making sure products don’t run out in the wrong place at the wrong time.
Then something breaks.
A supplier reports a five-day delay on a shipment. Inventory on hand runs out in three.
That single event is enough to kick the loop into motion.
In the Observe phase, the agent starts pulling together what it knows: current inventory, demand forecasts, supplier performance, alternative sources. Straightforward in theory. In practice, this is where things already start to wobble a bit. Some data might be restricted. Some might be stale. Some might not exist in the form the agent expects.
So the system adjusts. It requests access. It re-queries. It works around gaps. Even here, you’re not looking at a clean step—you’re looking at the first set of feedback loops making sure the agent isn’t about to reason from bad or inappropriate data.
By the time it reaches Orient, the problem isn’t access—it’s focus. There’s always more data than you need, and almost never exactly the data you want. So the agent must narrow things down: which regions matter, which products actually drive revenue, which suppliers are viable in this situation. If something critical is missing—say, pricing for a backup supplier—it goes back and gets it. If too much irrelevant data sneaks in, it gets trimmed away (i.e. the agent revises its observations.)
This is where orchestration earns its keep. Not by giving the model more data, but by helping it ask for the right data. And checking that the data it retrieves is, in fact, the right data. Skip this, and you don’t just get inefficiency—you get hallucinations, bad assumptions, and ultimately bad decisions.
Then comes Decide. At this point the agent has enough context to act. It evaluates options: expedite the shipment, switch suppliers, rebalance inventory across regions. It produces a recommendation. But here’s the part people tend to gloss over: that answer isn’t the answer.
It still has to survive scrutiny.
Maybe the alternative supplier isn’t approved. Maybe the cost blows past a policy threshold. Maybe the assumptions don’t line up with reality. So something—another agent, a rule system, a validator—pushes back. The response gets revised, or rejected outright, and the loop runs again.
Only once it passes that gauntlet does the system move to Act. Orders are placed. Inventory is rerouted. APIs fire. And then, inevitably, something doesn’t go as planned.
An API call fails. A supplier can’t fulfill the order. A shipment doesn’t arrive where it should. So the agent checks the outcome, compares it to what it expected, and—if needed—drops right back into the loop with a slightly different observation of the world.
There are so many places in which the output of one step of the loop can redirect the flow of the loop to a previous step with new understanding.
The “Loop” in OODA
In other words, the OODA loop isn’t just a cycle the agent completes. It’s something the system is constantly falling back into.
At every stage—data access, context building, decision-making, execution—you have opportunities to be wrong. The value of an agentic system isn’t that it avoids those moments. It’s that it detects them early, corrects them quickly, and carries that correction forward into the next pass.
Or put more simply:
The OODA loop isn’t what the agent does once. It’s how the system keeps itself from drifting off course.
Success in agentic AI at scale is predicated by what the system does at scale, in the face of unknowns. That is exactly why the feedback mechanisms and constant iteration of the loop is a foundational principle that every agent builder should understand.
As always, I write to learn. I’d love to hear your thoughts! Let me know in the comments below.
