# Agent-First Architecture: A Practical Reference Model

> Canonical: https://auxfirst.com/agent-first-architecture.html
> License: CC BY 4.0 · auxfirst agency 2026

> Pillar guide · The agent-first series · 02

**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 can select and perform actions within a defined scope, while the surrounding system controls access, records outcomes and provides routes for human intervention.

This changes what an architecture needs to make explicit. Alongside application components and data flows, teams must define who delegated the work, which actions are permitted, how execution survives failure and what evidence demonstrates that the task was completed.

By **Emil Krzemiński**, founder of auxfirst · Published 13 September 2026 · Reference model · ~16 minutes · Last reviewed September 2026 · Series 02 of 04 · Architecture

> **The short answer**
>
> 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.

## 01 · 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 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.

> **What the term is not**
>
> “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](https://auxfirst.com/agent-first-design.html) decides what work an agent should do and how people supervise it. This guide makes those decisions enforceable. An [agent-first platform](https://auxfirst.com/agent-first-platform.html) supplies the capabilities the agent operates. And the [AI agent development lifecycle](https://auxfirst.com/agent-development-lifecycle.html) keeps the system working as it changes.

## 02 · What 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.

## 03 · Traditional, 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 |

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.

## 04 · The 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.

#### Figure 1 · The auxfirst Agent-First Reference Architecture

**Execution path — five areas carry the delegated work, left to right**

- **01 · Delegation & intent** — Goal · Scope · Completion criteria · Trigger · Budget
- **02 · Runtime & orchestration** — Model and instructions · Action loop · Routing · Limits, stop conditions
- **03 · Context & state** — Task context · retrieval · Run state · memory if needed (exchanges information with the runtime)
- **04 · Tools & interfaces** — APIs, functions, contracts · MCP where useful (called by the runtime)
- **06 · Execution & systems** — CRM, databases · Code · External services · Durable jobs

**Cross-cutting — three areas touch every stage**

| Area | At delegation | At runtime | At context and tools | At execution |
|---|---|---|---|---|
| 07 · Human supervision | delegates, sets limits | can interrupt any run | approves specific actions | revokes · takes escalations |
| 05 · Identity & authority | records who delegated | agent's own identity | scope enforced at each tool call | limits held in the system |
| 08 · Evidence & evaluation | completion checked | run log: steps, stops | calls, parameters, results | changes, action receipts |

Five areas carry the work from delegation to the systems where its effects land; three cut across all of them. An analytical model — not eight services, and not a sequence.

*Figure 1 · The auxfirst Agent-First Reference Architecture. Five areas carry the work from delegation to the systems where its effects land; identity and authority, human supervision, and evidence and evaluation cut across all of them. An analytical model, not a service map.*

What each area answers, and what it has to make explicit:

#### Area 01 · Delegation and intent

*What work was delegated?* 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.

#### Area 02 · Runtime and orchestration

*How is the work carried out?* 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.

#### Area 03 · Context and state

*What information and state does the work need?* 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.

#### Area 04 · Tools and interfaces

*How does the agent act?* APIs, functions and tool contracts: what each tool does, what it accepts, what it returns and what it may change. The [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28) is one way to expose tools; the contract matters more than the transport.

#### Area 05 · Identity and authority (cross-cutting)

*Who granted permission, and for what?* The agent's own identity, an access scope derived from whoever delegated the work, policy enforcement and hard limits. [OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693.html) is one standard way to express acting on someone's behalf. Enforcement sits where actions execute, so a persuasive prompt cannot widen it.

#### Area 06 · Execution and systems

*Where do effects occur?* 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.

#### Area 07 · Human supervision (cross-cutting)

*When does a person decide?* 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](https://auxfirst.com/agent-owners-manual.html).

#### Area 08 · Evidence and evaluation (cross-cutting)

*How do we know what happened?* 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](https://github.com/open-telemetry/semantic-conventions-genai) are one vendor-neutral way to capture them.

### Seven distinctions the model depends on

1. **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.
2. **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.
3. **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.
4. **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.
5. **Prevent duplicate writes.** Where an interface supports them, [idempotency keys](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/) let a retried request return the original result instead of creating a second record — [Stripe's API](https://docs.stripe.com/api/idempotent_requests) is a widely used example.
6. **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](https://genai.owasp.org/llmrisk/llm01-prompt-injection/).
7. **Supervision starts before the action.** Controls that only review results arrive too late for anything irreversible.

## 05 · Authority, 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](https://auxfirst.com/action-heat-ladder.html) — reversibility, blast radius, exposure, commitment and authority — and the grade decides the path the action takes.

#### Figure 2 · Authority and approval flow

1. **Proposed action** — a tool call with exact parameters.
2. **Policy check, outside the model** — agent identity · delegated scope · limits and budget · action parameters · consequence grade.
3. **Three outcomes:**
   - **Allowed** — within scope → execute with an idempotency key → confirm the effect in the system of record → action receipt (id · authority · result).
   - **Needs approval** — bound to this action, its parameters and an expiry → approved: execute as above · rejected or expired: not executed.
   - **Denied** — outside delegation → not executed: recorded, escalated.
4. **Timeout or unknown result?** Check the target system's state first, and retry only with the same idempotency key.

*Figure 2 · Authority and approval flow. The policy check runs outside the model, against the agent's identity and the parameters of this specific action. An approval is bound to that action and expires; a timeout triggers a status check, not a blind retry.*

- **Allowed.** The action runs within the agent's scope — creating an internal task, for example — and still produces a receipt.
- **Needs approval.** 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.
- **Denied.** 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](https://genai.owasp.org/llmrisk/llm062025-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](https://artificialintelligenceact.eu/article/14/) 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:

| | Case | What it means | Example |
|---|---|---|---|
| 01 · Easiest | Cancel | Stop the action before it takes effect. | withdraw a queued message |
| 02 | Rollback | Restore a previous state or version. | revert a record or a configuration |
| 03 | Compensating action | Offset the effect with a new action. | issue a refund, send a correction |
| 04 · Hardest | Irreversible | The effect cannot be taken back. | a message read, a payment settled |

← easier to undo · the control has to act earlier →

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](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction) 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.

## 06 · Single-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](https://www.anthropic.com/engineering/building-effective-agents) and increasing complexity only when needed, and OpenAI's [practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf) recommends maximizing a single agent's capabilities before splitting the work.

**Start with one agent when**

- 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.

**Consider several agents when**

- 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.

## 07 · Practical 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.

- **Pattern 01 · Explicit delegation boundary** — State the goal, the scope and the condition for completion before the run starts. *Use it always — it is the contract every other pattern refers to.*
- **Pattern 02 · Controlled tool access** — Enforce permitted operations in the tool or the system behind it, not in the prompt. *Use it whenever the agent can write, send, spend or delete.*
- **Pattern 03 · Approval before consequential action** — Show the approver the exact action and parameters before anything executes. *Use it when an action is external, costly or hard to reverse.*
- **Pattern 04 · Action receipts** — Record an action identifier, the result and the confirmed effect for each consequential action. *Use it wherever someone may later need to prove what happened.*
- **Pattern 05 · Progressive autonomy** — Widen the agent's scope only when evaluated results justify it, and narrow it again when they do not. *Use it for new agents and for rising stakes.*
- **Pattern 06 · Recovery and escalation** — Define behavior for errors, uncertainty and partial completion, including who receives the escalation. *Use it for any run that can fail halfway — which is every run.*

The interface side of the same ideas — approval queues, activity streams, escape hatches — is cataloged in [Agent-First Design Patterns](https://auxfirst.com/agent-first-design-patterns.html).

## 08 · Worked example: a revenue operations agent

*Illustrative example · a hypothetical scenario, not a client case study*

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.

#### Figure 3 · One run of the revenue operations agent

| Step | What happens | Where | Boundary |
|---|---|---|---|
| 01 | A CRM change or the daily schedule starts the run. | System | Trigger |
| 02 | The agent retrieves the opportunity, its owner and the activities it is allowed to create. | Agent · CRM | Read |
| 03 | It checks the stall criteria and whether the data is complete enough to act on. | Agent | Read |
| 04 | It reviews the available context of recent interactions. | Agent | Read |
| 05 | It prepares a recommendation that cites the records it relied on. | Agent | No side effects |
| 06 | It creates an internal follow-up task, because that is within its granted permissions. | CRM | Allowed write |
| 07 | A message to the customer goes to the opportunity owner for approval. | Person | Needs approval |
| 08 | The system records each operation and its result. | System | Evidence |
| 09 | An error, a missing owner or conflicting data sends the case to the RevOps lead. | Person | Escalation |
| 10 | A sample of results goes to later quality review. | Person | Evaluation |

*Figure 3 · One run of the revenue operations agent. Each step is tagged by where it happens and what it is allowed to do.*

### 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 |

> **One failure path · step 06 times out**
>
> 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.

## 09 · Architecture 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](https://auxfirst.com/agent-operability-audit.html).

## 10 · Frequently 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.

## 11 · Terms 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.

## 12 · Sources and further reading

**Standards and guidance cited on this page**

- Anthropic — [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) (December 2024): start with the simplest solution; workflows versus agents
- OpenAI — [A practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf): maximize a single agent before splitting the work
- OWASP GenAI Security Project — [LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/): minimal functionality and permissions, human approval, authorization in downstream systems
- OWASP GenAI Security Project — [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/): why retrieved content must not carry authority
- IETF — [RFC 8693: OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693.html): one party acting on behalf of another
- IETF — [The Idempotency-Key HTTP Header Field](https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/) (Internet-Draft): making retried write requests safe
- Stripe — [Idempotent requests](https://docs.stripe.com/api/idempotent_requests): a widely used implementation of idempotency keys
- Microsoft Azure Architecture Center — [Compensating Transaction pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction)
- [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2026-07-28), version 2026-07-28: resources, prompts and tools, and the security principles the protocol leaves to implementors
- OpenTelemetry — [GenAI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai): recording model, agent and tool activity as telemetry
- [EU AI Act, Article 14](https://artificialintelligenceact.eu/article/14/): human oversight of high-risk AI systems, including the ability to interrupt them
- [The C4 model](https://c4model.com/): the context, container and component views an agent architecture diagram extends

**The agent-first series**

- [Agent-first design](https://auxfirst.com/agent-first-design.html) — what to delegate, and how people supervise it
- [Agent-first platform](https://auxfirst.com/agent-first-platform.html) — the capabilities an agent needs to operate a platform
- [AI agent development lifecycle](https://auxfirst.com/agent-development-lifecycle.html) — how the system is built, released, run and retired

**Frameworks and engagements underneath**

- [the Action Heat Ladder](https://auxfirst.com/action-heat-ladder.html) — grading actions by consequence before granting autonomy
- [AI agent workflow design](https://auxfirst.com/agentic-experience-center/agent-process-design.html) — Agent Process Design: the workflow specified before the agent is built
- [AI agent operating model](https://auxfirst.com/agent-owners-manual.html) — the Agent Owner's Manual: ownership, mandate, human control and shutdown
- [Agent-First Design Patterns](https://auxfirst.com/agent-first-design-patterns.html) — the interface patterns for supervision and control
- [The Two-Layer Stack](https://auxfirst.com/news/two-layer-stack-agt-vs-aux.html) — 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](https://auxfirst.com/agentic-experience-center/agent-process-design.html).

[Discuss your agent architecture →](https://auxfirst.com/index.html#contact) · [View all engagements](https://auxfirst.com/index.html#engagements)

## The agent-first series

Design defines the scope of delegation. Architecture describes the system that performs the work. Platform describes the capabilities it operates. Lifecycle describes how it is built, run and changed.

- **01 · Design** — [Agent-First Design](https://auxfirst.com/agent-first-design.html): what work to delegate, and how people supervise, steer and override it.
- **02 · Architecture** — Agent-First Architecture (this page): the system that performs the work — runtime, context, tools, authority and evidence.
- **03 · Platform** — [What Is an Agent-First Platform?](https://auxfirst.com/agent-first-platform.html): the capabilities an agent needs to operate a platform, and a ten-question test.
- **04 · Lifecycle** — [The Agent Development Lifecycle](https://auxfirst.com/agent-development-lifecycle.html): how the system is built, evaluated, released, run and retired.

---

**Written by Emil Krzemiński** — founder of auxfirst, the agentic experience design agency. Develops the AUX discipline and the Action Heat Ladder — the frameworks for designing trust and control into AI agents that act on people's behalf — and leads every engagement personally. [LinkedIn](https://www.linkedin.com/in/emilkrzeminski/) · [About auxfirst](https://auxfirst.com/about.html) · [For AI assistants →](https://auxfirst.com/ai-info.html)

**Cite this page:** Krzemiński, E. (2026). *Agent-First Architecture: A Practical Reference Model.* auxfirst. https://auxfirst.com/agent-first-architecture.html · Published 13 September 2026