Field Notes: AI Agents Are Learning to Reconcile Plans With Reality

An agent can produce a sound plan, call the right tools, and still fail operationally. The reason is simple: execution changes the world, often in ways the agent did not predict. A customer pays while a collections workflow is running. Inventory is reserved by another order. A manager approves a request through email rather than the designated system. The plan remains internally coherent while reality moves elsewhere.

The important change is not that agents have become better planners. It is that operational designs are beginning to treat reconciliation as a first-class capability. Instead of assuming every tool response advances a clean sequence, the agent repeatedly compares expected state with observed state. This is the difference between executing instructions and managing live work.

What changed: the execution loop now includes reconciliation

Early agent workflows commonly followed a linear pattern: interpret the request, form a plan, call tools, and report completion. More robust systems use a different loop: observe, propose, act, re-observe, compare, and adapt.

The decisive addition is the comparison step. After an action, the agent does not merely ask whether the tool returned success. It asks whether the intended business condition now exists. An API can accept a refund request while the payment remains unsettled. A CRM can accept an owner update while a routing rule immediately overwrites it. Transport success is not business success.

This has pushed agent design toward explicit representations of expected state. Before acting, the agent records what should change, what should remain invariant, and what evidence would confirm the transition. After acting, it reads the relevant systems again. The resulting difference is not simply an error message; it is an operational diagnosis.

The practical model: expected, observed, and authoritative state

Reconciliation requires three distinct concepts. Expected state is the condition predicted by the current plan. Observed state is what tools and events report. Authoritative state is the source the business has designated to settle a particular fact.

These can disagree. Suppose an agent is handling a contract renewal. The CRM says the renewal is pending, the billing platform shows a successful charge, and the signed agreement is stored in the document system. The agent should not average those signals or trust the latest timestamp by default. Authority is field-specific: billing settles payment, the contract repository settles signature status, and the CRM may only summarize the process.

This model prevents a common mistake: treating every mismatch as a reason to retry. Retrying is safe only when the operation is idempotent, the target remains valid, and no other actor has fulfilled or altered the goal.

What it means in practice: classify drift before correcting it

Not all divergence deserves replanning. A useful agent first classifies the mismatch by cause and consequence.

• Timing drift: the expected transition is still in progress. The response is usually bounded waiting, not intervention.
• Representation drift: two systems describe the same reality differently. The response is normalization or identity resolution.
• Concurrent drift: another person or automation changed the object. The response must account for ownership and intent.
• Policy drift: the plan conflicts with a current rule, approval condition, or entitlement. The response is to stop and re-evaluate authority.
• Goal drift: the requested outcome itself has changed or has already been achieved. The response is to reconsider the remaining plan.

The classification controls the remedy. A delayed warehouse update may justify polling. A sales representative changing a negotiated discount may justify pausing. A customer paying an invoice through another channel should terminate collection actions immediately. One generic “retry on failure” policy cannot distinguish these cases.

A worked example: repairing an order exception

Consider an agent tasked with replacing a damaged product. Its plan is to verify eligibility, reserve replacement inventory, create a shipment, and send return instructions.

Eligibility passes. The inventory tool reports that one unit is available, so the agent submits a reservation. The call succeeds. Before shipment creation, the agent re-reads the reservation and finds no unit attached to the order.

A weak agent retries the reservation. A reconciliation-capable agent inspects the transition. It discovers that another order claimed the last unit between availability checking and reservation. The successful response meant the request was accepted for processing, not that stock was secured.

The agent then evaluates repair options. It can source the same item from another location, offer an equivalent product, wait for replenishment, or issue a refund. Those options have different customer, margin, and authority implications. If policy permits cross-location sourcing within a delivery threshold, the agent can repair the plan automatically. If substitution requires customer consent, it should prepare the options and ask one precise question.

Before sending anything, it should also suppress the original return instructions if they assumed an immediate replacement. Reconciliation is therefore not just finding the next step. It includes cancelling actions that became invalid when the state changed.

The core design requirement: postconditions, not success flags

Every consequential action should have a business-level postcondition. “Tool returned success” is diagnostic evidence, but rarely a sufficient postcondition.

For a meeting cancellation, the postcondition may be that the event is marked cancelled, attendees were notified, and no replacement event was unintentionally removed. For an access revocation, it may be that active sessions are invalidated as well as the account being disabled. For a purchase order, it may be that the supplier accepted the order under the intended quantities and terms.

A practical action specification contains:

1. The intended state transition.
2. The fields or objects allowed to change.
3. The invariants that must remain true.
4. The authoritative evidence used for verification.
5. The expected settlement window.
6. The permitted repair actions.
7. The condition requiring human review.

This makes execution auditable. It also separates planning quality from operational reliability. A correct plan can encounter an external exception; a poor plan can accidentally reach the right result. Postconditions reveal which occurred.

Where autonomy should stop

Automatic repair is appropriate when the goal remains stable, the alternative path is policy-equivalent, the action is within delegated authority, and the consequences are reversible or tightly bounded.

The agent should pause when reconciliation reveals a new decision rather than a mere execution problem. Material price changes, altered legal terms, conflicting human instructions, ambiguous ownership, and irreversible customer impact are not technical exceptions. They change the choice being made.

The escalation should not dump logs on an operator. It should state the intended outcome, the expected and observed states, the most likely cause, actions already attempted, viable options, and the single decision required. This preserves momentum without concealing uncertainty.

What remains unresolved

Authority is often implicit

Many organizations cannot say which system settles each business fact. They have a nominal system of record, but exceptions live in email, spreadsheets, and specialist tools. An agent exposes this ambiguity quickly. Technical reconciliation cannot compensate for undefined operational ownership.

Concurrent intent is harder than concurrent data

Systems can detect that a field changed. They are less capable of determining why a person changed it and whether that intent should override the agent’s mandate. Timestamps and job titles are weak substitutes for explicit decision rights.

Verification has a cost

Repeated reads, event subscriptions, and delayed confirmation increase tool usage and latency. The answer is not to verify everything equally. High-impact transitions deserve strong postconditions; low-risk, reversible updates may justify lighter checks.

Compensation is not always restoration

Reversing a database update may restore data without restoring trust, inventory position, or customer expectations. Once an external message is sent or a market action occurs, the original state may no longer be recoverable. Agents need compensation plans that address business consequences, not just technical rollback.

The operating implication

The next useful question for an agent platform is not, “Can it complete this workflow?” It is, “How does it know the workflow still matches reality after each consequential step?”

Organizations should begin with a narrow inventory of critical transitions: payment captured, access granted, order committed, contract accepted, case closed. For each one, define authority, postconditions, settlement time, repair rights, and escalation boundaries. That work will often reveal process defects before it improves the agent.

An agent that plans well but cannot reconcile is dependable only in a static environment. Business operations are not static. The stronger design assumes divergence, detects it early, and treats recovery as part of the work rather than evidence that the work has failed.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.