RePerspective LabsINSIGHT
Deep Dive
AI Agents and Systems of Record: Making Changes Dependable
Connect adaptive work to authoritative records, controlled changes and accountable completion.
Executive summary
An agent can be authorized to request a change without the enterprise knowing whether that change happened. This matters when an outcome spans several systems, a response is lost, or another person updates the same record. Leaders need an architecture that identifies which system owns each business fact, defines what an action commits, and keeps incomplete work visible until it is resolved. Existing applications, workflows and integration services may already provide much of this capability. The leadership decision is where to introduce adaptive work while preserving dependable execution, staffed recovery and clear acceptance of the outcome.
The question
The request timed out but the warehouse may already have changed
Consider a hypothetical approved change to a delivery address before an order leaves the warehouse. The order system confirms its update. The fulfillment system receives the next instruction, but its response never reaches the caller.
The agent cannot tell whether the instruction failed or the warehouse record changed. Repeating the action could create a second effect. Declaring success could leave the order and warehouse working from different instructions. Meanwhile, someone must decide whether dispatch can proceed and what to tell the customer.
An authority check establishes whether the request was permitted. The operation still needs to establish what happened. That question connects enterprise architecture to an everyday business commitment: completing a change accurately, without losing track of the work when execution becomes uncertain.
My perspective
I would judge an agent architecture by how it handles an unfinished business change. The organization should be able to establish what committed, prevent conflicting work and put the remaining decision with someone able to resolve it. That is where Adaptation and Control meet: flexible contributions to the work, supported by dependable commitments in the systems and teams that deliver it.
Shashi Sethi
The approach
Define the outcome before connecting the agent
In this hypothetical design, success means an approved address change is in force in the order and fulfillment records before dispatch, the warehouse can proceed on that instruction, and customer service has accurate confirmation. The change has a named acceptance decision. Delivery of the parcel is a later outcome; this service must not claim to have completed it.
Limit the initial scope to one warehouse and ordinary unshipped orders. An authorized person approves the exact address. The operation verifies a dispatch hold and records a change in progress that participating writers must honor. Each update also checks the relevant record version. Without a dependable hold and a way to prevent or detect competing changes, this design remains in Recommend.
The agent can interpret a customer's message, identify missing information and assemble a proposed change. An existing workflow can coordinate the approved actions. If a structured form and established rules already handle the variation adequately, adding an agent needs a separate justification. Workflow, Agent, or Both? Choosing How Work Gets Done addresses that choice.
The authority remains specific: Recommend the proposed change; Act only through the approved interfaces within the mandate; Escalate conflicting or unresolved cases. In this example, overriding a dispatch restriction or accepting an unverified outcome is Never Delegate to the agent. Before an AI Agent Acts: Where Authority Is Enforced explains the enforcement boundary. Here, the concern is what follows a permitted request.
Identify which record settles each question
A system of record is authoritative for particular facts or states. The order system owns the commercial order and its approved revision. The fulfillment system owns the warehouse instruction, hold and dispatch status. Agreement between them must be established for this change. Neither becomes the universal database for the enterprise.
This separation allows an operation to resume after an agent session ends. The next worker can reconstruct progress from the case and verify business facts at their sources. The Enterprise Knowledge Backbone helps establish which knowledge applies; the action interfaces must separately establish which business state is current.
Figure 1. Responsibilities and records for the hypothetical order change. The agent proposes work; controlled interfaces commit changes. Durable case state and evidence support reconciliation and acceptance. These are logical responsibilities, which existing services may combine.
Figure 1 description
Reference architecture for an approved address change. People approve the exact change, own exceptions and accept the outcome. The agent uses retrieved context and working memory to propose a request to a durable coordinator, which can be an existing workflow. The coordinator calls controlled order and fulfillment interfaces. Each interface checks authority, intent and prerequisites, prevents duplicate effects within its contract and returns commit or status evidence. The order system owns the commercial order and approved revision. The fulfillment system owns warehouse instructions, hold and dispatch state. A durable case records operation identifiers, confirmed steps, unresolved work and acceptance; an evidence record links requests, decisions and authoritative checks. Dashed information paths do not confer authority to act. Technology owners maintain the service contracts; the Operating owner owns unfinished cases under the Outcome owner’s acceptance criteria.
Make the interface commitment explicit
An interface contract defines what a requested action means and what evidence it returns. For the address change, it identifies the order, approved address and approval revision, gives each intended action a stable operation identifier, and states the expected record version. A case identifier groups the work; it is not enough to distinguish every action within it.
The contract also specifies prerequisites, permitted effects and limits. The hold must be valid. The action may change the approved address; any change to price, tax, delivery promise or carrier instructions outside the mandate requires another decision. The result must identify a committed revision, a definite rejection, an operation still in progress, or a result that cannot yet be established.
Keep three meanings separate. Received means the service has taken the request. Committed means the authoritative system has durably applied the defined change within its stated transaction boundary. Accepted means the operation has met its business criteria and the designated acceptor has accepted it. HTTP's 202 Accepted response, for example, explicitly does not establish completed processing. [1]
An older address read moments earlier can already be stale. A conditional update checks the expected version as part of applying the change, preventing an intervening update from being silently overwritten. HTTP If-Match is one established mechanism for this purpose. A version conflict calls for renewed assessment; changing the version and repeating the write would bypass the reason for the check. [1]
Duplicate prevention must also be a real service commitment. Idempotency means repeating the same intended operation has the same intended effect. The service must recognize its stable identifier and bind it to the original request. The contract must state how long that protection lasts and what happens if parameters change. A key added by the caller cannot create protection that the receiving system does not provide. [2]
Resolve uncertainty before accepting the change
Return to the lost response. The order update is confirmed. The fulfillment write has committed, but the coordinator does not yet know that. Its durable case should say exactly that: order confirmed, fulfillment unresolved. The confirmed dispatch hold remains under operating supervision while the result is investigated.
Reconciliation compares the approved intent, operation history and authoritative records to establish what happened. The coordinator queries the fulfillment action's identifier and checks the resulting revision through a read path suitable for that decision. It finds the recorded commitment, verifies the intended address and makes no second write. It then checks the order and fulfillment revisions for intervening changes before moving toward acceptance.
A search index, cached response or lagging replica may omit a recent change. Read guarantees differ by system and access path. An empty lookup is also inconclusive while the original request could still be executing. The interface must distinguish a definitive non-application from an observation that has not yet caught up. [3]
If the interface establishes that the action did not apply and cannot later commit, a retry may proceed within the original contract and current authority. If the result remains unknown, a documented same-operation replay can sometimes resolve it safely through the service's duplicate protection. It must retain the original identifier and intent. Otherwise, pause and escalate; do not turn uncertainty into a new action.
Set an attempt limit and a time limit for retries, with waits between attempts. Coordinate retries across the agent, workflow and connector. Exhausting that budget ends automatic attempts; it does not establish failure. The case remains open for reconciliation or an accountable exception decision. [4]
Figure 2. The fulfillment write commits but its response is lost. Reconciliation establishes the result before completion. The main path avoids a second write; the alternatives show bounded retry, repair or escalation. Hold release is itself a controlled action whose result must be confirmed.
Figure 2 description
Sequence for a hypothetical approved address change, with a confirmed dispatch hold and coordination of competing writers. People approve the exact change. The coordinator updates the order and records a confirmed commitment. It requests a fulfillment update, which commits, but the response is lost. The durable case records fulfillment as unresolved. The coordinator queries the original operation and current authoritative record. When the commitment and approved revision are established, it checks for an intervening order change, obtains confirmed controlled release of the hold and presents the evidence to the designated acceptor. Acceptance is recorded only after the defined criteria are met. Alternative results: a definitive terminal non-application permits a retry only within the contract and budget; rejection or conflict requires authorized repair or compensation and renewed verification; continuing uncertainty requires a pause and Operating owner escalation before the hold deadline. An empty lookup while the original operation might still commit is not a definitive non-application.
A confirmed rejection creates a different problem. Suppose the order changed but fulfillment rejects its update because a concurrent change invalidated the expected revision. The Operating owner must decide whether to complete the approved change through a revised, authorized action or restore a permissible prior instruction. A compensating action is a new business change with its own checks and evidence. It may fail, and it may not recreate the original state. A database rollback cannot recall a parcel already handed to a carrier. [5]
Keep the hold and unfinished case visible, with an owner and a deadline. If the hold cannot remain dependable, the case moves to a staffed operational exception path before dispatch can resume. Acceptance follows verified agreement on the approved instruction, confirmed controlled release of the hold and accurate customer-service confirmation. A designated receiving acceptor records that decision against the Outcome owner's criteria.
Build on capabilities the enterprise can already operate
The useful architectural boundary may sit around an existing workflow, integration service or rules-based automation. These capabilities can already validate business conditions and execute changes. Agent participation does not justify discarding those controls or duplicating their records.
A translation layer can isolate differences between systems, but it adds a service to operate and does not remove the need to manage transaction and data consistency. [6] A wrapper cannot make an opaque screen-based action safely repeatable merely by logging it. If it cannot establish whether the underlying write occurred, keep that step assisted or redesign the boundary. The broader estate decision belongs in Modernize the Automation You Already Have.
Fund responsibility for the unfinished work
The Outcome owner defines the accepted result and funds the capability. The Operating owner runs the queue, staffs exceptions and owns continuity. Technology owners maintain the action and reconciliation contracts, including recovery after a coordinator restart. The Knowledge owner maintains applicable policy. The Control lead coordinates control requirements and evidence; the Sponsor resolves barriers to the resources and organizational changes needed. Specialist approval and independent assurance retain their own mandates.
For the first introduction, use one eligible order class and a finite volume that the fallback team can absorb. Compare against the existing operation. Observe elapsed time to acceptance, human review and recovery effort, conflicting changes, and the age of unresolved cases. A reduction in drafting time has limited value if warehouse staff inherit more investigation.
Before allowing Act, demonstrate lost responses after committed writes, duplicate delivery, stale reads, concurrent human updates, permanent rejection and restart during unfinished work. Recovery must resume from durable state. The manual fallback must take explicit control of the case and reconcile prior attempts before entering changes through the existing tools. Two active execution paths would recreate the duplicate problem.
At a planned review, Expand only when evidence supports a broader commitment within recovery capacity. Continue when the current boundary remains justified but broader evidence is insufficient. Narrow when a particular order class or interface is unreliable. Redesign when the coordination mechanism cannot establish the required result. Stop when dependable records or effective fallback cannot be maintained. These are review decisions; a specific incident may still require an immediate pause or repair.
Use Assuring AI Services from Release to Retirement to structure the evidence for release and continued operation, and Governing AI-Enabled Operations for the decision rights behind that commitment.
Two implementation details worth making explicit
Operation records must be reliable. If a service records a duplicate-prevention key separately from its business write, a crash between them can undermine the guarantee. The implementation needs an atomic coupling or equivalent proven mechanism. After protection expires, a replay cannot be assumed safe. [2]
A local commit does not settle a distributed outcome. A transactional outbox can commit a business change and its pending event together within one database transaction. Delivery can still produce duplicates, and receiving systems still need coordination. This pattern does not by itself provide one atomic transaction across the order and fulfillment systems. [7]
Leadership takeaway
Before extending an agent's mandate, ask the team to demonstrate one approved change whose response is lost after the write commits. Follow the case through the authoritative records, the unresolved state, the decision to avoid another write and the evidence used for acceptance.
Then ask who owns that same case when the normal recovery path cannot finish it. The answer should identify a staffed responsibility, a limit on automatic attempts and a workable way to protect the customer commitment.
Start where adaptive work can remove meaningful effort and the existing estate can support dependable execution. Broaden the commitment only when the evidence includes exception work and its consequences. An operation is ready to accept more agent participation when it can account for the work the agent leaves unfinished.
Sources and further reading
[1] HTTP Semantics — RFC 9110
IETF. June 2022. Sections 9.2.2, 13.1.1 and 15.3.3: idempotent methods, conditional changes and the limits of 202 Accepted.
[2] Making retries safe with idempotent APIs
AWS Builders' Library — Malcolm Featonby. Current documentation, accessed 16 October 2026. Request identity, equivalent intent, atomic handling and retention limits. Guarantees apply to the specific API contract.
[3] DynamoDB read consistency
AWS documentation. Current documentation, accessed 16 October 2026. A documented example of different read guarantees by access path. The article does not assume these guarantees for other systems.
[4] Timeouts, retries, and backoff with jitter
AWS Builders' Library / AWS Builder Center — Marc Brooker. Current article, accessed 16 October 2026. Retry limits, delayed retries and amplification when several layers retry independently.
[5] Compensating Transaction pattern
Microsoft Azure Architecture Center. Current documentation, accessed 16 October 2026. Business-specific compensation, concurrent changes, recovery failures and human intervention.
[6] Anti-Corruption Layer pattern
Microsoft Azure Architecture Center. Updated 30 May 2026; accessed 16 October 2026. Translation between different system semantics, operating overhead and retained consistency responsibilities.
[7] Transactional outbox pattern
AWS Prescriptive Guidance. Current documentation, accessed 16 October 2026. Local atomicity for a business write and event record; remaining duplicate-delivery and consumer responsibilities.
The engineering sources support the mechanisms and their limits. The operating interpretation and the order-change architecture are RePerspective Labs synthesis. The example and diagrams are hypothetical designs, not a customer implementation or evidence of achieved results.