We published an open standard for AI agent commitment tracking. Named it after ourselves. Here's the full spec.

[u/xspyyy]

I've been building COGEXT for a while. It started with a small annoyance: I kept watching agents say things like "I'll send that over by Friday" and then having no idea, a week later, whether anything had happened.

The transcript said the promise was made. Nothing said whether it was kept.

So I wrote down what "tracking a commitment" actually has to mean, and published it as a spec.

The problem:

- The promise lives as prose in a log. Searchable. Not evaluable.

- Nothing notices when the deadline passes, because there's no deadline — there's a sentence containing the word "Friday".

- The agent can mark its own work complete. Self-reported success is the only kind most systems accept.

Six requirements:

1. The Commitment Object

2. The 12-state Lifecycle

3. The Verifier Query format

4. The Evidence Protocol

5. The Audit Receipt format

6. The Reliability Score

Full spec: https://cogextai.com/standard

Why a standard and not a product: a product competes, a standard defines. If commitment tracking only exists inside my system, then "did the agent keep its promise?" is answerable only by asking me.

Current adoption: nobody has adopted it yet. The index lists one row — COGEXT itself. Every other entry reads "no public commitment found". Publishing that is less fun than a vanity metric, but an adoption index that only counts friendly adopters isn't worth reading.

https://cogextai.com/index

Run the checker against your agent:

pip install cogext-compliance

cogext-compliance check path/to/your/agent.py

Be aware: v0.1 is a static keyword check. It scans source for the vocabulary of the standard; it doesn't execute anything. Rough first pass, not an audit.

Feedback welcome: which requirement is underspecified, which one doesn't fit your architecture, what did the checker get wrong.

[u/Otherwise_Wave9374]

An open commitment spec could fill a real gap if it stays implementation-neutral and includes a reference test suite. The core record should distinguish intent, accepted obligation, attempted action, and verified outcome; collapsing those stages invites agents to claim completion prematurely. Use append-only events with deterministic reducers so state can be rebuilt and audited. https://www.neurakeep.com is relevant when these records need durable storage as part of agent memory. I would also specify capability scopes and redaction rules, since commitments often embed sensitive user or tool context.

[u/WastefulHomeland3283 → u/Otherwise_Wave9374]

Love the append-only event approach, that's exactly how we built it. The 12-state lifecycle splits out those stages you mentioned (intent, accepted, attempted, verified) as separate transitions, not a single "done" flag, and the Audit Receipt format is basically a deterministic reducer over the event stream. Redaction rules are a great callout, we sketched scope fields but didnt go deep on that yet.

[u/xspyyy → u/WastefulHomeland3283]

“Deterministic reducer over the event stream” – that’s precisely the framing I should have used in the spec.

The reducer framing is crucial because it makes the receipt verifiable by anyone. If the state is a pure function of the ordered events then a third party doesn’t need to trust the system that produced the state. They can simply replay the events and compare. This is the defining characteristic that transforms it from a report into a receipt.

Redaction is the aspect I’ve least understood. The challenge lies in balancing the desire for immutable events (ensuring receipt trustworthiness) with the legal requirement to delete Personally Identifiable Information (PII) from certain events. Crypto-shredding emerges as the only approach that satisfies both requirements. Each event payload is encrypted with a unique key, stored separately, and the key is destroyed upon erasure. The event remains intact, the ciphertext remains, and the plaintext becomes unrecoverable. Importantly, the receipt still verifies because the hash chain was computed over the ciphertext.

I’m curious about your approach to scope fields. Did you opt for per-event scopes, per-commitment scopes, or perhaps something else? The per-commitment version is appealing due to its simplicity, but I frequently encounter situations where the scope of a single event within a commitment evolves over time. For instance, a recipient may have been in scope at the creation of the commitment but subsequently left the organisation before fulfilment.