Skip to content

Choosing an Agent Architecture—and Deciding How Much Autonomy It Deserves

Extending Victor Dibia’s decision framework with deterministic alternatives, verification, permission boundaries, and the economics of coordination.

I am only 25 pages into Victor Dibia’s Designing Multi-Agent Systems, and one of its diagrams has already made me pause and start extending it.

Figure 1.8 presents a decision framework for choosing an AI agent architecture based on task requirements. It asks whether the task requires actions beyond text generation, whether the solution can be expressed as a known workflow, and whether specialisation or exploration justifies a more elaborate system. The outcomes include a simple model, a single agent, a multi-agent workflow, and an autonomous multi-agent system.1

It is a useful starting point because it makes architecture a consequence of the problem. Looking at it through a software engineering lens, I wanted to make several additional decisions explicit: whether AI is needed at all, what separates one responsibility from another, how results will be verified, which actions are authorised, and what evidence would justify the coordination overhead.

This article develops that extension. It is an interpretation and a proposal inspired by the diagram, not a claim that the book omits these subjects elsewhere. I have not finished reading it, and a single figure cannot represent an entire book.

The central distinction I want to introduce is this:

Task structure helps determine the architecture. Permissions, consequences, and verification constrain the autonomy we can responsibly delegate to it.

Those decisions interact, but they should not collapse into a single progression from “simple model” to “autonomous team.” Five specialised agents can operate inside a tightly controlled process. One agent can hold broad authority over an external system. Agent count tells us very little about the consequences of a mistake.

Define the terms before choosing the boxes

Agent terminology is inconsistent enough that two people can agree on a diagram while imagining different systems.

In this article, a model call is an invocation that produces an output from supplied input. The surrounding application decides what happens next. A workflow is a process whose permissible transitions and execution rules are defined primarily in code. A single agent has a bounded loop in which a model selects subsequent steps using feedback from tools or its environment. A multi-agent system contains multiple such participants with separate responsibilities or execution contexts, plus a mechanism for coordinating their work.

This working distinction is consistent with Anthropic’s separation between predefined workflows and systems in which models dynamically direct their execution.2

The distinctions matter in practice. A pipeline with an extraction prompt, a classification prompt, and a summarisation prompt is not automatically a team of agents. It may simply be a well-designed workflow with three model calls.

Likewise, “autonomous” does not mean unrestricted. An agent may independently choose which read-only diagnostic query to run while having no ability to restart a service. It has autonomy over its investigation, not over remediation.

I therefore propose making three decisions explicit:

Decision Core question Possible outcomes
Execution structure How is the work organised? Conventional code, fixed workflow, one adaptive loop, coordinated adaptive loops
Capability design What information and operations are necessary? Retrieval, computation, scoped memory, read-only tools, state-changing tools
Delegated authority What may execute without additional approval? Advice only, bounded read access, reversible changes, approved consequential actions

Retrieval belongs in the capability decision. It can support a simple question-answering application, a fixed workflow, or a team of agents. It should not be treated as a competing architecture that excludes those options.

Start one step earlier: does the task need a model?

The first branch in my extension appears before the first agent.

Can explicit rules and conventional software solve the relevant part of the task reliably?

Consider an application that receives an invoice, identifies its supplier, checks a purchase order, validates totals, and routes an exception. Some parts may require interpretation of variable document layouts. Other parts are exact operations: arithmetic, identifier matching, duplicate detection against a known key, or comparison with a configured threshold.

A model may help extract a supplier name from a scanned document. It should not become the authority for whether a set of line items adds up to the stated total when a deterministic calculation is available.

That gives us a mixed design: probabilistic interpretation where it is useful, deterministic enforcement where the requirements are explicit.

The decision applies at the component level. A business process does not need to be classified globally as either “AI” or “not AI.” One ambiguous step does not make every subsequent step ambiguous.

There is also a difference between a rule that can be written and a rule system that remains practical to maintain. A classification task with hundreds of unstable linguistic variants might technically admit hand-written rules while making a trained classifier or language model a better engineering choice. The question is whether conventional logic meets the required accuracy and maintenance constraints—not whether someone can imagine an elaborate set of conditions.

Example: “Reject a transaction if the required identifier is absent” is an explicit rule. “Interpret what this customer is asking for in an unstructured message” is a different kind of problem. They can coexist in the same application without sharing the same implementation mechanism.

External knowledge does not automatically require an agent

Suppose an employee asks which internal policy applies to a particular expense. The relevant information is outside the model’s supplied context, but the application may still have a stable process: retrieve authorised policy passages, generate an answer grounded in those passages, and provide references.

Nothing in that requirement necessarily demands an adaptive agent loop.

The application still needs engineering decisions: which documents are authoritative, how versions are handled, how access is enforced, and what happens when the evidence is insufficient. Retrieval can supply evidence; it does not guarantee that the generated interpretation is correct.

Now change the request: “Investigate why these two policy documents appear to disagree, locate the approval history, and identify who owns the unresolved discrepancy.” The next step may depend on discoveries during the investigation. An adaptive loop becomes a plausible candidate.

The output of both tasks may be text. Their execution structures differ because one follows a stable retrieval-and-answer process, while the other may require iterative investigation.

This is why my extension asks about adaptive execution, not only whether the final output contains something beyond text. A research agent can produce a written report while still performing substantial autonomous tool use along the way.

A known process does not require an agent at every step

When the path is known, the next question is whether the system needs freedom to choose its own path at all.

Imagine a support intake process. The application classifies a message, extracts an order reference, retrieves the corresponding record, applies eligibility rules, and drafts a response. There may be several model calls and several tools. Nevertheless, the process can remain a controlled workflow.

A fixed workflow can also contain a bounded agent as one step. An investigation stage may search for missing information, after which a deterministic controller resumes routing the case. These patterns compose; they are not mutually exclusive product categories.

Different responsibilities still deserve different components. However, a useful module boundary is not automatically an agent boundary. Before introducing a separate agent, I would ask what capability the agent contributes beyond a function, service, or model call.

Does it need its own iterative reasoning process? Its own evolving context? A distinct set of tools? A separately managed execution budget? If the only distinction is a title in a prompt, a separate agent may be an unnecessarily expensive abstraction.

Example: An “Invoice Arithmetic Agent” that checks totals by asking a model to reason about numbers is a questionable design when a calculation function already provides the answer. An exception investigator that examines inconsistent supporting documents may justify adaptive behaviour. The two responsibilities should not be implemented identically simply because both appear in the same workflow.

Separate agents when the boundary has an engineering purpose

Specialisation is a reasonable motivation for multiple agents, but it needs a precise meaning.

One possible boundary is context. A broad investigation may contain several substantial evidence sets that do not all need to remain in one execution history. Separate workers can investigate narrower questions and return structured findings.

Another boundary is tools and permissions. A worker reviewing public documentation may need web retrieval. A worker analysing an internal service may need access to approved telemetry. A component applying a configuration change needs a much narrower, explicitly controlled write capability.

A third boundary is evaluation. A component that proposes a solution and a component that challenges its evidence can have different instructions, inputs, and acceptance criteria.

These are candidate reasons for separation, not proof that additional agents will improve the result. Context fragmentation can remove information that a worker needs. A separate reviewer can repeat the proposer’s mistake. Multiple workers can duplicate the same search while missing the same source.

Permissions deserve particular care. Two agents with different role prompts but the same credentials have not created a security boundary. The boundary must be enforced by the runtime, tool layer, credentials, and downstream services. OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency, and recommends limiting what tools and identities can do.4

For my proposed framework, every new agent should have a short architectural justification:

This component requires a separate execution context because ____. Its inputs are ____. Its permitted operations are ____. Its output is accepted only when ____.

If those blanks cannot be filled clearly, the separation may be premature.

Decide which dependencies permit parallel execution

Multiple agents do not imply parallel work. Parallelism depends on the structure of the task and the resources being changed.

Consider a comparison of three technology vendors. Each worker can independently collect evidence about one vendor using the same criteria. A later step reconciles definitions and compares the findings. That is a plausible parallel decomposition.

Now consider a migration where the target schema must be approved before transformation logic is written. Generating transformations against an unsettled schema creates rework. The dependency exists regardless of how many workers are available.

Even apparently independent tasks may share mutable state. Two coding agents editing the same module can conflict. Two operations agents changing different settings in the same service can invalidate each other’s assumptions.

Dependency pattern Candidate execution structure Main concern
Independent evidence gathering Parallel workers, followed by reconciliation Inconsistent definitions or evidence quality
Known prerequisite relationships Sequential workflow or dependency graph Invalid handoffs and stale intermediate results
Dependencies discovered during execution Bounded adaptive coordinator Duplicate work, scope expansion, coordination failure

The coordinator needs more than the ability to send messages. It must understand what counts as completion, which findings conflict, whether workers are blocked, and when further delegation is no longer useful.

Make handoffs explicit

An agent boundary introduces an information boundary. That information can be lost, distorted, or accepted without sufficient evidence.

For the vendor investigation, “Vendor A looks strongest” is a weak handoff. It hides the criteria, evidence, and uncertainty. A useful handoff identifies the scope examined, the findings, their sources, and what remains unknown.

An illustrative contract might look like this:

{
  "task_id": "vendor-a-resilience-review",
  "status": "completed_with_gaps",
  "criteria_version": "1.0",
  "findings": [
    {
      "criterion": "documented_recovery_procedure",
      "assessment": "evidence_found",
      "evidence_refs": ["source-014#recovery"],
      "limitations": "Procedure documented; execution not independently tested"
    }
  ],
  "unresolved_questions": [
    "No evidence found for the requested recovery-time commitment"
  ],
  "recommended_next_step": "Request clarification before final comparison"
}

These are example fields and placeholder evidence references, not findings about a real vendor.

A schema makes missing fields and invalid statuses detectable. It does not prove that a claim is true. The receiving component must still check whether a source supports the assessment and whether the evidence answers the actual question.

This distinction matters because a syntactically valid response can be confidently wrong. A handoff contract needs both structural validation and an appropriate method of checking its meaning.

Treat verification as part of the architecture

Before deciding how independently a system should operate, I want to know how we will recognise success and failure.

Verification is rarely binary. Different properties require different checks.

For generated code, parsing and compilation establish only limited facts. Tests add behavioural evidence, but their coverage and quality determine what they can establish. A successful deployment does not prove that the change solved the customer’s problem.

For a research report, valid citations are only a starting point. The cited sources must support the claims, relevant contradictory evidence must be considered, and the comparison must use consistent criteria.

For a state-changing operation, a successful API response may require a subsequent read to confirm the resulting state. A timeout may mean the operation failed, or it may mean the operation succeeded and the response was lost.

Property Example check What it cannot establish alone
Structural validity Schema, required fields, type checks Factual correctness
Deterministic consistency Arithmetic, identifier matching, allowed transitions Whether the input itself is trustworthy
Behavioural correctness Tests against defined requirements Correctness outside the tested conditions
Evidence support Claim-to-source review Complete coverage of all relevant evidence

A second model can provide useful criticism. It should not be treated as an independent oracle merely because its role is “reviewer.” Shared inputs and similar reasoning can produce shared errors.

When verification is weak, I would narrow the permitted action, require more review, or keep the output advisory. Adding more agents does not by itself solve the inability to recognise a wrong result.

Give consequential actions their own decision path

The photographed diagram includes significant side effects in a question that can lead towards autonomous multi-agent systems. My extension moves consequences into a separate authority decision.

An action can be mechanically simple and still require strict control. Deleting a record might take one API call. That simplicity does not justify giving an agent permission to perform it freely.

Conversely, a long investigation may involve substantial adaptive reasoning while remaining read-only. Complexity and authority are different dimensions.

I would assess a proposed action against the following questions:

  1. Is this operation within the user’s or organisation’s delegated scope?
  2. What resources and people can it affect?
  3. Can its result be checked?
  4. Can an error be reversed or compensated for?
  5. Which conditions require approval or escalation?

Approval must apply to a concrete action. “Fix the service” is not the same as approving a particular configuration change against a particular version of that configuration. If the plan, payload, or relevant state changes materially after approval, the system may need to request approval again.

This does not mean asking a human before every routine operation. A pre-approved policy can authorise a tightly bounded action when explicit conditions hold. The policy should be enforced outside the model’s own declaration that the action is safe. OWASP’s guidance similarly places controls around permissions and approval of high-impact operations.4

For example, a diagnostic agent may automatically retrieve approved logs. It may prepare a proposed change in a staging environment. Applying the change to production can remain behind an independent authorisation gate.

Plan for uncertainty after execution

Recovery is easy to underestimate when a diagram ends at “execute.”

Suppose a tool times out after submitting a request. Retrying immediately may duplicate the operation. The next step should depend on the operation’s semantics: inspect the resulting state, query an operation identifier, or reuse an idempotency key where supported.

Similarly, rollback is not a universal safety net. A published message may already have been read. An external notification cannot be made unseen. Restoring a configuration does not undo every effect it produced while active.

The architecture therefore needs distinct outcomes for failure, uncertain completion, and successful completion. An uncertain result should not silently become either “failed” or “safe to retry.”

I would record the intended action, its authorisation, the relevant state version, the execution identifier, and the observed outcome. Logs need enough detail to reconstruct what happened without indiscriminately storing secrets or unnecessary personal data.

Time, cost, retry, and delegation limits also belong here. A coordinator should not be able to escape a task budget simply by spawning more workers. Limits need to apply across the execution, including child tasks.

Require evidence that coordination is worthwhile

A multi-agent prototype can appear impressive while failing to establish why it is better than a simpler alternative.

My extension includes an explicit comparison gate. Before retaining the additional machinery, evaluate it against a credible baseline: a conventional workflow, a single model with retrieval, or one well-equipped agent.

Anthropic’s account of its research system provides a useful example of a workload where parallel exploration and separate contexts helped. It also discusses the additional resource requirements. That is evidence about a particular implementation and evaluation setting, not a general result that multi-agent systems are superior.3

For a local evaluation, I would compare both the quality obtainable at a similar budget and the cost required to reach a target quality. Otherwise, a design can appear architecturally stronger simply because it consumes far more computation.

The following table is entirely hypothetical. It illustrates a decision, not a benchmark result:

Candidate Accepted outcomes out of 100 Total execution cost Cost per accepted outcome Median latency
Fixed workflow 80 $100 $1.25 12 seconds
Single agent 90 $200 $2.22 30 seconds
Multi-agent system 94 $600 $6.38 55 seconds

Four additional accepted outcomes compared with the single agent may be worthwhile for a high-value investigation. They may be unacceptable for a low-margin, latency-sensitive service.

These numbers are insufficient by themselves. We also need the severity of failures, human review time, tail latency, recurring operating cost, and uncertainty in the measurements. One hundred examples may not be representative, and a small difference may not persist across repeated runs.

The acceptance criteria should be specified before comparing results. Include ambiguous requests, missing information, unavailable tools, contradictory evidence, and attempts to redirect the system through untrusted content. A happy-path demonstration is useful for showing that the system can work. It does not establish how reliably it works.

The extended architecture decision tree

The diagram below proposes an initial candidate. Retrieval, memory, tool design, and permission scoping remain supporting decisions across its branches. Evaluation can send us back to an earlier choice.

flowchart TD
    A["Define the task and acceptance criteria"] --> B{"Can conventional logic meet the requirements?"}
    B -->|Yes| C["Conventional code or workflow"]
    B -->|No| D{"Is the execution path known?"}
    D -->|Yes| E{"Does any step need adaptive execution?"}
    E -->|No| F["Controlled workflow with model calls"]
    E -->|Yes| G["Workflow with bounded agent steps"]
    D -->|No| H["Prototype a single bounded agent"]
    G --> I{"Do separate contexts, tools or responsibilities justify multiple agents?"}
    H --> I
    I -->|No| J["Retain the simpler candidate"]
    I -->|Yes| K{"Can responsibilities and handoffs be defined?"}
    K -->|No| L["Clarify or redesign the task"]
    K -->|Yes| M["Prototype coordinated agents"]
    M --> N["Parallelise independent work; sequence dependencies"]
    N --> O{"Does measured benefit justify coordination?"}
    O -->|Yes| P["Retain the multi-agent candidate"]
    O -->|No| J

Figure A: proposed extension for choosing an execution structure

Figure A. Proposed extension: choosing an execution structure. Inspired by Dibia’s Figure 1.8; the additional questions and organisation here are my proposed interpretation. “Known path” refers to execution structure, not knowing the answer in advance. Every retained candidate still needs evaluation and the authority controls below.

The action-authority decision tree

This second diagram applies to concrete operations. It prevents “we selected an agent architecture” from becoming an implicit grant of unrestricted authority.

flowchart TD
    A["Proposed action and concrete payload"] --> B{"Within delegated permissions?"}
    B -->|No| C["Deny or request authorisation"]
    B -->|Yes| D{"Consequential or difficult to reverse?"}
    D -->|Yes| E["Require approval or an applicable pre-approved policy"]
    D -->|No| F["Validate inputs and current state"]
    E --> F
    F --> G{"Preconditions and safeguards satisfied?"}
    G -->|No| H["Revise, narrow scope or escalate"]
    G -->|Yes| I["Execute within enforced limits"]
    I --> J["Inspect the outcome"]
    J --> K{"Outcome established?"}
    K -->|Success| L["Record completion"]
    K -->|Failure| M["Recover or compensate where possible"]
    K -->|Uncertain| N["Reconcile state before retrying"]
    M --> O["Stop or continue under the approved policy"]
    N --> O

Figure B: proposed extension for authorising and verifying actions

Figure B. Proposed extension: authorising and verifying actions. Approval does not override failed preconditions. Changed state or a materially changed payload may invalidate the original approval. The diagram is a design aid, not a complete security specification.

Worked example: invoice processing

Assume the task is to receive an invoice, match it to supporting records, identify inconsistencies, and prepare a disposition for review.

The process is largely known. A model may extract fields from varied documents. Conventional code checks arithmetic, mandatory fields, supplier identifiers, and purchase-order relationships. A controller routes disagreements to an exception path.

The initial candidate is therefore a controlled workflow. A bounded agent could investigate an exception by retrieving supporting documents and identifying the unresolved discrepancy. There is no immediate reason to introduce a separate agent for every validation rule.

The acceptance criteria distinguish extraction accuracy from final disposition accuracy. The system must preserve the source document, indicate unresolved fields, and avoid treating a plausible inferred value as a verified one.

Write authority is limited independently of this architecture. Preparing a draft record can be permitted under a defined policy. Releasing a payment is a separate consequential operation with its own controls.

What would justify more agents? Perhaps exceptions require several substantial, independently accessible evidence sets with distinct permissions. Even then, a prototype must demonstrate that the split improves investigation quality or throughput. Merely naming workers “Supplier Agent,” “Invoice Agent,” and “Payment Agent” would not establish that benefit.

Worked example: vendor due diligence

Assume the task is to compare several vendors against agreed criteria for integration, operational resilience, and support arrangements.

Some work can be predetermined, but the investigation may uncover missing evidence and conflicting terminology. Separate workers are plausible because each can examine a vendor or a clearly scoped dimension. The decomposition should avoid overlap: assigning both vendors and dimensions without a coverage plan can produce duplicated work and unowned gaps.

The workers use a shared criteria version and return evidence-linked findings. The coordinator normalises the comparison and identifies contradictions. A review step checks whether important claims are supported and whether a missing statement has been incorrectly treated as proof of absence.

The system can remain read-only. It may draft clarification questions, but sending them externally is a separately authorised action. A research system does not gain communication authority merely because it has identified something worth asking.

What would invalidate this design? If each vendor requires only a short inspection of two documents, a single agent may do the work with less overhead. If the criteria change repeatedly during execution, the system must version them and decide which earlier findings require rework. Additional agents cannot compensate for an undefined comparison.

Worked example: production incident investigation

Assume the task is to investigate an increase in failed requests after a deployment and propose a remediation.

An agent may need to choose its next diagnostic step based on observations. The investigation is adaptive. However, access to telemetry and authority to change production should be separated.

A first candidate is one agent with scoped read access to logs, metrics, deployment history, and relevant documentation. It produces a hypothesis, supporting evidence, alternative explanations, and a proposed action.

For a broader incident, independent workers might investigate application behaviour, infrastructure signals, and dependency health. The coordinator must reconcile their timelines and distinguish correlation from a supported causal explanation. Each worker needs enough shared incident context to avoid analysing a different time window or service version.

The proposal is then evaluated against a runbook and current system state. Any remediation follows the applicable approval policy. After execution, deterministic health checks and subsequent observations establish whether the expected recovery occurred.

What would invalidate this design? If the incident matches a well-tested, tightly scoped runbook, a deterministic diagnostic and remediation workflow may be more appropriate. If telemetry is incomplete, adding agents may produce more hypotheses without better evidence. The system should be able to report that uncertainty instead of turning an unverified explanation into a production change.

Limits of the proposed framework

This is a design heuristic, not an experimentally validated method for selecting the best architecture.

The decision tree simplifies a space in which hybrid designs are common. A single application can contain deterministic services, fixed model workflows, and adaptive agent loops. The useful unit of analysis is often a task or capability, not the entire product.

Some decisions can only be resolved through prototyping. We may suspect that context separation will help but discover that the coordination overhead outweighs the benefit. We may begin with one agent and later split a responsibility after observing consistent failures.

The framework also leaves substantial design work outside the diagram: data retention, privacy, infrastructure isolation, model selection, availability, and organisation-specific obligations. Those concerns need explicit treatment in a real system. No branch labelled “approved” establishes that they have been addressed.

Most importantly, the framework cannot repair poorly defined objectives. If stakeholders cannot agree on an acceptable outcome, allocating the work to more agents distributes the ambiguity.

What I want an architecture review to make explicit

The purpose of this extension is to produce a decision that another engineer can inspect and challenge.

For any proposed agent system, I would expect a short record covering the task, its acceptance criteria, the simpler alternatives considered, the reason for each agent boundary, and the evidence supporting the selected design. The same record should identify permitted operations, verification methods, recovery behaviour, and conditions under which the system stops or escalates.

I would also record what would cause us to simplify the design. An architecture that is justified only by its initial promise is difficult to maintain honestly. If a simpler implementation meets the required quality at lower cost and with fewer failure modes, the decision should be revisited.

Dibia’s diagram gave me a useful starting point. My extension makes the next set of engineering questions visible: why this boundary, why this authority, how we will detect failure, and what improvement pays for the coordination.

Those are the questions I want answered before an agent architecture becomes a production responsibility.

Sources and attribution

Authorship note: This article presents my proposed extension and interpretation of an existing decision framework. I used an LLM to help develop the structure, explore examples, and refine the language. The examples are illustrative; the numerical comparison is hypothetical. The extended framework has not been empirically validated. Corrections, counterexamples, and suggestions for testing it are welcome.

  1. Victor Dibia, Designing Multi-Agent Systems: Principles, Patterns, and Implementation for AI Agents. Figure 1.8, “Decision framework for choosing the right AI agent architecture based on task requirements,” from the reader-provided photograph. The discussion of the original framework is limited to the supplied figure. ↩

  2. Anthropic, Building effective agents. Background for the working distinction between predefined workflows and model-directed execution. ↩

  3. Anthropic, How we built our multi-agent research system. An implementation-specific account of parallel research, context separation, evaluation, and operating trade-offs. Its findings are not presented here as universal benchmarks. ↩

  4. OWASP Gen AI Security Project, LLM06:2025 Excessive Agency. Background for limiting functionality, permissions, and autonomy, and controlling high-impact operations. ↩↩