An agent can carry a plan from one department to another faster than the company can resolve an ambiguous responsibility. The plan may be useful. Its speed still leaves a practical question: what exactly authorises the receiving system to act, and who takes responsibility if only part of the plan succeeds?
My Enterprise Agentic Mesh proposal starts from this cross-system problem. The guidance here develops that proposal into review questions. The manufacturer used below is fictional. The examples illustrate mechanisms to design and test; they report no measured customer outcomes or deployed enterprise mesh.
A proposal should arrive with the conditions that matter
Suppose a manufacturer considers lending a demonstration machine while a delayed replacement is in transit. Engineering finds it suitable and the equipment owner approves a loan. The next customer’s booking must remain protected.
The booking service needs more than the agent’s statement that “approval was obtained.” It needs an identifiable proposal, the appropriate approver, the scope of the decision and the conditions under which it remains valid. If the dates, machine or customer change, the service must know whether the existing approval still covers the action.
These facts belong in a defined contract between participants. An agent explanation may help a person understand that contract, but the receiving system must obtain and verify the authority it relies on. Open Policy Agent describes policy evaluation separately from enforcement. Connecting the two correctly remains an application responsibility.
Confirm facts where they become commitments
A plan is an account of a possible future. Availability in the system of record is a current fact that can change before the plan is executed. Two agents may both find the same machine free and prepare individually reasonable loans.
The service making the reservation must protect the invariant that prevents incompatible bookings. A pre-action check can become stale before a write. The implementation needs a concurrency mechanism appropriate to its transaction boundary, rather than relying on the agent to remember to check again.
A shared case record helps participants see what is known, proposed, approved and confirmed. It should link to authoritative records and respect access boundaries. It cannot silently become the source of truth for every department. The architecture must identify which service owns each fact and each transition.
An unknown result needs its own state
Imagine the booking succeeds and the network fails before its reply arrives. The calling agent sees a timeout. Treating that timeout as a confirmed failure could produce a second reservation. Treating it as success could leave later work dependent on an action that never happened.
The system needs to preserve “outcome unknown” until it can reconcile the attempt with the executing service. An operation identifier, a status query and a durable record of attempts can make that reconciliation possible. The exact mechanisms depend on the service contract.
AWS’s account of idempotent APIs explains a practical role for caller-supplied request identity in safer retries. The important design question is what repeated requests mean to this service. Reusing the same identity for a materially changed request needs explicit handling. A retry limit constrains activity; it cannot alone prevent duplicated effects.
Recover the case, including its remaining obligations
Now suppose transport cannot be arranged after the reservation is confirmed. Cancelling the booking may release the equipment, but the customer may already have received a promise. Recovery therefore includes both system state and business obligations.
Identify which actions are reversible, which require a compensating action and which create a commitment a person must resolve. A compensating action may fail too. The case needs a responsible owner, the evidence needed to reconcile it and a clear point beyond which automated work stops.
This is why I treat recovery as part of capability in Governed Intelligence. Describing what a service can do should include its failure states and recovery responsibility. An architecture that lists only successful actions leaves the hardest coordination work for an incident.
Change the rule through the whole path
Suppose the owner increases the inspection allowance before the machine’s next booking. That decision has consequences for planning, approval and execution. Uncommitted plans may need reassessment; an existing loan may require a person to resolve the conflict.
The business-model essay proposes translating approved business changes into the operational model. A useful test follows one rule across its effective date, versions, affected cases and enforcement points. Publishing a revised policy does not establish that the systems have changed their behaviour.
Test the handoff with an expired approval, a changed proposal, simultaneous reservations, a lost response and a failed compensation. Inspect the authoritative final state and the obligations still open. These are suggested mechanism tests; broader operational qualification requires representative cases and evidence from the intended environment.
Cross-system autonomy becomes more credible when each commitment has an owner, each authority has a verifiable scope and each partial failure has a route back to a known state. That gives an agent room to find useful alternatives while preserving the company’s ability to answer for them.
Continue with the architecture-review guide or workflow versus adaptive agent. To discuss one difficult handoff, use Advisory; focused advisory scope and outputs are agreed together.