Prove what your AI agents actually did.
CommitLayer verifies that every action an agent takes in your business systems was valid, within limits, and produced the intended outcome. Independent of what the agent says.
Read-only connectors. No agent changes required.
Agents no longer just answer. They act.
A support agent now takes a message on WhatsApp, updates the CRM, refunds the order and closes the ticket — across four systems, in seconds, without a human in the loop. The risk moved from “did it answer wrong” to “did it act wrong”.
- Agent
- Salesforce
- Shopify
- Zendesk
Wrong customer
Executed twice
Exceeded permissions
Downstream state never reached
One refund. Four expected effects. One that never happened.
The agent reported success. The payment was refunded, the CRM was updated and the customer was told — but the order in Shopify stayed active. The verdict comes from the systems of record, not from the agent.
- stripe.refund_created observed within 15m of the actionobserved 10:42:07
- shopify.order_cancelled observed within 15m of the actionNOT OBSERVED
- crm.note_added observed within 15m of the actionobserved 10:42:09
- messaging.customer_notified observed within 15m of the actionobserved 10:42:11
Define → Record → Observe → Verify
- 1
Define
An action contract in YAML: the allowed action, required inputs, expected effects, limits, and forbidden effects.
contract: refund_workflow action: refund_order required_inputs: [amount, currency] limits: amount: { lte: 250 } expected_effects: - stripe.refund_created - shopify.order_cancelled forbidden_effects: - duplicate: stripe.refund_created - 2
Record
The agent's action, via one API call or an OpenTelemetry span. No change to the agent's logic.
POST /v1/actions { "contract_id": "refund_workflow", "action_type": "refund_order", "subject_id": "order_10231", "params": { "amount": 180 } } - 3
Observe
Read-only facts from the systems of record. Never the agent's own account of what it did.
shopify order_status 10:41:30 stripe refund_created 10:42:07 crm note_added 10:42:09 messaging customer_notified 10:42:11
- 4
Verify
PASS / FAIL / UNKNOWN per lens with plain-language reasons, hashed and chained to the previous verdict.
outcome: FAIL policy: FAIL reason: expected_effect_missing: shopify.order_cancelled hash: sha256:3f9a2c… prev: sha256:b21c7e…
Three verdicts, plain-language reasons.
Every action gets exactly one verdict per lens: outcome (did the intended change land?) and policy (was the action valid and within limits?). Reason codes explain why, in words an operator and an auditor can both read.
| Reason code | Label | In plain language |
|---|---|---|
| precondition_unmet | Precondition not met | A fact the contract requires before the action may run was not observed in the system of record, or did not have the required value. |
| limit_exceeded | Limit exceeded | A parameter of the action was outside the limit set in the contract, for example a refund amount above the cap. |
| expected_effect_missing | Expected effect not observed | The contract expects a change in a system of record after the action, and no matching fact was observed inside the settlement window. |
| forbidden_effect_observed | Forbidden effect observed | A fact the contract forbids, for example a second refund on the same order, was observed inside the window. |
| duplicate_effect | Duplicate effect | The same effect was observed more than once for the subject, which suggests the action was executed twice. |
| effects_pending | Effects still within settlement window | Not every expected effect has been observed yet, and the settlement window has not closed. The verdict is UNKNOWN until it does. |
| verified_condition_not_met | Verified condition not met | None of the conditions that would verify the claim were satisfied. |
| duplicate_claim_for_subject | Duplicate claim for subject | Another claim for the same subject exists in the same billing period; only the earliest counts. |
| missing_fact_source | Required fact source not connected | A fact source the definition depends on is not connected, so there are no facts to verify against. |
| identity_unmatched | Subject not found in fact sources | The claim's subject could not be found in any connected fact source, so nothing can be verified either way. |
One verification layer, two applications.
CommitLayer Verify
Action contracts for agents that act in your systems. Define what a valid action looks like, record what the agent did, and get a PASS / FAIL / UNKNOWN verdict from the systems of record — with a hash chain you can verify publicly.
CommitLayer Reconcile
Outcome-priced vendor invoices, verified against your systems of record. Monthly statements, invoice reconciliation, dispute packages. Covers outcome-priced vendors such as Intercom Fin, Zendesk AI, Sierra, Decagon and Agentforce, each cited to its public definition.
Every contract in plain language — cited.
Action contracts spell out preconditions, limits, expected and forbidden effects. Vendor outcome definitions are transcribed from public documentation with source URL and retrieval date; fields the vendor has not published are listed as unknown, not assumed.
Decagon states you pay only when the AI resolves a conversation from start to finish and that there is no charge when the case is passed to a human. The vendor notes that defining a resolution 'can be tricky'. No public operational definition exists, so the vendor lens below is a conservative placeholder to be replaced with the criteria in your Decagon order form.
Retrieved 2026-09-11 · 6 unknown fields
Template for vendors without a built-in connector. Claims come from a CSV/XLSX export mapped in the Connections screen. Replace the vendor lens with the definition in your contract and cite it.
Retrieved 2026-09-11 · 3 unknown fields
HubSpot charges 50 credits (USD 0.50) per resolved conversation on text-based channels. The Knowledge Base defines a resolution as a conversation with at least one customer-agent reply that shares a content source or performs an action, and no qualifying (visitor-initiated) handoff to a human within 72 hours of the last visitor response.
Retrieved 2026-09-11 · 2 unknown fields
A Procedure handoff is counted when Fin successfully executes a Procedure configured to end in a handoff to a human or a workflow. Verified when the handoff (escalation/assignment) is observed in the conversation record.
Retrieved 2026-09-11 · 1 unknown field
Built to be trusted by the people who sign off on agent actions.
Connectors request read-only, least-privilege scopes, listed in the Trust Center with the exact fields pulled. Action contracts observe; they never write to your systems.
Every verdict under an action contract is hashed and chained to the previous one. Verdict, statement and dispute-package hashes are publicly verifiable.
CommitLayer is paid by customers only. No payments, partnerships or data deals with the agent platforms or vendors it verifies.
How large might your definition delta be?
For CommitLayer Reconcile: enter what you are billed and an assumed strict-lens rate. The output is a range, labeled as an estimate.
Priced by verified actions, not by what the agent claims.
Every plan includes both modules. Developer is free with no time limit; paid plans start with a 14-day trial and no card.
Developer
No card, no time limit
Engineers wiring the first agent to action contracts.
- Verified actions / mo
- 1,000
- Connections
- 1
- Contracts
- 2
- Seats
- 2
Starter
14-day free trial, no card
One team, one agent workflow, one vendor invoice.
- Verified actions / mo
- 5,000
- Connections
- 2
- Contracts
- 3
- Seats
- 3
GrowthPopular
14-day free trial, no card
Several agent workflows across payments, commerce, CRM and support.
- Verified actions / mo
- 50,000
- Connections
- 5
- Contracts
- 10
- Seats
- 10
Scale
14-day free trial, no card
A platform team running agents from more than one vendor.
- Verified actions / mo
- 250,000
- Connections
- 10
- Contracts
- —
- Seats
- 25
Enterprise
Annual agreement
Agent governance across the company, with procurement and security review.
- Verified actions / mo
- —
- Connections
- —
- Contracts
- —
- Seats
- —
Questions an operator asks first.
- What does UNKNOWN mean?
- It means the facts needed to decide are not available: the settlement window is still open, a system of record is not connected, or the subject could not be matched. It is reported separately from FAIL so you can close the gap, and it is never counted as a failure.
- Does CommitLayer block actions?
- No. Today it verifies after the fact and in shadow mode: the agent acts, the facts land in your systems, and the verdict follows. Enforcement is on the roadmap and off by default.
- Where do the facts come from?
- From your systems of record — payments, commerce, CRM, helpdesk, messaging — through read-only connectors, CSV uploads or a facts API. The agent's own report of what it did is recorded, but it is never used as evidence.
- Do I need to change my agent?
- No. Record actions with one API call, or send OpenTelemetry spans from the agent runtime you already have. The contract, the observation and the verdict live outside the agent.
- Does a language model decide verdicts?
- No. Verdicts come from deterministic rules compiled from the contract and evaluated against facts. Transcript assist in the Reconcile module is opt-in, sampled, cost-capped, and only produces calibration labels; it never changes a verdict.
- Can I verify a verdict without an account?
- Yes. Every verdict and every statement carries a hash. Paste it into the public verification page to confirm the document exists and its chain is intact.
- Do you take money from vendors?
- No. CommitLayer is paid only by the customer whose agents and invoices it verifies. We do not accept payment, referral fees, data or partnerships from vendors whose claims we verify. See the independence policy in the Trust Center.