Agent-first architecture is how you build a system in which an AI agent performs delegated work inside explicit boundaries. It makes eight areas of responsibility explicit, so that the agent can act while the system decides what it may touch, records what happened and routes consequential choices to a person.
- Not full autonomy. The agent acts inside a delegation that people define, supervise and can revoke.
- Not necessarily multi-agent. One well-bounded agent is often the right design. Persistent memory and MCP are choices, not requirements.
- Permissions live in the system, not the prompt. An instruction describes a rule; enforcement makes breaking it impossible.
- Evidence, not assurance. Every consequential action leaves a record of what was attempted, under whose authority, and what actually changed.
01What is agent-first architecture?
Agent-first architecture is an approach to software architecture that organizes delegated agent work around runtime execution, context, tools, authority, evidence and human supervision. The unit it is built around is not a screen or a service call but a piece of delegated work: a goal someone handed over, with limits attached.
As auxfirst uses the term, it covers the whole system an agent operates within — how work is triggered and run, what information the agent receives, which tools it can call, where permissions are enforced, where results land, when a person decides, and how anyone can tell afterwards what happened.
“Agent-first” describes a design approach. It is not a certification, a named standard or a technology stack, and it does not mean removing the human interface. People still delegate, inspect, approve and intervene; the architecture decides where.
Each layer of the series answers a different question. Agent-first design decides what work an agent should do and how people supervise it. This guide makes those decisions enforceable. An agent-first platform supplies the capabilities the agent operates. And the AI agent development lifecycle keeps the system working as it changes.
02What changes when an agent becomes an operator?
In most software, a person or a programmed workflow decides what happens next, and the application executes. When an agent becomes an operator, part of that decision moves into the system. The agent reads the situation, chooses an action from those available to it, observes the result and decides again, until the work is done or it reaches a limit.
That does not make the agent autonomous in any absolute sense. It performs delegated work — work that a person or an organization handed over, with a goal, a scope and conditions for stopping. The delegation is the contract, and the architecture exists to keep the agent inside it.
Four things stop being implementation details and become architectural decisions:
- Who delegated the work, and with what authority. The agent acts on someone's behalf, and the system has to know whose.
- Which actions are permitted. Not in principle, but per tool, per record and per parameter.
- How execution survives failure. Requests time out, services return errors and some tasks run for hours. The system must know what already happened before it tries again.
- What evidence shows that the task was completed. A fluent summary is not evidence. A confirmed change in a system of record is.
Two assumptions are worth dropping early. Agent-first does not mean full autonomy: most useful agents act freely on some actions and ask on others. And it does not mean multi-agent: a single, well-bounded agent is often the right architecture.
03Traditional, AI-assisted and agent-first systems
The difference is easiest to see side by side. Read the table as three orientations rather than a strict classification — most real systems mix them.
| Dimension | Traditional application | AI-assisted application | Agent-first system |
|---|---|---|---|
| How work starts | A user action or a rule | A user action, a rule or a prompt | A delegated goal, an event or a schedule |
| Who chooses the next action | A person, or a programmed workflow | A person, supported by AI | The agent, within defined boundaries |
| Role of the interface | Doing and controlling the work | Doing the work with AI assistance | Delegating, inspecting, approving and intervening |
| Permissions | Application and user permissions | Application, user and tool permissions | An explicit relationship between the delegator, the agent and the actions it may take |
| Error handling | Application procedures | Procedures, plus correcting AI output | Retry, stop, escalate — and control of side effects |
↔ scroll table
None of these properties is exclusive. Traditional systems can be asynchronous, fully audited and governed by sophisticated permission models, and many are. What distinguishes an agent-first system is how it organizes delegated work: because a non-human operator chooses the actions, authority, supervision and evidence have to be designed into the runtime rather than inherited from the person in front of the screen.
04The auxfirst reference architecture
The auxfirst Agent-First Reference Architecture describes eight areas of responsibility. It is an analytical model — a way to check that nothing important has been left implicit — not an industry standard and not a diagram of eight services. One component can cover several areas, and one area can span several components. Nor are the areas a sequence: three of them cut across all the others.
What each area answers, and what it has to make explicit:
Delegation and intent
Goal, scope, completion criteria, trigger and budget. Without explicit completion criteria an agent has no principled reason to stop; without a budget it has no reason to stop early.
Runtime and orchestration
The model, its instructions and the action loop that plans, calls tools, reads results and decides again — plus routing, limits and the conditions that end a run or hand it back.
Context and state
Task context, retrieval and execution state, with long-term memory only where the workflow needs it. These are three different things, and each needs its own owner and retention rule.
Tools and interfaces
APIs, functions and tool contracts: what each tool does, what it accepts, what it returns and what it may change. The Model Context Protocol is one way to expose tools; the contract matters more than the transport.
Identity and authority
The agent's own identity, an access scope derived from whoever delegated the work, policy enforcement and hard limits. OAuth 2.0 Token Exchange is one standard way to express acting on someone's behalf. Enforcement sits where actions execute, so a persuasive prompt cannot widen it.
Execution and systems
CRM, databases, code, external services and durable jobs: the systems of record where changes land, and where timeouts, partial completion and duplicate writes actually happen.
Human supervision
Approvals of specific actions, escalations that carry the evidence, the ability to interrupt a run, and revocation of access. Ownership and shutdown sit one level up, in the AI agent operating model.
Evidence and evaluation
Tool calls, parameters, results, state changes and errors, plus the evaluations that judge outcomes. It records observable actions and effects, not the model's internal reasoning; the OpenTelemetry GenAI conventions are one vendor-neutral way to capture them.
Seven distinctions the model depends on
- Context, task state and memory are different things. Context is what the model sees on this step; task state is where this piece of work stands; memory is what persists across tasks. Merge them and agents forget their own progress, or remember what they should not.
- An instruction is not a permission. A prompt that says “never change the deal value” is a request. A tool that cannot change the deal value is a control.
- Approval attaches to an action, not a conversation. A person approves this message, to this recipient, with this content. If the parameters change, the approval does not carry over.
- After a timeout, find out before you retry. A request that never answered may still have succeeded. Check the state of the target system before sending it again.
- Prevent duplicate writes. Where an interface supports them, idempotency keys let a retried request return the original result instead of creating a second record — Stripe's API is a widely used example.
- Retrieved content is data, not authority. An email, a web page or a ticket can inform the work. It cannot grant permissions or change the delegation — the failure OWASP catalogs as prompt injection.
- Supervision starts before the action. Controls that only review results arrive too late for anything irreversible.
05Authority, supervision and failure handling
Before any proposed action runs, the architecture has to answer one question: is it allowed as it stands, allowed only with approval, or not allowed at all? auxfirst grades that consequence with the Action Heat Ladder — reversibility, blast radius, exposure, commitment and authority — and the grade decides the path the action takes.
The action runs within the agent's scope — creating an internal task, for example — and still produces a receipt.
The system prepares the exact action and its parameters for a named approver. The approval covers that action only; if anything changes, it goes back. If nobody answers in time, the request escalates instead of proceeding.
The action is outside the delegation. The agent records the refusal and, if the work cannot continue, escalates with the evidence rather than looking for another route.
This is the same logic the OWASP GenAI Security Project recommends against what it calls excessive agency: keep tools, functions and permissions to the minimum, require human approval for high-impact actions, and implement authorization in the downstream systems rather than relying on the model to decide. Interruption belongs in the same design. For high-risk systems, Article 14 of the EU AI Act requires that people can oversee the system and interrupt it through a “stop” button or a similar procedure — much easier to meet when it is designed in than when it is retrofitted.
Not every action can be undone
The architecture should not pretend otherwise. It helps to separate four cases:
The further right an action sits, the earlier its control has to act. Irreversible actions need that control before execution — approval, a hard limit or no access at all — because there is nothing to repair afterwards. Compensating transactions are a long-established pattern in distributed systems; they offset an effect, they do not erase it.
When a run fails halfway
A run can fail cleanly (the tool reports an error), ambiguously (a timeout with no answer) or partially (three of five steps done). Each needs a defined response: retry with the same idempotency key, check the target system before deciding, stop and hand over what was completed, or run a compensating action. What an agent must not do is improvise a workaround that exceeds its delegation.
06Single-agent or multi-agent?
Agent-first architecture does not require several agents. Each boundary between agents adds coordination — hand-offs, shared state, and attribution when something goes wrong — and each is a place where context is lost and authority can blur. Builder guidance points the same way: Anthropic advises finding the simplest solution possible and increasing complexity only when needed, and OpenAI's practical guide to building agents recommends maximizing a single agent's capabilities before splitting the work.
- the work is one coherent task with one set of tools;
- the same permissions apply throughout;
- the context fits comfortably in a single run;
- one person is accountable for the outcome.
- parts of the work need genuinely different tools, context or permissions;
- separation of duties is required — the agent that drafts should not approve;
- one context would grow too large or too mixed to stay reliable;
- parts of the work change or scale on different schedules.
If you do split the work, the reference model applies to each agent and to every hand-off between them: who delegated to whom, under which authority, and with what evidence passed along.
07Practical architecture patterns
Six patterns turn the model into something a team can build and review. Each names the problem it solves and when to reach for it.
Explicit delegation boundary
State the goal, the scope and the condition for completion before the run starts.
Controlled tool access
Enforce permitted operations in the tool or the system behind it, not in the prompt.
Approval before consequential action
Show the approver the exact action and parameters before anything executes.
Action receipts
Record an action identifier, the result and the confirmed effect for each consequential action.
Progressive autonomy
Widen the agent's scope only when evaluated results justify it, and narrow it again when they do not.
Recovery and escalation
Define behavior for errors, uncertainty and partial completion, including who receives the escalation.
The interface side of the same ideas — approval queues, activity streams, escape hatches — is cataloged in Agent-First Design Patterns.
08Worked example: a revenue operations agent
A revenue operations team wants an agent that finds open opportunities that have gone quiet and prepares the next step for each. The delegation: review stalled opportunities daily, recommend a next step with the data behind it, create internal follow-up tasks, and draft customer messages for the opportunity owner to approve.
- 01A CRM change or the daily schedule starts the run.SystemTrigger
- 02The agent retrieves the opportunity, its owner and the activities it is allowed to create.Agent · CRMRead
- 03It checks the stall criteria and whether the data is complete enough to act on.AgentRead
- 04It reviews the available context of recent interactions.AgentRead
- 05It prepares a recommendation that cites the records it relied on.AgentNo side effects
- 06It creates an internal follow-up task, because that is within its granted permissions.CRMAllowed write
- 07A message to the customer goes to the opportunity owner for approval.PersonNeeds approval
- 08The system records each operation and its result.SystemEvidence
- 09An error, a missing owner or conflicting data sends the case to the RevOps lead.PersonEscalation
- 10A sample of results goes to later quality review.PersonEvaluation
The boundaries of the example
| Action | What the agent may do |
|---|---|
| Read the opportunity, its owner and activity history | Yes — within the team's pipeline |
| Create an internal follow-up task | Yes — once per opportunity per stall event, using an idempotency key |
| Send a message to the customer | Only after the owner approves the exact draft |
| Change the deal value | Never |
| Close or reopen an opportunity | Never |
| Create the same task again when an event repeats | Never — the key prevents it |
The CRM does not answer the task-creation request. The agent does not retry blindly: it checks whether a task with this run's idempotency key already exists. It does — the request succeeded before the connection dropped — so the agent records the receipt and moves on. Had the status check failed too, the case would have gone to the RevOps lead with the attempted action and its parameters attached, instead of a second task being created.
On the success path, the owner sees one approval request per quiet opportunity — a draft, the evidence behind it and a single decision — while internal tasks, receipts and the evaluation sample happen without anyone having to ask.
09Architecture review checklist
Use these questions in a design review before build, or against an agent already running. Each “no” or “not sure” is a gap to close, not a verdict.
- Is the delegation written down — goal, scope, completion criteria, trigger and budget?
- Does the agent have its own identity, with a scope derived from the person or role that delegated the work?
- Are permitted operations enforced in tools or systems rather than in the prompt?
- Is every consequential action classified as allowed, approval-required or denied?
- Does an approval bind to the exact action and parameters, and does it expire?
- Are context, task state and long-term memory separated, with retention decided for each?
- Do write operations prevent duplicates, for example with idempotency keys?
- Does the system check the target state after a timeout before it retries?
- Is there a defined response to partial completion?
- Is retrieved external content treated as data, never as a source of permissions?
- Can a person interrupt a run and revoke access without redeploying?
- Does every consequential action leave a receipt that someone outside engineering can read?
For one workflow end to end, the same review is the core of an AI agent readiness assessment.
10Frequently asked questions
What is agent-first architecture?
Agent-first architecture is an approach to software architecture that organizes delegated agent work around runtime execution, context, tools, authority, evidence and human supervision. The agent chooses and performs actions within a defined scope, while the surrounding system controls access, records outcomes and gives people ways to approve, intervene and stop.
How does it differ from AI-assisted architecture?
In an AI-assisted system, a person still chooses each next action and AI helps with steps along the way. In an agent-first system, the agent chooses actions within delegated boundaries, so authority, supervision, failure handling and evidence become part of the architecture instead of being assumed from the person at the screen.
Does it require multiple agents?
No. Many workflows are best served by one well-bounded agent. Several agents make sense when parts of the work need different tools, context or permissions, or when separation of duties is required. Every hand-off adds coordination cost and a place where context and accountability can be lost.
Does every agent need persistent memory?
No. Most agents need task context and execution state, which are different from long-term memory across tasks. Persistent memory helps when the work genuinely depends on history, such as customer preferences, and it brings retention, correction and privacy decisions with it. Decide it per workflow, not by default.
Is MCP required?
No. The Model Context Protocol is one useful way to expose tools and context to agents, and it can reduce integration work. The architecture needs well-defined tool contracts, identity, permission enforcement and evidence whatever the transport, and adopting MCP does not settle any of those on its own.
Where should permissions be enforced?
Outside the model, at the point where the action is executed: in the tool, a gateway or the system of record, using the agent's own identity and a scope derived from the delegation. A prompt can describe the rules; only enforcement in the system can make an out-of-scope action impossible.
What should an agent architecture diagram show?
Beyond components and data flows: who delegated the work, where the agent's identity and permissions are checked, which actions require approval, where effects land in systems of record, where people can intervene, and what evidence each action leaves. If a diagram cannot show who approved an action and where the record is, it is incomplete.
How should a system handle failed or partially completed actions?
Classify the failure first. Retry transient errors with the same idempotency key. After a timeout, check the target system's state before retrying. For partial completion, stop, record what was done and escalate with the evidence, or run a defined compensating action. Irreversible effects need their controls before execution, not after.
11Terms used on this page
- Agent-first architecture
- An approach to software architecture that organizes delegated agent work around runtime execution, context, tools, authority, evidence and human supervision.
- Delegated work
- A goal handed to an agent by a person or an organization, with a scope, completion criteria and limits attached. The unit an agent-first architecture is built around.
- Delegation boundary
- The explicit statement of what an agent may pursue and do in a run: goal, scope, completion criteria, trigger and budget.
- Action receipt
- A record of one consequential action: an identifier, the parameters, the authority it ran under, the result and the confirmed effect in the target system.
- Idempotency key
- A unique value sent with a write request so that retrying the same request returns the original result instead of repeating the operation.
- Compensating action
- A new action that offsets the effect of an earlier one, such as a refund or a correction, when the original cannot simply be rolled back.
- Progressive autonomy
- Widening an agent's scope step by step as evaluated results justify it, and narrowing it again when they do not.
12Sources and further reading
Standards and guidance cited on this page
- Anthropic — Building effective agents (December 2024): start with the simplest solution; workflows versus agents
- OpenAI — A practical guide to building agents: maximize a single agent before splitting the work
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency: minimal functionality and permissions, human approval, authorization in downstream systems
- OWASP GenAI Security Project — LLM01:2025 Prompt Injection: why retrieved content must not carry authority
- IETF — RFC 8693: OAuth 2.0 Token Exchange: one party acting on behalf of another
- IETF — The Idempotency-Key HTTP Header Field (Internet-Draft): making retried write requests safe
- Stripe — Idempotent requests: a widely used implementation of idempotency keys
- Microsoft Azure Architecture Center — Compensating Transaction pattern
- Model Context Protocol specification, version 2026-07-28: resources, prompts and tools, and the security principles the protocol leaves to implementors
- OpenTelemetry — GenAI semantic conventions: recording model, agent and tool activity as telemetry
- EU AI Act, Article 14: human oversight of high-risk AI systems, including the ability to interrupt them
- The C4 model: the context, container and component views an agent architecture diagram extends
The agent-first series
- Agent-first design — what to delegate, and how people supervise it
- Agent-first platform — the capabilities an agent needs to operate a platform
- AI agent development lifecycle — how the system is built, released, run and retired
Frameworks and engagements underneath
- the Action Heat Ladder — grading actions by consequence before granting autonomy
- AI agent workflow design — Agent Process Design: the workflow specified before the agent is built
- AI agent operating model — the Agent Owner's Manual: ownership, mandate, human control and shutdown
- Agent-First Design Patterns — the interface patterns for supervision and control
- The Two-Layer Stack — how runtime enforcement and experience design compose
Method · This guide presents auxfirst's working model for agent-first systems. It combines established software engineering practices with our approach to delegation, authority and human supervision. The reference model is an analytical framework, not an industry standard. Product-specific examples are linked to their supporting documentation, and the revenue operations scenario is illustrative, not a client case study. External sources checked on 13 September 2026.
Planning an agentic system?
Work with auxfirst to define agent responsibilities, context, permissions and human checkpoints before implementation. For one workflow end to end, the fixed-scope engagement is AI agent workflow design.