Agent state-management architecture
Decide which state is authoritative and how concurrent updates are resolved
When agent state is distributed across sessions, stores, and tools, this area becomes relevant. For the application architecture owner, the concern is specific: different components act on incompatible versions of the same task. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. State design should describe meaning, not only storage technology. Identify which values are observations, tentative plans, approved decisions, and committed effects, and specify who may transition each value between those states.
The engineering decisions relationship
- State entities
Establish the basis for state ownership.
- Version conflict
Detect overlapping agent and human updates.
- State model
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around state ownership
Questions and the evidence they need
- State ownership
- Inspect state entities for the relevant constraint or observation.
- Version conflict
- Inspect write paths for the relevant constraint or observation.
- Reconciliation rule
- Inspect consistency and ownership expectations for the relevant constraint or observation.
For the application architecture owner, this becomes relevant when agent state is distributed across sessions, stores, and tools. The immediate decision is which state is authoritative and how concurrent updates are resolved. 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 different components act on incompatible versions of the same task. 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
Concurrent state changes need an authoritative resolution rule
Relationships within engineering decisions
- State ownership
- Name the system that determines each business fact.
- Version conflict
- Detect overlapping agent and human updates.
- Reconciliation rule
- Handle delayed tool results against the current record.
Version conflicts
For this scope, version conflicts should be examined alongside state entities. Identify concurrent writers and the state each may change. Version and conflict rules should preserve a distinction between user intent, agent plans, approved decisions, and observed effects. The design should not resolve every conflict by allowing whichever write arrives last to become authoritative.
Session boundaries
For this scope, session boundaries should be examined alongside write paths. Define session and task boundaries for state reuse. Information useful in one task may be stale or unauthorised in another. The architecture should specify what can persist, what must be refreshed, and which transitions require a new decision before the agent continues.
Source-of-truth reconciliation
For this scope, source-of-truth reconciliation should be examined alongside consistency and ownership expectations. Reconcile local state with authoritative external records when outcomes are uncertain. A delayed tool response can conflict with later human work. The proposed model should expose the disagreement and provide a resolution path rather than silently overwrite a valid newer decision.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for state ownership
Illustrative working format
- State entities
- Identify provenance and the specific decision this material can inform.
- Write paths
- Check its relationship to the relevant workflow and expose missing context.
- Consistency and ownership expectations
- Confirm the applicable revision and who resolves disputed interpretation.
The starting material is state entities, write paths, and consistency and ownership expectations. 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 state ownership through to an accountable finding
From the scoped material to a decision record
- State entities
Make the component and operating boundary explicit.
- Version conflict
Apply the scoped check to reconciliation rule.
- State model
Record the evidence, open dependencies, and the owner’s next decision.
Create a state transition table with allowed writers and version expectations. Distinguish a user’s request from an agent’s interpretation and an approved action from an observed result. The proposed concurrency design should explain how conflicting writes are detected and how the workflow avoids silently treating a stale value as current authority.
A practical first slice would focus on version conflicts and then follow its consequences into session boundaries. Keep source-of-truth reconciliation 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 state model usable by its owner
State model
Illustrative working format
- State model
- Identify the assessed workflow, revision, and decision boundary.
- Concurrency and ownership rules
- Name the role, decision right, handoff, and unresolved ownership boundary.
- State consistency cases
- Name the unresolved condition, next action, and accountable owner.
Indicative outputs include state model, concurrency and ownership rules, and state consistency cases. 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
Examine reconciliation rule through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- State ownership
A person edits a case while an asynchronous agent response arrives.
- Version conflict
Apply the delayed tool result against the person's newer case revision.
- Reconciliation rule
Resolve the conflict using the explicit source-of-truth and ownership rules.
Consider an illustrative situation in which an agent and a human editor update a case while an asynchronous tool response arrives. This is a constructed example, not a client engagement or an observed Softlander outcome.
For simultaneous human and agent edits, an illustrative test would delay a tool response until after the human changes the case. The system should apply its stated conflict rule rather than overwrite the newer decision automatically. The architecture owner can then judge whether state reconciliation is explicit enough for the business consequence.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves source-of-truth reconciliation 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
- State ownership
- This review is limited to the defined workflow and configuration.
- State entities
- The relevant owner must confirm access and the intended operating conditions.
- State model
- 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.