Agent architecture design
Decide which architecture separates reasoning, tools, state, and business authority
When a prototype must become an operable agent workflow, this area becomes relevant. For the principal engineer or platform architect, the concern is specific: the architecture diagram hides which component may commit an external change. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. Begin with a sequence of business decisions before selecting an agent framework. A useful architecture makes it possible to explain where information becomes an instruction and where an instruction becomes an authorised external effect.
The engineering decisions relationship
- Workflow requirements
Establish the basis for reasoning component.
- Tool boundary
Enforce the permissions for consequential operations.
- Architecture decision record
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around reasoning component
Questions and the evidence they need
- Reasoning component
- Inspect workflow requirements for the relevant constraint or observation.
- Tool boundary
- Inspect system interfaces for the relevant constraint or observation.
- State owner
- Inspect consequential action inventory for the relevant constraint or observation.
For the principal engineer or platform architect, this becomes relevant when a prototype must become an operable agent workflow. The immediate decision is which architecture separates reasoning, tools, state, and business authority. The scope should be narrow enough that the engineering team can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that the architecture diagram hides which component may commit an external change. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Separate reasoning from authority to change business state
Relationships within engineering decisions
- Reasoning component
- Assemble facts and proposed next actions.
- Tool boundary
- Enforce the permissions for consequential operations.
- State owner
- Define completion and operating responsibility.
Component boundaries
For this scope, component boundaries should be examined alongside workflow requirements. Separate evidence gathering, reasoning, authorisation, execution, and effect verification in the proposed architecture. A component boundary should correspond to a responsibility the team can explain and test. Selecting a framework comes after establishing which business decisions and trust transitions the deployment must support.
Failure containment
For this scope, failure containment should be examined alongside system interfaces. Locate where a local failure could become an external business effect. The design should preserve uncertainty and define which component contains or escalates it. A model’s fluent explanation should not be the only evidence that a prerequisite or approval was satisfied.
Operational ownership
For this scope, operational ownership should be examined alongside consequential action inventory. Assign operation and maintenance responsibilities to actual roles. Identify who changes prompts, tools, policies, and state, and who can suspend the workflow. The architecture should remain understandable after handover, including which assumptions depend on other teams or providers.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for reasoning component
Illustrative working format
- Workflow requirements
- Confirm the applicable revision and who resolves disputed interpretation.
- System interfaces
- Match this description to the deployed or proposed boundary being examined.
- Consequential action inventory
- Match this description to the deployed or proposed boundary being examined.
The starting material is workflow requirements, system interfaces, and consequential action inventory. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a workflow owner, an implementation lead, an eventual maintainer, and qualified control reviewers where needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry reasoning component through to an accountable finding
From the scoped material to a decision record
- Workflow requirements
Make the component and operating boundary explicit.
- Tool boundary
Apply the scoped check to state owner.
- Architecture decision record
Record the evidence, open dependencies, and the owner’s next decision.
Start with a sequence showing evidence gathering, planning, authorisation, execution, and effect verification. Assign each responsibility to a component or person and mark where trust changes. The proposed architecture review should challenge boundaries that depend solely on an agent’s narrative instead of an observable system state or enforceable control.
A practical first slice would focus on component boundaries and then follow its consequences into failure containment. Keep operational ownership visible as a separate review question rather than assuming it is satisfied by the first result. The engineering team should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the architecture decision record usable by its owner
Architecture decision record
Illustrative working format
- Architecture decision record
- Identify the assessed workflow, revision, and decision boundary.
- Trust and responsibility map
- Name the role, decision right, handoff, and unresolved ownership boundary.
- Validation backlog
- Name the missing evidence, responsible owner, and condition for revisiting the decision.
Indicative outputs include architecture decision record, trust and responsibility map, and validation backlog. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Approval should remain bound to the final account update
An update changes after approval
Illustrative scenario
- Draft and account action
A support agent gathers facts and drafts a response; updating the account needs separate approval.
- Altered approved update
Change the proposed update after approval and inspect whether authorisation must be renewed.
- Approval binding
Require approval for the final action; keep unresolved operating ownership as a next-step dependency.
Consider an illustrative situation in which a support agent must gather account facts, propose a response, and request approval before updating a record. This is a constructed example, not a client engagement or an observed Softlander outcome.
In the support example, a useful design would let the response draft evolve without granting permission to update the account. The illustrative validation would alter the proposed update after approval and inspect whether authorisation must be renewed. This makes the architecture decision concrete: where should approval bind to the final action?
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves operational ownership unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the defined workflow and configuration
Confirm fit before the next commitment
- Reasoning component
- This review is limited to the defined workflow and configuration.
- Workflow requirements
- The relevant owner must confirm access and the intended operating conditions.
- Architecture decision record
- Production acceptance needs separate scoped evidence.
The method described here is proposed engineering work. Scope, staffing, implementation access, acceptance, and commercial terms require a readiness review. A design or lab result does not establish production suitability, guaranteed reliability, or security certification.
Ways to engage
Related engagement scopes
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.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
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.