Agentic system architecture and engineering
Design the agent as an operated system.
Prompts, tools, memory and orchestration need an architecture that people can understand and maintain. Connect the execution path to authority, observability, recovery and ownership from the start.
Design the agent as an operated system
- Workflow contract
- Defines success, permitted actions and human decisions.
- Execution graph
- Connects planner, tools, memory and dependency calls.
- Control plane
- Places identity, limits, approval and configuration ownership.
- Operating evidence
- Captures state, failures and recovery for the receiving team.
Discipline model
The surrounding system determines what the agent can do
The relationships that define the discipline
- Workflow contract
- The task contract connects business success to allowed system behaviour.
- Execution graph
- Component interfaces determine how plans become reads, writes and handoffs.
- Control plane
- Controls constrain that execution across identities and environments.
- Operating evidence
- Traces and operating procedures let the owner diagnose and recover the workflow.
Agent engineering joins model behaviour to conventional software responsibilities. The surrounding system decides which data is available, how tools are invoked, what state survives and who receives a failure. Architecture should expose those decisions. A complex multi-agent design is useful only where its coordination and operational costs are justified by the workflow.
Illustrative situation
Partial completion changes what a retry should mean
A constructed situation to reason through
Illustrative scenario
- Partial execution
An agent updates one system before a second tool fails.
- State uncertainty
A retry could repeat the completed write.
- Design decision
Define action identity, compensation and escalation before resuming.
Use this situation to identify the evidence that would change the decision. The proposed examination must stay within the agreed scope, and any conclusion must describe the conditions actually inspected.
Working approach
Build recovery and operating evidence into the design
Proposed investigation sequence
- Define workflow contract
State the decision and conditions the work must address.
- Map execution graph
Connect the relevant actors, configuration and evidence.
- Examine control plane
Use agreed evidence and controlled cases where appropriate.
- Review operating evidence
Record limits, ownership and the condition for a next decision.
Begin with the workflow contract and its failure conditions. Design component interfaces, state transitions and authority boundaries, then implement a bounded path with evaluation and operational evidence alongside it. Make retries, idempotency, cancellation and rollback explicit where actions have side effects. Transfer the implementation with the tests and runbooks needed to maintain it.
Working artefact
Explain the architecture choice to the receiving owner
Illustrative working record
Illustrative working format
- Workflow contract
- Define the subject and the requirement the record addresses.
- Evidence reference
- Link source, version and observed condition without copying sensitive material.
- Control plane
- Explain the finding or choice and its consequence.
- Operating evidence
- Assign the next action and state what remains unresolved.
An architecture decision record should compare options using the same constraints: task behaviour, integration access, state, controls and operability. Record the chosen boundary, rationale and unresolved dependencies. An operating handover should then show how an owner detects a failure, follows its trace and acts without reverse-engineering the entire system.
Scope and next decision
Implementation needs access and a maintenance owner
Prepare a bounded next discussion
- Workflow contract
- Bring one concrete workflow question and its accountable owner.
- Execution graph
- Identify the evidence and access that can be made available.
- Control plane
- Agree the specialist involvement and responsibilities required.
- Written scope
- Confirm activities, evidence, readiness and acceptance before commitment.
Engineering scope depends on authorised repository and environment access, customer architecture constraints and a receiving owner. A prototype is not evidence of production readiness. Infrastructure operation and ongoing support require a separately agreed responsibility.
Explore the discipline
Specialist areas within this capability
Choose a question to explore its methods, boundaries and indicative outputs.
- Agent architecture design
- Multi-agent system engineering
- Agent orchestration design
- Context engineering
- Memory-system engineering
- Tool and connector engineering
- Model-routing architecture
- Human-in-the-loop workflow design
- Durable agent workflow engineering
- Agent rollback and recovery design
- Agent state-management architecture
- Agent observability architecture
- Agent permission and authority design
- Agent sandbox integration
- Long-running agent engineering
- Agent testing infrastructure
- Agent control-plane design
- Agent deployment architecture
- Production-readiness engineering
- Forward-deployed agent engineering
Related services
AI Fractional Agentic AI Office
Create a regular place for agentic AI decisions. Connect initiative priorities, architecture questions, risk ownership and evidence reviews.
AI Fractional Agentic Transformation Office
Coordinate the operating changes behind agent adoption. Align workflow redesign, ownership, dependencies and adoption measures.
AI Harness Engineering Pod
Engineer a bounded AI execution harness with tool adapters, context handling, orchestration, recovery and observable traces.
AI Harness Integration Pod
Integrate an AI harness into existing systems with bounded tool access, context interfaces, failure handling and ownership handover.
AI Retrieval Evaluation
Find why the right evidence is missing from an agent’s answer. Evaluate retrieval, grounding and context assembly against representative tasks.
AI Orchestration Reliability Review
Follow the work across agents and tools. Examine routing, delegation, retries and recovery where coordination can fail.
AI Continuous Agent Assurance
Keep evidence aligned with change. Define recurring checks for the models, prompts, tools and workflows your agents depend on.
AI Production Agent Assurance
Review the evidence needed to operate a specific agent workflow, from release criteria to monitoring, escalation and rollback.
Relevant insights
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Do you need an agent centre of excellence?
A centre can concentrate scarce expertise and reusable controls, or become an approval queue detached from real work. Choose the mandate before the structure.
A quarterly watchlist for agentic AI leaders
A useful quarterly watchlist tracks changes that could alter real decisions: system authority, evidence, incidents, standards, providers and organisational readiness.