How is Postcept different from observability, evals, or authorization?

Authorization checks whether an agent may act. Observability shows what happened in the trace. Evals judge whether behavior looked successful. Postcept verifies whether the action actually completed correctly in the system of record, deterministically, not with another model.

Does Postcept move money or take actions on my behalf?

No. For the first wedge, Postcept is read-only by default and least privilege by design. It uses scoped read access to confirm refunds, credits, cancellations, and tickets, and routes failures to your existing review and recovery workflows.

Which systems does Postcept verify against?

Systems of record like Stripe, Zendesk, Gorgias, Salesforce, Shopify, NetSuite, and ServiceNow, plus your internal systems via API. Postcept checks existence, amount, customer, status, duplicates, and policy-required postconditions.

What is Verified Completion Rate?

The percentage of an agent's claimed completions that are independently verified as correct against the system of record. It's a completion metric for action-taking agents that goes beyond eval scores and self-reported success.

How do I get started?

Verify your first action in about five minutes with the quickstart, in sandbox mode, no system to connect. Then add a read-only connection to a system of record and drop test mode to verify against the real thing. It's free to start, no credit card.

Completion control for AI agents

Don’t let an agent say “done” until the system of record agrees.

Postcept checks each protected refund, cancellation and ticket against the system of record and returns one enforceable decision: safe to claim complete, or exactly why not.

Run the broken-refund demo See the five-minute integration

Open-source relay and verifierRelay mode keeps credentials in your environmentEvery decision signed, verifiable offline

postcept · verification

op_refund_8F31

verified against system of record

Agent claim

Refund processed and ticket resolved.

status: claimed

Agent: SupportAgent-04
Operation: op_refund_8F31
Amount: $120.00
Reason: duplicate charge

System of record

Stripe

refund: re_4md82k
amount: $120.00
status: succeeded
idempotency: refund_8F31

Zendesk

ticket: #48921
status: Solved
customer: matched
linked refund: re_4md82k

Postcept verification

Refund existsevidence

Amount matchesevidence

Customer matchesevidence

Duplicate check passedevidence

Ticket updatedevidence

Postcept Receipt

Verified completion

Receipt ID: pcpt_rcpt_01HY9Q...
Operation ID: op_refund_8F31
Agent: SupportAgent-04
Claimed action: refund_customer
Systems checked: Stripe, Zendesk
Timestamp: 2026-06-23 09:41:26 UTC

Signaturevalid

Verified completionVCR 0.0%

01/The completion gap

“Done” is not proof.

When an AI agent says a refund was processed, a ticket was resolved, or a subscription was cancelled, that is only a completion claim. The system of record may tell a different story, and that mismatch is the completion gap, where agent trust breaks.

False completion

The agent reports success, but the external system never changed.

Duplicate completion

A retry, timeout, or lost idempotency key performs the same action twice.

Non-compliant completion

The action happened, but skipped a required verification, approval, or policy step.

Corrupted context

OAuth state, signed URLs, session tokens, webhooks, or operation IDs break across handoffs.

02/The decision

One boolean controls the next step.

Every verification returns safe_to_claim_complete with a machine-readable reason. Your application enforces it, so the entity being checked never grades its own work.

the decision

{
  "decision": "pending",
  "safe_to_claim_complete": false,
  "lifecycle": "pending_finality",
  "claim_reason": "pending_finality",
  "next_reverify_at": "…"
}

A refund can be real and still not final. The decision separates the two, names the reason, and carries the deadline for the next re-check, so pending never silently becomes done.

your workflow owns the branch

const v = await postcept.verifyRefund(claim);

if (!v.safe_to_claim_complete) {
  // Real but not final. Say "processing",
  // never "done" and never "failed".
  return hold(v);
}

await notifyCustomer("Your refund is complete.");
await closeTicket();

The SDK’s guard() goes further and returns the strongest customer message the evidence supports: complete, processing, or under review. The agent never gets to overstate what actually happened.

03/The first wedge

Where false completion hurts most.

Postcept starts with refunds, credits, and cancellations, the actions where agents touch money and customer trust, and where a wrong “done” can become a chargeback, a reopened ticket, and a broken promise. Here is exactly what Postcept checks before any of that can happen.

Verify Stripe refunds before closing support tickets

Detect duplicate refunds caused by retries and timeouts

Match refund amount, customer, currency, and ticket

Preserve operation IDs and idempotency context

Confirm Zendesk/Gorgias ticket state after payment verification

Produce signed receipts for audit and recovery

04/Adoption

Measure first. Enforce when the numbers earn it.

Same engine, same API, three postures. Start in Monitor without touching your workflow, then turn on the gate for your highest-risk action first.

Audit

Find the gap before changing anything.

Run the Refund Integrity Scan over your recent refunds. It reads the system of record and reports what settled, what is still pending, what duplicated, and what never happened.

Monitor

Verify every action, block nothing.

Call the API on each completion and watch the decisions accumulate: how often claims disagree with reality, how long finality takes, what would have been held. Reversals and reopens surface on re-verification.

Gate

No customer-facing done without a decision.

Your workflow branches on safe_to_claim_complete before it confirms, closes or notifies. Everything that fails the contract routes to recovery with the evidence attached.

05/The artifact

Every verification returns a signed receipt.

A Postcept Receipt is a tamper-evident JSON object: what the agent claimed, which systems were checked, every postcondition, the evidence, and a signature. Verified, failed, or duplicate, each outcome becomes signed evidence you can store, audit, and act on.

receipt.json

verified

{
  "receipt": "pcpt_rcpt_01HY9Q8F3X",
  "operation": "op_refund_8F31",
  "agent": "SupportAgent-04",
  "action": "refund_customer",
  "result": "verified",
  "systems": ["stripe", "zendesk"],
  "postconditions": {
    "refund_exists": true,
    "amount_matches": true,
    "customer_matches": true,
    "duplicate_check": "passed",
    "ticket_updated": true
  },
  "evidence": {
    "stripe": "re_4md82k",
    "zendesk": "#48921"
  },
  "signature": "ed25519:9f3c...a17b",
  "issued_at": "2026-06-23T09:41:26Z"
}

06/Trust boundary

Your credentials never have to leave your environment.

In Relay mode, provider credentials and raw records stay in your own infrastructure. The open-source relay reads the system of record, minimizes what it keeps, and signs what it observed. Postcept separately signs its evaluation. Both signatures ride on the receipt, and anyone can verify them offline against the published keys.

Observation role

Your relay signs what it saw

The relay runs in your VPC or locally with read-only credentials, reads the system of record, and signs the observation. Provider secrets and raw records never reach Postcept.

Evaluation role

Postcept signs the verdict

Postcept evaluates the signed observation against the versioned outcome contract and signs the result. Two signatures over distinct roles, observation and evaluation, neither able to forge the other, both verifiable offline.

Scoped, read-only access

Postcept reads only the records needed to verify an action, never more than the postcondition requires.

No write access

It confirms what happened. It never moves money, edits records, or takes actions on your behalf.

Signed, tamper-evident receipts

Every result is signed over its full contents, so any later modification is detectable.

Encrypted, least-privilege

TLS 1.2+ in transit, encrypted at rest, with scoped, revocable credentials.

Failures route to your queue

Incomplete and duplicate actions go to your review and recovery workflows, never to auto-action.

Runs alongside your stack

Keep your agent framework, workflow engine, and approvals. Postcept adds verification on top.

Read about our security posture

07/Proof

Verify us the way we verify agents.

The core technical claims trace to live artifacts you can inspect without asking us.

Witnessed transparency log

Signed log checkpoints are anchored to the public Sigstore Rekor transparency service, and every witness bundle sits in a public append-only history.

Inspect the bundles Independent uptime

The API is probed every 15 minutes from infrastructure outside the accounts that serve it, with every probe committed to a public history.

See the live history Provenance-attested releases

The verifier and SDKs publish through CI with signed provenance. npm audit signatures verifies the path from source to package.

Check the packages An open benchmark

The Completion Gap Gauntlet scores the live engine against baselines on a public set of safe completions and traps, reporting false safes and false blocks separately.

Run it yourself

08/FAQ

Questions, answered.

The short version of what Postcept does, how it's different, and how it handles your systems.

The completion gap is the difference between what an AI agent claims it completed and what the system of record proves actually happened, for example, an agent reporting a refund as processed when Stripe has no matching refund.

Prove what your agents actually did.

Add outcome verification to your high-risk agent actions. Keep your existing agent stack, workflow engine, and approvals. Postcept checks the system of record and signs the receipt.

Get started Book a demo