Prompts the operator pins and rolls back.
Instead of editing prod prompts in place and hoping nothing breaks, the operator promotes governed versions — changed only by a receipted action, rolled back in one move, and joined to every output they produced.
When a prompt change breaks production, the operator already knows which one
The operator stores every prompt as an immutable version (slug@N) and moves promotion labels like @prod and @staging by receipted action, never by editing in place. Render compiles a template; Completions renders and dispatches in one call — writing a parent receipt and a join row.
That join links every production output to the exact template_id@version behind it. When something breaks, the operator traces the output to the prompt version, and the prompt version to who promoted it and when — and rolls it back in one move.
- Pins immutable versions. Every change becomes a new monotonic version; a rollback copies the old body forward, never overwrites.
- Moves labels by receipt. @prod / @staging are audited pointers the operator repoints, not edits in place.
- Joins output to prompt. Each completion links back to the template version that produced it — on the record.
Every output traces to a prompt version
Instead of correlating logs after an incident, the operator writes a join alongside each receipt — so an output is always attributable to the exact template version behind it, a link a regulator can follow without us.
The receipt links to the prompt version
When the operator runs a completion through the registry, it writes a parent receipt joined to template_id@version. Recompute the leaf to confirm the dispatch record, then follow the join to the exact prompt that produced it.
This is the same client-side verification shipped on the Trust portal. SHA-256 runs via Web Crypto. No Agentics call.
- •Recompute leaf
- •Chain integrity
- •Fold Merkle proof
- •Anchor memo == root
SHA-256 runs in your browser via Web Crypto. No Agentics call.
Render to preview, complete to ship
Instead of templating in your app and logging on the side, Render compiles only; Completions renders and dispatches, and the operator writes the receipt and the join.
curl -X POST https://agentics.you/api/prompts/support-triage/render \
-H "Authorization: Bearer ak_…" -H "Content-Type: application/json" \
-d '{ "version": "@prod", "vars": { "ticket": "login broken" } }'
# → { messages: [...] } (no provider call, no receipt)curl -X POST https://agentics.you/api/prompts/support-triage/completions \
-H "Authorization: Bearer ak_…" -H "Content-Type: application/json" \
-d '{ "version": "@prod", "vars": { "ticket": "login broken" },
"model": "@anthropic/claude-opus-4-8" }'
# → completion + x-agentics-receipt, joined to template@versionSupervise versions and labels
Instead of digging through deploy logs, the console shows every prompt version, where each label points, who promoted it, and what each version produced.
Prompt Registry console
Prompt versions with promotion labels the operator moves, plus the outputs each version produced via the join.
Open Prompt Registry →