At a glance
What you need to know.
Choose an agent architecture from the task, permitted actions and recovery requirements. A fixed workflow, a bounded single agent and a coordinated set of agents solve different problems. Start with the smallest supported execution model, then add autonomy only when evaluation shows that it helps a defined journey.
Distinguish workflow from agent discretion
A fixed workflow executes steps that the application defines. An agent selects some next steps from the state and permitted tools. Use a fixed workflow when the sequence and branching rules are already known, such as validate a form, request approval and post an accepted record. Agent discretion can help when the task needs interpretation or varied investigation. Document exactly which choice belongs to the model. A conversational interface or several model calls do not by themselves justify an autonomous control loop.
Use a bounded single agent for one coherent task
A single agent can inspect permitted evidence and propose a result within a limited task, such as preparing a cited support draft. Define its inputs, tool allowlist, stop conditions and required output. Keep execution and authorization outside the model where business rules are known. Limit iterations and cost, and make an unresolved state available to a reviewer. This pattern is easier to inspect than a collection of agents when one role and one evidence scope suffice. Test ambiguous instructions and irrelevant sources as well as the ideal case.
Add coordination only for a real separation of work
Several agents can be useful when distinct tasks, evidence scopes or review roles need separate boundaries. Define who creates the task, who owns the shared state and who decides that the overall result is accepted. Treat messages between agents as proposals that require schema and permission checks. Avoid several agents repeating the same search without a clear reason. A coordinator can become a bottleneck or an extra failure dependency. Evaluate the coordinated design against the simpler single-agent or workflow baseline before accepting the added complexity.
Model state and effects explicitly
Store task state independently from a conversation transcript: requested, investigating, proposed, awaiting approval, executing and completed may need different recovery rules. Give each proposed effect a stable business reference. If a tool times out after a write, reconcile destination state before allowing another attempt. An agent's belief that it succeeded is not evidence of the actual record. Define how cancellation, changed inputs and expired approvals affect pending work. The architecture needs an operator-visible exception when it cannot safely determine the next step.
Design tools as narrow business operations
Expose a task-specific operation such as prepare a draft or fetch an authorized order status rather than unrestricted database queries or arbitrary command execution. Validate tool arguments against the current identity and record ownership. Return bounded data and explicit errors. Keep secret values outside model context. A tool description helps selection but cannot enforce a permission. Test an attempted operation outside the allowlist, misleading source text and an unexpected tool response. The output of one model or tool should not silently become trusted instructions for the next.
Compare patterns with complete-task evaluation
Use the same task set to compare workflow, single-agent and coordinated designs. Record accepted completion, inappropriate actions, reviewer effort, elapsed time and full execution cost. Include unsupported questions, changed sources, unavailable tools and a malicious instruction embedded in content. Assess the actual destination result for write workflows. A more elaborate architecture needs evidence of a useful benefit, not merely a longer reasoning trace. Release a bounded category first and retain a stop mechanism and a fallback that the responsible team can operate.
Keep evidence and execution under separate authority
An AI-generated proposal is not authorization to perform a business action. Validate record ownership, tool arguments and the permitted operation outside the model using the actual requesting identity. Restrict tools to the agreed task and require a reviewed path for privileged or irreversible decisions. Treat retrieved documents and tool responses as untrusted content that can contain misleading instructions. Preserve the evidence a reviewer needs with appropriate access, rather than exposing raw sensitive inputs in general logs. OWASP's prompt-injection guidance supports layered controls; retrieval, fine-tuning and a carefully written prompt do not establish an enforceable security boundary.
Before you start.
- Which decision needs model discretion?
- What state and permitted tools define the loop?
- Does coordination add a measurable useful capability?
- How are ambiguous effects reconciled?
- Can an operator stop and recover the task?
Common questions.
Do multiple agents always produce a better result?
No. Coordination adds state, communication and failure handling. Use several agents when distinct tasks or authority boundaries justify them, then compare accepted quality, review effort, elapsed time and cost with a simpler baseline using the same evaluation cases.
Can an agent enforce authorization from its system prompt?
A prompt can describe intended behavior but is not an enforceable application boundary. The server and tools must validate identity, record ownership and allowed effects independently. Keep high-risk actions reviewed and test misleading content and invalid tool arguments.