Inspiration
Enterprise AI agents are becoming very good at completing tasks. That creates a new problem: a completed task is not necessarily a completed business outcome.
Imagine a customer reports a missing $200 order.
A Support Agent issues a $200 refund.
A Fulfillment Agent creates a $200 replacement.
A Retention Agent grants $50 in goodwill.
A second support workflow independently issues another $200 refund.
Every agent can be locally reasonable. Every system can report success. Jira can even close the ticket.
But the business has now projected $650 of compensation against a $200 problem.
That gap between agent completion and business settlement inspired IsoPact.
We wanted to build infrastructure underneath an enterprise agent fleet that could answer a different question:
Do all of these independently valid actions still compose into one valid business outcome — and has that outcome actually settled?
IsoPact is our answer: an outcome settlement layer for enterprise agent fleets.
What it does
IsoPact creates an Outcome Pact for an enterprise obligation and keeps track of what the organization has promised, attempted, confirmed, blocked, recovered, and ultimately settled.
In our missing-order scenario, Support, Fulfillment, and Retention agents remain independent and continue pursuing their own legitimate objectives.
IsoPact sits beneath them and governs the combined outcome.
When Support requests a $200 refund, IsoPact allows it.
When Fulfillment later attempts a $200 replacement for the same obligation, IsoPact stops it because another primary resolution is already underway.
When Retention grants $50 in goodwill, IsoPact allows it because additive goodwill is permitted by policy.
When another Support session retries the same economic refund using different request metadata, IsoPact recognizes the underlying business operation and blocks the duplicate.
The protected result is:
- $200 refund
- $50 goodwill
- $200 replacement blocked
- duplicate $200 refund blocked
- $250 final authorized response
- $400 in projected conflicting value prevented
But preventing contradictory actions is only half the problem.
IsoPact also separates agent claims from authoritative business evidence.
A Support Agent can say the refund is complete and Jira can close the ticket while Stripe still reports the refund as pending. IsoPact therefore keeps the case Waiting for confirmation.
Only when authoritative payment evidence arrives does the business outcome transition to Resolved and verified.
IsoPact also handles cases where something already went wrong before it could intervene. Its Settlement Resolver can propose recovery actions from a closed Compensation Registry, while deterministic code rechecks current state before execution.
If the world changes after a recovery plan is created, IsoPact refuses the stale action.
If an external API may have succeeded but its response is lost, IsoPact does not blindly retry. It persists an ambiguous outcome, waits for authoritative evidence, and prevents duplicate consequential execution.
Finally, settled cases can produce a KMS-signed outcome receipt whose claim history and signatures can be independently verified.
How we built it
IsoPact is deliberately split into a reasoning plane and an authority / settlement plane.
Enterprise agent fleet
We deployed four specialized enterprise agents:
- Support Agent — financial customer resolution
- Fulfillment Agent — replacements and logistics
- Retention Agent — goodwill and relationship recovery
- Settlement Resolver — cross-system recovery planning
The agents are cataloged through Google Agent Registry and run through Google Agent Runtime with managed Agent Identity.
We use Memory Bank for persistent cross-session reasoning context, but we made an important architectural distinction:
Memory remembers context. The Pact Graph remembers truth.
Memory can help an agent reason, but it can never silently change business policy or settlement authority.
Gemini for reasoning, deterministic code for authority
We use Gemini 3.5 Flash through Vertex AI for tasks where semantic reasoning is useful:
- converting business intent into a candidate Outcome Pact
- understanding conflicting enterprise context
- selecting recovery actions from an approved Compensation Registry
- explaining why a case is unresolved
Gemini cannot directly authorize consequential writes.
Financial and operational authority remains deterministic.
This means the model can recommend:
Cancel the unused shipping label.
But IsoPact still checks:
- Is that action registered?
- Is it permitted for this case?
- Is the current carrier state still cancellable?
- Has another operation already consumed the resolution authority?
- Is human approval required?
Only then can execution proceed.
Outcome Gateway and durable authority
The IsoPact Outcome Gateway runs on Cloud Run in africa-south1.
Before a consequential external action happens, IsoPact creates durable authority using a Firestore transaction.
The external SaaS/API call happens after that authority commit — never inside the Firestore transaction callback.
This prevents transaction retries from accidentally executing external economic actions multiple times.
We also separated:
- transport request identity
- semantic economic operation identity
- resolution exclusivity
That lets IsoPact recognize two requests as the same refund even when they come from different sessions, agents, request IDs, or API idempotency keys.
Evidence and settlement
Business truth is stored in a Firestore-backed Pact Graph.
Evidence arrives through Pub/Sub and is ranked according to authority.
For example:
- an agent saying “refund complete” is useful context, but not settlement authority
- an API saying a refund is merely accepted/pending is not settlement authority
- an authenticated source-system event confirming refund success can be authoritative
Duplicate Pub/Sub deliveries and transport IDs are separated from the identity of the underlying business event so redelivery cannot duplicate economic value.
A deterministic invariant engine then evaluates the complete business position before a case may settle.
Safe recovery
For pre-existing divergence, Gemini can select actions from a typed Compensation Registry.
Examples include:
- cancelling an unaccepted carrier label
- releasing reserved warehouse stock
- reopening Jira work
- approval-gated reversal of unused goodwill
The model cannot invent executable compensation.
IsoPact also performs an execution-time state recheck. In one proof, Gemini proposed cancelling a carrier label while the state was CREATED. Before execution the carrier changed to ACCEPTED.
IsoPact stopped the cancellation.
Unsafe external calls: 0.
Provenance and verification
State transitions are added to a per-case SHA-256 provenance chain.
We use Cloud KMS to sign checkpoints and final outcome receipts.
The final receipt can independently verify:
- receipt signature
- checkpoint signature
- claim chain
- terminal integrity fingerprint
A modified receipt fails verification without changing the production record.
Security and observability
We also integrated:
- Model Armor for untrusted model-facing input
- Secret Manager for protected integration secrets
- OpenTelemetry
- Cloud Trace
- Cloud Logging
- Cloud Monitoring
Our telemetry is intentionally non-authoritative: if observability fails, settlement correctness continues.
We also proved asynchronous causality across Pub/Sub using real OpenTelemetry span linking rather than fabricating one continuous parent-child trace.
Challenges we ran into
One of the hardest problems was realizing that idempotency alone does not solve this problem.
An API can perfectly deduplicate retries of one request while two different agents still initiate different but economically contradictory operations.
That led us to separate semantic operation identity from transport identity and introduce explicit primary-resolution exclusivity.
Another difficult failure mode was the classic distributed-systems case where:
the external action may have succeeded, but the response disappears.
Immediately retrying a refund, shipment, or cancellation can be dangerous. We therefore introduced a durable OUTCOME_UNKNOWN state: when IsoPact cannot prove whether a consequential write happened, it refuses to guess.
Observability was another major challenge. Synchronous Agent Runtime → Gateway tracing was straightforward compared with reconstructing causality once an authoritative Pub/Sub event arrived asynchronously. We eventually implemented real causal links between publisher and consumer traces.
We also discovered a real performance limitation in our provenance architecture: extreme concurrent writes to the same Pact can contend on the Firestore chain head. We kept the integrity guarantee intact and documented the bottleneck rather than weakening the chain simply to produce prettier benchmark numbers.
Finally, integrating enterprise-agent infrastructure forced us to be precise about what every Google service actually does. For example, our Agent Gateway resource is provisioned but is not in the canonical request path, so we do not claim that it enforces IsoPact traffic.
Accomplishments that we're proud of
We are especially proud that IsoPact became much more than a scripted demo.
The final system includes:
- four specialized agents deployed through Google Agent Runtime
- all four cataloged through Agent Registry
- managed Agent Identity
- persistent Memory Bank context with a non-authoritative boundary
- live Cloud Run Outcome Gateway
- Firestore Pact Graph and reservations
- Pub/Sub authoritative evidence pipeline
- deterministic economic invariants
- constrained recovery through a Compensation Registry
- TOCTOU-safe compensation
- persistent ambiguous-write handling
- Model Armor
- KMS-signed provenance and outcome receipts
- OpenTelemetry causal traces
- a live judge-facing enterprise UI
- reproducible deployment and locked dependencies
- SBOM and release manifest
We also froze the architecture and ran an adversarial Stage 12 benchmark:
- 130 deterministic benchmark cases
- 39 held-out cases
- 2,500 generated economic/property cases
- 30 injected failures
- 100 refund-vs-replacement race repetitions
- 100 duplicate-refund contention repetitions
- 50 concurrent independent Pact cases
On that frozen benchmark we observed:
- 100% contradiction detection recall
- 100% contradiction detection precision
- 100% legitimate-action approval
- 0% false-block rate
- 0 duplicate consequential executions
- 0 unsupported business closures
- 0 unsafe automatic compensations
- 0 model-caused authority mutations
- 0 forged events accepted as authoritative
- 100% tamper detection in the tested provenance attacks
These are benchmark results, not a claim of universal production accuracy.
We also built the interface so the architecture is understandable without requiring a distributed-systems lecture.
An operator can simply see:
Support finished its work.
Jira is closed.
Stripe has not confirmed the refund.
The business is still waiting.
What we learned
The biggest lesson was that more model autonomy is not always better system design.
Gemini is extremely valuable when the problem is ambiguous language, intent interpretation, semantic correlation, or choosing among safe recovery options.
It is much less appropriate as the final authority for whether money should move or whether an irreversible operation remains safe several seconds later.
We learned to treat reasoning and authority as separate concerns.
We also learned that persistent memory and authoritative state are different concepts. Memory can improve an agent's continuity, but enterprise truth must have stronger provenance, source authority, lifecycle rules, and versioning.
Another lesson was:
API accepted does not mean business settled.
The state of the actual obligation matters more than whether an agent received a successful HTTP response.
We also learned that recovery is fundamentally different from prevention. Blocking a replacement before execution is straightforward compared with discovering a contradiction that already exists and safely unwinding only the reversible parts.
Finally, building the observability layer reinforced an important principle: enterprise telemetry should make the architecture explainable, but it should never become part of the architecture's authority.
What's next for IsoPact
The missing-order workflow is intentionally narrow enough to let us rigorously prove the settlement model, but the underlying pattern extends far beyond commerce.
Our next step is to expand IsoPact's Enterprise Connector Plane with production-grade integrations for platforms such as Stripe, Jira, Slack, Salesforce, logistics providers, and ERP systems while keeping those connectors below the deterministic authority boundary.
We also want to expand the Outcome Pact model into domains such as:
- accounts payable
- procurement
- insurance workflows
- subscription lifecycle operations
- logistics
- enterprise incident remediation
On the infrastructure side, future work includes:
- stronger tenant isolation for multi-organization deployments
- broader policy administration and approval workflows
- additional source-specific evidence adapters
- Firestore PITR / backup hardening
- reducing same-Pact provenance contention without weakening integrity
- externally archived signed checkpoints
- broader adversarial benchmarks across additional enterprise domains
The long-term goal is for IsoPact to become a protocol layer beneath enterprise agent fleets:
Agents reason locally. IsoPact settles globally.
Log in or sign up for Devpost to join the conversation.