4. Theoretical Requirements for Agents

Deconstructing the architecture of an agent: the models, tools, state, controls, and runtime needed to build one reliably.

Building an AI agent is primarily a software and systems-engineering problem. The language model is an important component, but it is not the complete agent.

A production agent also needs an execution environment, clearly defined tools, application state, permissions, validation, stopping conditions, observability, and mechanisms for human intervention. The system surrounding the model determines what the agent can see, which actions it can take, and whether those actions are actually executed.

The simplest useful agent may be only a model, a small set of tools, and an execution loop. A production-grade agent usually requires a broader architecture designed around reliability and risk.

Start With the Right Abstraction

Not every multi-step AI application needs an autonomous agent. It is useful to distinguish three levels of architecture:

Single model call: The application sends input to a model and receives one output.
Workflow: The developer defines the sequence, branches, and control flow. Models perform selected steps inside that predefined process.
Agent: The model has some responsibility for choosing the next action based on the goal, current state, available tools, and previous observations.

Workflows are generally easier to predict, test, and audit. Agents are useful when the required sequence cannot be known completely in advance and must adapt to information discovered during execution.

🧱 Use the Simplest Architecture That Works

Do not add planning loops, persistent memory, multiple agents, or dynamic tool selection merely because they are available. Begin with deterministic application logic and introduce model-driven control only where flexibility provides measurable value.

The Anatomy of a Modern Agent

There is no universal agent architecture, but most robust systems contain the following components.

🧠 1. The Model Layer

The model interprets the task, evaluates the current state, generates outputs, and may select the next action. Depending on the application, it may process text, images, audio, video, files, or structured data.

Modern models can return more than ordinary prose. They may produce structured objects, request tool calls, generate code, or delegate work to another model. However, the model normally proposes an action rather than directly receiving unrestricted access to the operating system or external services.

The surrounding application decides whether a proposed action is valid, authorized, and safe to execute.

📜 2. Instructions, Policies, and Task Context

The agent needs instructions describing its objective, role, constraints, available tools, trusted sources, output requirements, and stopping conditions.

These instructions may come from several places:

Developer or system-level instructions.
The user’s current request.
Application policies and business rules.
Retrieved documents or procedural guidance.
Tool descriptions and schemas.
Dynamic context supplied by the application.

A system prompt remains useful, but it is not a complete control system. Important restrictions should also be enforced through code, permissions, tool design, validation, and approval gates.

🛠️ 3. Tools and Environmental Interfaces

Tools allow the agent to retrieve information or cause effects outside the model. A tool may be a local function, remote API, database operation, browser controller, command-line program, code sandbox, retrieval service, or another agent.

Each tool should have a clear contract describing:

What the tool does.
When it should be used.
Its required and optional inputs.
The structure of its output.
Its possible errors and side effects.
The permissions needed to invoke it.

Narrow, well-documented tools are generally easier for models to use reliably than large collections of overlapping or vaguely named functions.

🗂️ 4. Context and Retrieval

The model needs relevant information at the moment it makes a decision. That context may include the conversation, previous actions, tool results, documents, database records, user preferences, or application state.

Because the model’s context window is finite and expensive to process, the application usually selects, filters, summarizes, or retrieves only the information needed for the current step.

Retrieval may use keyword search, embeddings, SQL, metadata filters, knowledge graphs, document indexes, or application-specific queries. A vector database is one option, not a universal requirement.

💾 5. State and Memory

An agent needs state so it can track what has happened and what remains to be done. This is broader than simply replaying the entire conversation.

State may include:

The original objective.
Completed and pending steps.
Tool calls and their results.
Generated files or artifacts.
Current application records.
Budgets, deadlines, and step counts.
Pending approvals.
Errors and retry history.

Long-term memory is optional and should be added only when the application benefits from information surviving across sessions. Persistent information should normally be stored in an external system where it can be permissioned, corrected, audited, and deleted.

🔄 6. The Agent Runtime or Orchestrator

The runtime controls the interaction between the model and the rest of the system. It sends the current state to the model, receives a response or tool request, validates the request, executes permitted actions, records the result, and decides whether the run should continue.

A basic implementation may use a loop in Python, JavaScript, or another language. More advanced runtimes may provide:

Automatic tool-call loops.
Branching and routing.
Parallel tool execution.
Retries and timeouts.
Persistent or resumable runs.
Streaming results.
Agent handoffs.
Approval interruptions.
Tracing and evaluation hooks.

The orchestrator—not the language model—owns the authoritative execution state.

🔐 7. Identity, Permissions, and Authorization

An agent should not automatically inherit unrestricted access to the user’s accounts, files, databases, or infrastructure.

The application must determine:

Who the user is.
What the user is permitted to access.
Which permissions may be delegated to the agent.
Which records and tools are available for this task.
Whether an action is read-only or causes a side effect.
Whether additional approval is required.

These restrictions should be enforced by the tool and application layers. Telling the model “only access authorized records” is not a substitute for actual authorization checks.

🛡️ 8. Validation and Guardrails

Every boundary between the model and an external system should be treated as untrusted. The model may produce malformed arguments, select the wrong tool, misunderstand the task, or follow malicious instructions found inside retrieved content.

Guardrails may validate:

User input before the main run begins.
Tool names and arguments before execution.
Tool results before they are returned to the model.
Final outputs before they reach the user.
Whether an action violates policy or exceeds a limit.

Validation can be implemented with schemas, deterministic rules, policy engines, classifiers, additional model checks, or combinations of these methods.

👤 9. Human Approval and Escalation

Agents should pause before consequential actions when automated execution would create unacceptable risk.

Approval may be required before:

Sending an external message.
Changing or deleting important data.
Executing shell commands.
Publishing content.
Issuing a refund or making a purchase.
Deploying software.
Accessing sensitive records.
Making legal, medical, financial, or employment decisions.

A well-designed runtime can serialize the current state, pause the run, collect a decision, and then resume from the same point.

⏹️ 10. Budgets and Stopping Conditions

An agent needs explicit boundaries around how long it may operate and how many resources it may consume.

Typical limits include:

Maximum model calls or tool calls.
Maximum run duration.
Token or monetary budgets.
Maximum retries per action.
Maximum number of delegated subtasks.
Deadlines and cancellation signals.
Conditions that require human escalation.

Without stopping conditions, an agent can enter repetitive loops, repeatedly call an unavailable tool, or consume far more compute than the task justifies.

📊 11. Observability and Evaluation

Production agents need records of what happened during each run. This usually includes model calls, tool calls, inputs, outputs, errors, state transitions, approvals, latency, cost, and the final outcome.

Tracing helps developers understand an individual failure. Evaluations measure how frequently the system succeeds across a representative set of tasks.

Useful measures include:

End-to-end task completion.
Correct tool selection.
Valid tool arguments.
Unnecessary actions and retries.
Error-recovery rate.
Policy compliance.
Latency and cost per successful task.
Frequency of human intervention.

The Model Is Not Literally the Entire “Brain”

It is common to describe the model as the agent’s brain, the tools as its hands, and the orchestrator as its nervous system. These metaphors can be helpful initially, but they can also obscure where control actually resides.

The model is a probabilistic decision component. The runtime, application code, tools, databases, authorization system, and human operators jointly determine the behaviour of the complete agent.

For example, the model may propose:

{
"tool": "issue_refund",
"arguments": {
"order_id": "A-1041",
"amount": 250
}
}

The application must still verify:

That the order exists.
That the authenticated user owns or can manage it.
That the amount is valid.
That the refund complies with policy.
That the agent is permitted to issue refunds.
That the value does not exceed an approval threshold.

The tool call is a proposal until the surrounding system accepts and executes it.

🔐 The Model Is Not the Security Boundary

Prompts influence model behaviour, but permissions and policy must be enforced outside the model. An agent should be unable—not merely instructed not—to perform unauthorized actions.

From System Prompts to Layered Instructions

Earlier agent implementations often placed nearly everything in one large system prompt: the role, workflow, tool syntax, safety rules, examples, and formatting requirements.

Modern systems usually distribute these responsibilities across several layers:

Developer instructions: High-level role, constraints, and behavioural guidance.
Tool schemas: Machine-readable descriptions of available actions.
Application policy: Deterministic rules enforced outside the model.
Retrieved context: Task-specific documents, records, or procedures.
Output schemas: The structure expected from a particular step.
Guardrails: Validation before and after model and tool operations.
Permissions: The actual resources and actions available during the run.

This separation makes the system easier to test and reduces dependence on a single enormous prompt.

The Tool Contract

A tool is more than a Python function. It is a contract between the model, the runtime, and an external capability.

A well-designed tool should have:

A precise name: For example, get_order_status rather than order_tool.
A clear description: Explain when the tool should and should not be used.
A constrained input schema: Use enums, required fields, formats, and numerical limits where possible.
A structured output: Return predictable fields rather than a large block of ambiguous text.
Typed errors: Distinguish authorization failures, missing records, validation errors, and temporary service failures.
Defined side effects: Make it obvious whether the tool reads information or modifies the environment.
Idempotency where possible: Repeating a call should not accidentally repeat a payment, message, or destructive action.

Read Tools and Write Tools

It is useful to distinguish between tools that retrieve information and tools that create side effects.

Read tools: Search documents, retrieve records, inspect files, or check a status.
Write tools: Send messages, update records, modify files, execute transactions, or deploy software.

Write tools usually require stricter validation, narrower permissions, audit logging, and human approval.

The Parsing Problem Has Changed

Early agents frequently asked the model to emit conventions such as:

ACTION: Search("current weather in London")

The application then used regular expressions or string matching to determine whether the model had requested a tool. This was fragile because the model might add commentary, change punctuation, misspell the tool name, or generate invalid syntax.

Modern model APIs commonly support tool calling or function calling. Instead of expressing the action as prose, the model returns a structured request associated with a declared tool.

A simplified request might resemble:

{
"name": "get_weather",
"arguments": {
"location": "London",
"unit": "celsius"
}
}

The normal tool-calling flow is:

The application sends the model a list of available tool definitions.
The model returns either a user-facing answer or one or more tool requests.
The application validates each request.
The application executes approved tools.
The results are returned to the model.
The model decides whether to answer, call another tool, pause, or stop.

This is substantially more reliable than free-form text parsing, but it does not eliminate errors.

Structured Output Does Not Mean Guaranteed Correctness

A model may produce syntactically valid JSON while still supplying the wrong value, choosing the wrong tool, misunderstanding a field, or requesting an unauthorized action.

Validation should occur at several levels:

Syntax: Is the output valid JSON or another required format?
Schema: Are all required fields present and correctly typed?
Semantics: Do the values make sense for this operation?
Authorization: Is the action allowed for this user and agent?
Business rules: Does the request comply with policy?
Safety: Could the action cause unacceptable harm?

For example, a schema can confirm that a refund amount is a number. It cannot by itself determine whether that amount is permitted under company policy.

✅ Parse, Validate, Authorize, Then Execute

Never execute a tool merely because the model returned valid structured arguments. Treat model output as untrusted input and pass it through the same validation and authorization standards applied to any external request.

Tool Outputs Also Need Structure

Tool results should be designed for both the model and the application. Returning a large, unstructured block of text can make it difficult for the model to identify the important result or distinguish data from instructions.

A useful tool response might include:

{
"status": "success",
"order_id": "A-1041",
"shipping_status": "in_transit",
"estimated_delivery": "2026-08-08",
"source": "fulfilment_system",
"retrieved_at": "2026-08-06T15:15:00Z"
}

Structured outputs make it easier to:

Validate the result.
Display selected fields to the user.
Record the result in an audit log.
Use the result in deterministic application logic.
Reduce ambiguity for the next model call.

When a tool returns documents, web pages, emails, or user-generated content, that content should be treated as potentially untrusted. Text inside a retrieved document must not automatically override the agent’s governing instructions.

State Is More Than Conversation History

Replaying the complete conversation on every model call is a simple form of state management, but it becomes expensive and unreliable as tasks grow.

A more robust agent separates several categories of state:

Conversation state: What the user and agent have said.
Execution state: Current step, tool calls, results, errors, and pending actions.
Domain state: The authoritative records in business systems.
Retrieved context: Information selected for the current decision.
Persistent memory: Approved facts or preferences retained across runs.
Audit state: The immutable record of what the system attempted and completed.

The context supplied to the model is a temporary representation of relevant state. It should not be treated as the authoritative database.

Memory Requires a Lifecycle

Long-term memory should not simply save every model message to a vector database. A production memory system needs rules governing:

What information may be stored.
Who can retrieve it.
How long it is retained.
How conflicting information is resolved.
How users can inspect, correct, or delete it.
How sensitive information is protected.
How stale information is detected.

In many applications, ordinary structured storage is more useful than semantic vector retrieval. Customer details belong in a customer database; permissions belong in an identity system; task status belongs in a workflow store; and searchable documents may belong in a retrieval index.

A Simplified Agent Runtime

Conceptually, an agent runtime may follow logic like this:

state = initialise_run(user_request)

while not state.finished:
context = build_relevant_context(state)
response = call_model(context, available_tools)

if response.contains_tool_calls:
for call in response.tool_calls:
validate_schema(call)
authorize_action(call, state.user, state.permissions)
apply_policy_checks(call)

if requires_human_approval(call):
state = pause_for_approval(state, call)
break

result = execute_tool_with_timeout(call)
state.record(call, result)

else:
final_output = validate_final_output(response)
state.finish(final_output)

enforce_step_time_and_cost_limits(state)

This is only a conceptual example. Real systems must also handle concurrency, partial failures, cancellations, credentials, retries, idempotency, streaming, persistence, rate limits, and unavailable services.

Agent Frameworks and SDKs

Agent frameworks can provide reusable components such as tool wrappers, model adapters, state management, handoffs, tracing, approval flows, and evaluation hooks.

Examples of architecture categories include:

Model API with custom orchestration: Your application directly manages the tool loop and state.
Agent SDK: A library manages common runtime behaviour while your application supplies tools, policies, and storage.
Graph or workflow runtime: Execution is represented as nodes, transitions, and resumable state.
Multi-agent framework: Several specialized agents communicate or delegate tasks.
Hosted agent platform: The provider manages parts of the runtime, tools, tracing, or deployment environment.

A framework does not remove the need to understand the underlying architecture. It packages choices about loops, state, retries, tool execution, and control flow. Those choices still need to match the requirements of your application.

Protocols Such as MCP

The Model Context Protocol, or MCP, provides a standardized way for AI applications to connect to external capabilities and context providers.

An MCP server may expose:

Tools: Actions that a client can invoke.
Resources: Data or content that a client can read.
Prompts: Reusable prompt templates or workflow entry points.

This can reduce the amount of custom integration code needed to connect different AI clients and services. However, MCP is a communication protocol, not a complete agent architecture.

The host application still decides:

Which servers may be connected.
Which tools and resources are exposed to the model.
How credentials are managed.
What requires user consent.
Which tool calls need approval.
How returned content is validated.
How prompt injection and untrusted servers are handled.

🔌 Standardized Connectivity Is Not Automatic Trust

A tool becoming easier to connect does not make it safe to invoke. Protocol-level compatibility and application-level authorization are separate concerns.

Single-Agent and Multi-Agent Orchestration

Some systems use a single agent with several tools. Others divide work among specialized agents with different instructions, tools, or policies.

Two common multi-agent patterns are:

Handoff: One agent transfers control of the current interaction to a specialist.
Agent as a tool: A coordinating agent retains control and calls a specialist as a bounded subroutine.

Multi-agent systems may be appropriate when different parts of the task genuinely require distinct expertise, permissions, context, or policies. They also add cost, latency, coordination problems, and additional failure points.

Do not use several agents when one agent with a small, clear toolset—or a deterministic workflow—would solve the task more reliably.

Planning Is Optional

An agent does not always need to produce a complete plan before taking its first action.

Common control patterns include:

Direct action: Select the next tool immediately.
Plan then execute: Generate a multi-step plan before beginning.
Rolling planning: Plan only the next few steps and revise after each observation.
Deterministic workflow with agentic branches: Use fixed control flow while allowing the model to decide selected steps.
Evaluator–optimizer: Generate a result, evaluate it, and revise until it meets a criterion or limit.

Explicit plans can improve transparency and coordination, but long model-generated plans may become obsolete as soon as the environment returns unexpected information.

Reliability Comes From the System

A capable model cannot compensate for poorly designed tools, missing permissions, stale data, ambiguous objectives, or absent failure handling.

Reliable agent systems typically use:

Small and clearly differentiated toolsets.
Structured inputs and outputs.
Deterministic validation.
Least-privilege access.
Timeouts and retry policies.
Idempotent write operations.
Human review for consequential actions.
Persistent and resumable state.
Tracing and representative evaluations.
Explicit limits and stopping conditions.

The goal is not to make the model incapable of mistakes. The goal is to ensure that mistakes are detected, contained, recoverable, and prevented from causing unacceptable effects.

A Minimum Viable Agent

For a low-risk prototype, the minimum architecture may contain:

A suitable model.
Clear task instructions.
One or two narrow, read-only tools.
A runtime that manages the tool loop.
Structured tool inputs and outputs.
A maximum number of steps.
Basic logging.

This may be enough to demonstrate the behaviour of an agent without prematurely introducing persistent memory, multiple models, complex planning, or write access.

A Production-Ready Agent

A production deployment will commonly add:

User authentication and authorization.
Per-tool permissions.
Input, tool, and output guardrails.
Human approval for sensitive actions.
Durable state and resumable runs.
Timeout, retry, and cancellation handling.
Idempotency and transaction controls.
Prompt-injection defences.
Audit logs and distributed tracing.
Offline and continuous evaluations.
Cost, latency, and token monitoring.
Incident-response and rollback procedures.

🏗️ The Complete Formula

A practical agent is not simply:

Model + Prompt + Tools

A more complete representation is:

Model + Instructions + Context + Tools + State + Runtime + Permissions + Validation + Human Oversight + Observability

Questions to Answer Before Building

What exact outcome should the system produce?
Why does the task require model-driven control rather than a fixed workflow?
Which tools and data sources are genuinely necessary?
Which actions are read-only, reversible, or irreversible?
What authority is delegated to the agent?
Which decisions require human approval?
How will the system know that the task is complete?
What are the time, step, token, and spending limits?
How will failed or interrupted runs be resumed?
How will the complete trajectory be logged and evaluated?
What happens when a tool fails or returns conflicting information?
How will prompt injection and malicious content be handled?