Agentic AI Architecture

Most agent frameworks default to ReAct (Reasoning + Acting): the agent generates a thought, selects a tool, observes the result, generates another thought, and repeats. ReAct is simple, well-understood, and adequate for straightforward retrieval-and-answer tasks.

For complex enterprise workflows — multi-step analysis, high-stakes decision support, workflows with adversarial or noisy inputs — the OODA loop is a better decision architecture. The key difference is that OODA treats orientation (the agent's world model) as a first-class, explicitly maintained component rather than an implicit by-product of the chain-of-thought. This makes the agent's beliefs inspectable, correctable, and auditable — which matters enormously when the agent's decisions have regulatory or financial consequences.

The practical question is: does your agent need to maintain coherent state across 10+ tool calls, handle contradictory observations gracefully, and produce an audit trail that reconstructs its reasoning? If yes, the OODA architecture is worth the additional complexity. If no, ReAct is fine.

The instinct in enterprise AI projects is to build one general-purpose agent that can do everything. This is the wrong instinct for most production use cases.

Single-agent architectures are appropriate when the task is coherent — a single domain of expertise, a consistent set of tools, a bounded decision space. The agent's context stays manageable, its reasoning is coherent, and failures are localized.

Multi-agent architectures are appropriate when the task genuinely requires specialist capabilities that cannot coexist in a single context window without degrading each other. An AML investigation pipeline that needs a document retrieval specialist, a transaction pattern analyst, a regulatory knowledge retriever, and a report drafting agent is a genuine multi-agent problem — each specialist has a different tool set, different knowledge base, and different failure mode profile.

The failure mode of premature multi-agent architecture is coordination overhead and debuggability collapse: when something goes wrong in a five-agent pipeline, finding the root cause requires tracing across five separate reasoning chains. Build the simplest agent that solves the problem, then split when you have specific evidence that a single agent is hitting a capability ceiling.

This is the question that enterprise AI teams most frequently get wrong — not because they don't want human oversight, but because they implement it incorrectly.

Advisory oversight (the agent can proceed if a human doesn't review within N minutes) is not oversight. It is a paper trail. Under load, when queues back up, the agent proceeds without review, the "oversight" never happened, and you have documented that you built a system with nominal oversight and real autonomy.

Structural oversight (the agent physically cannot take the irreversible action without a human approval token) is real oversight. It creates queues when reviewers are unavailable. It creates operational pressure to hire and train enough reviewers. It creates the friction that tells you the governance is actually working.

The architectural rule is: every irreversible action (filing, transaction, decision that becomes system-of-record) requires a structural human gate. Every reversible action (routing, classification, draft generation) can be monitored with post-hoc audit rather than synchronous approval. The boundary between reversible and irreversible is a governance decision, not a technical one — and it needs to be made explicitly, documented, and defended to auditors.