WriteGuard

Agents can reason before acting. WriteGuard gives them durable execution memory after acting.

Comment

Inspiration

The next step for AI is not only getting agents to reason. It is trusting them to act.

I kept returning to one deceptively simple failure: an agent issues a refund, the payment provider succeeds, but the response is lost. The agent sees a timeout, retries, and refunds the customer again.

The model may have reasoned correctly both times. The failure happened after the decision, at the boundary between a probabilistic agent and an external system with an uncertain outcome.

That boundary is becoming more important as agents gain access to payments, communications, orders, infrastructure, and systems of record. Permission checks can decide whether an agent should act. They do not tell the agent whether a timed-out action already happened.

I built WriteGuard to provide that missing execution memory.

What it does

WriteGuard helps developers prevent uncertain retries, concurrent workers, and crashes from turning one intended action into multiple real-world effects.

It takes an MCP tool through a complete developer journey:

  1. Analyze — GPT-5.6 identifies consequential writes, retry risks, candidate identity fields, reconciliation constraints, sensitive fields, and failure scenarios.
  2. Review — the result remains a recommendation, not executable policy.
  3. Approve — a developer explicitly chooses and approves the operation identity and safeguards.
  4. Generate — deterministic code creates a typed guarded wrapper, explicit provider boundary, manifest, and failure tests.
  5. Verify — WriteGuard checks provenance bindings, artifact integrity, compilation, provider-boundary completeness, and—only with explicit opt-in—generated failure scenarios.
  6. Integrate — the wrapper protects the provider call while keeping provider-specific behavior explicit.

The credential-free evaluation shows the core result directly: an unsafe retry produces two simulated external effects, while the guarded workflow produces one simulated external effect under the documented assumptions.

How it works

WriteGuard separates probabilistic reasoning from deterministic authority.

1. GPT-5.6 understands unfamiliar tools

A tool schema can reveal its fields, but syntax alone cannot reliably explain whether the tool creates a consequential effect, which fields should identify one logical operation, whether a provider can reconcile an uncertain result, or which data should be redacted.

GPT-5.6 analyzes the validated tool definition and returns a strict, structured recommendation covering those questions.

2. The developer remains the authority

Every analysis is marked recommendation_only. It cannot approve itself or silently become runtime policy. The developer reviews the proposed identity, reconciliation strategy, redaction fields, and failure scenarios before approving a digest-bound configuration.

3. Trusted code generates the integration

After approval, deterministic code generates the typed wrapper, provider boundary, manifest, and failure tests. Generation makes no model or network call and does not invent provider-specific semantics.

4. WriteGuard supplies durable execution memory

At runtime, WriteGuard records the logical operation and coordinates execution across retries, concurrency, crashes, and uncertain outcomes. Durable deployments use PostgreSQL. Provider-specific reconciliation remains explicit instead of being guessed by a model.

5. Verification preserves the meaning of the evidence

WriteGuard emits runtime-validated receipts showing what was checked. Artifact integrity is not presented as authenticity. Compilation is not presented as provider correctness. A simulated provider is not presented as production validation. Real-provider semantics remain not_run unless they were actually tested.

WriteGuard also does not attempt to replace provider-native idempotency. When a provider offers reliable idempotency keys, they are useful. WriteGuard addresses the larger integration problem: identifying the logical operation, persisting its state, coordinating retries, reconciling uncertainty, testing failures, and preserving evidence across providers with different capabilities.

The complete Build Week experience

Run:

pnpm evaluate:local

The packed-package evaluation completes:

Tool → Analyze → Review → Approve → Generate → Verify → Integrate

It requires no API key, Stripe credential, PostgreSQL database, authentication, or workspace-only dependency. The canonical evaluation itself makes no live OpenAI, Stripe, or other-provider request.

The maintained evaluation completes in approximately 39 seconds of automated execution time. A fresh private clone also passed frozen installation and the canonical evaluation on the verified environment. These are execution measurements, not claims about new-developer onboarding time.

Why this matters

Developers are moving from AI that recommends actions to AI that performs them. That shift creates a new trust requirement.

For a user, the difference between “the model meant to send one email” and “the system sent two emails” is the difference between an impressive demo and a product they can trust. The same is true for refunds, orders, deployments, account changes, and other consequential operations.

WriteGuard’s long-term opportunity is to become the execution-safety layer beneath agent platforms: the place where an agent’s intent becomes one durable, reviewable, and verifiable real-world operation.

Real-world application: Stripe and agentic commerce

This transition is already happening in commerce.

Stripe’s new Link CLI and wallet for agents let people authorize agents to obtain scoped, one-time-use payment credentials. Stripe’s Agentic Commerce Suite helps merchants sell through AI agents, while Stripe MCP exposes consequential tools such as creating refunds directly to agent workflows.

These products solve critical authorization, credential-security, payment-processing, and protocol problems. They also make WriteGuard’s layer more necessary. After a user approves a purchase or refund, the agent can still lose the merchant or provider response, restart midway through the workflow, or receive an indeterminate result. It must then decide whether to retry, reconcile the existing action, request a replacement credential, or stop for review.

For example, Stripe allows multiple legitimate partial refunds on one charge. If a refund succeeds but the agent loses the response, a retry with a new request identity can create another valid partial refund. Provider-native idempotency helps only when the application chooses and durably reuses the correct key.

WriteGuard complements Stripe rather than replacing it. Stripe protects credentials and processes the financial operation; WriteGuard preserves the agent’s logical intent across the support ticket, approval, idempotency key, refund, webhook events, and confirmation email. If execution becomes uncertain, WriteGuard can reconcile those identifiers before another consequential action is attempted.

The first planned commerce pilots are a guarded Stripe MCP refund workflow and a Link CLI test-mode purchase flow. They are future integrations, not part of the current Build Week evaluation, but they demonstrate how WriteGuard can become a provider-agnostic trust layer for the emerging agent economy.

How GPT-5.6 was used

GPT-5.6 performs the design-time reasoning that deterministic code cannot safely infer from syntax alone. Given a validated MCP tool definition, it recommends:

  • Whether the tool performs a consequential write
  • Retry, timeout, concurrency, and uncertain-outcome risks
  • Candidate operation-identity fields
  • Possible reconciliation constraints
  • Sensitive fields requiring redaction
  • Relevant failure scenarios
  • Confidence and missing information requiring developer review

The analyzer uses the OpenAI Responses API with strict structured output. Its live evaluation passed 9 of 9 sanitized cases covering consequential writes, read-only tools, missing identity, unsupported reconciliation, sensitive fields, ambiguity, and prompt-injection-shaped metadata.

The canonical offline evaluation uses a sanitized, schema-valid recorded GPT-5.6 fixture so judges can run it without credentials or API spend. The result is explicitly labeled as recorded rather than live.

GPT-5.6 never decides whether a real action executes.

How Codex was used

Codex was my engineering partner throughout five Build Week iterations:

  1. We designed versioned tool-analysis contracts, deterministic MCP normalization, provenance hashing, and the injectable analyzer boundary.
  2. We added the optional GPT-5.6 analyzer and hardened structured-output, refusal, timeout, rate-limit, prompt-injection, invalid-output, and provenance handling.
  3. We built the explicit review → approve → generate workflow, typed provider boundaries, deterministic wrappers, and generated failure tests.
  4. We added safe-by-default verification, controlled compilation and test execution, versioned receipts, and separate refund and email consumer pilots.
  5. We consolidated the credential-free evaluation, adapter-conformance receipts, CI receipt policy, clean packaging, and judge-testing materials.

Codex also helped create and run the validation gates, investigate concurrency and cross-platform failures, preserve the boundary between probabilistic recommendations and deterministic enforcement, and document what every layer proves and does not prove.

What existed before Build Week

WriteGuard entered Build Week with a TypeScript SDK foundation that already included guarded execution, durable redacted tracing, PostgreSQL storage, MCP integration, reconciliation, concurrency and crash-recovery scenarios, shadow mode, adapter conformance, and public demos.

During Build Week, I turned that runtime foundation into a complete developer product for understanding an unfamiliar tool, reviewing its risks, approving safeguards, generating an integration, testing failure behavior, verifying the result, and evaluating the full journey.

The repository’s BUILD_WEEK.md, validation reports, commits, and annotated iteration tags distinguish the pre-existing foundation from the work completed during the event.

Accomplishments that we're proud of

  • A complete tool-to-integration product journey rather than a standalone model call
  • Strict separation between GPT-5.6 recommendations and developer approval
  • Deterministic, network-free wrapper and failure-test generation
  • Static verification that executes no generated JavaScript by default
  • Explicit opt-in before generated tests execute
  • Versioned analysis, verification, adapter-conformance, and CI-policy contracts
  • Durable PostgreSQL execution with concurrency and crash-recovery coverage
  • Separate refund and email packed-package pilots
  • Two unsafe simulated effects versus one guarded simulated effect
  • 172 unit tests and 20 PostgreSQL/MCP/concurrency integration tests
  • Five generated failure scenarios, six adapter-conformance scenarios, and six pilot-specific tests
  • Historical live GPT-5.6 evaluation: 9/9 sanitized cases passed
  • Remote Windows and Ubuntu evaluation workflows passed
  • Ubuntu/PostgreSQL pilot-ready workflow passed
  • Fresh-clone frozen installation and canonical evaluation passed
  • No OpenAI dependency in the guarded runtime path

Challenges we ran into

The hardest design decision was deciding where AI should stop.

It would have been easy to let the model generate trusted runtime policy and call the result complete. I instead treated tool descriptions and model output as untrusted design-time inputs. Recommendations are validated, provenance-bound, separately approved, deterministically generated, and independently verified.

The second challenge was communicating evidence honestly. Compilation does not prove provider correctness. Hashes do not establish authenticity. Controlled child processes are not security sandboxes. Simulated retries do not establish production-provider behavior.

WriteGuard preserves those distinctions instead of collapsing everything into one reassuring but misleading green checkmark.

What we learned

Agent reliability is not only a model-reasoning problem. It is also an execution-semantics problem.

Models can help developers identify risky operations, but the final safety boundary must remain reviewable, deterministic, durable, and testable. Trust comes not only from the intelligence of the model, but from the system’s ability to explain what happened and continue safely when the answer is uncertain.

What's next for WriteGuard

  • Validate onboarding with unaffiliated agent and backend developers
  • Build a guarded Stripe MCP refund pilot that binds one refund intent to its support ticket, idempotency key, Stripe refund, webhook events, and customer notification
  • Build a Link CLI test-mode purchase pilot that safely handles an uncertain merchant checkout and replacement-credential decision
  • Add Agentic Commerce Protocol conformance tests for idempotent replay, in-flight collisions, payload conflicts, and order reconciliation
  • Run the existing Stripe adapter using a freshly rotated test-mode credential
  • Expand provider-specific conformance evidence
  • Support additional schema inputs after validating the MCP workflow
  • Explore a Studio or hosted control plane after observing real developer workflows

The long-term goal is for WriteGuard to become the trusted execution layer for consequential actions performed by AI agents.

Built With

Share this project:

Updates