Testimony Records from AutoGen
pip install testimony-autogen
Or one file: copy testimony_autogen.py and
testimony_emit.py next to your agent. There is
nothing else to install and nothing here depends on OMEM.
from autogen_core.tools import StaticWorkbench
from testimony_autogen import Recorder
def decide(req):
# req.action, req.arguments, req.risk_class.
# Your approval UI, queue or ticket goes here. The identity has to come
# from your authentication layer; this adapter has none to find.
if req.action == "close_account":
return req.refuse("a balance is outstanding")
return req.approve(approver={"id": "r.okonkwo@example.com", "kind": "human"},
identity_source="auth-session")
rec = Recorder(
agent={"id": "support-agent", "kind": "agent"},
risk={"issue_refund": "high", "close_account": "high",
"search_docs": "low"},
decide=decide,
)
workbench = rec.gate(StaticWorkbench(tools)) # hand this to the agent
...
rec.write("record.jsonl")
$ python3 testimony_validate.py record.jsonl
Conformance: TR-4
Why the workbench is the right boundary
Workbench.call_tool is the one place every tool call passes through, and it
is an abstract method on a public class, so a workbench that wraps a workbench
is a supported thing to build rather than a trick.
autogen#7405 and the open
issue proposing a workbench-level approval gate are asking for exactly this
seam.
list_tools passes straight through, so the model sees the same schemas, and
start, stop, reset, save_state and load_state all delegate to the
workbench underneath. The agent, the model client and the team configuration
are untouched.
Colorado asks for this from 1 January 2027
Proposed Rule 7.7 under Colorado's Automated Decision-Making Technology Act requires a deployer to retain a record showing, when a human reviews an automated decision: the reviewer's identity, review timestamps, the primary evidence available to them, whether they approved, modified or overrode the output, and a written justification. The rules were filed on 11 August 2026 and take effect with the act on 1 January 2027 if adopted. They are not law yet.
A reading of ten widely deployed agent systems found that of the eight which take or gate consequential actions, one can identify the person who approved one, and that one is the reference implementation of this specification, which is disclosed rather than left to be found.
What this framework can show, measured
AutoGen has no approval pause of its own, which is why this adapter works at the workbench rather than at a hook: there is no boundary in the framework to attach one to. That is not a criticism. It is a multi-agent conversation library and it never claimed to be an authorisation layer.
The consequence for Rule 7.7 is direct. Nothing in a plain AutoGen run identifies a person on any approval path, because there is no approval path, so every one of the six things the rule asks a record to show has to come from the boundary you put around it.
Read 4 to 6 September 2026 at machinetestimony.org/register/, with the file and line behind every verdict.
What it will not do
It will not fail open. If your decide returns anything that is not a
decision it issued, the call raises and the tool does not run.
openai-agents-python#4845
is the same mistake in a shipped SDK: a callable needs_approval predicate
returned None from an unhandled branch, None read as "no approval needed",
and the gate opened on the path nobody had considered.
It will not classify risk from anything the model produced, invent an approver, let the acting agent approve its own action, or accept an identity source the model could have written.
It will not gate call_tool_stream, and says so rather than pretending. A
decision has to precede the action, and a stream that has begun has already
acted. Use call_tool for anything that needs an approval on the record.
A refusal comes back as a ToolResult with is_error set, because that is how
a workbench already reports a call that produced no result. It is recorded with
the same standing as a permission: a system that records only what it did is a
receipt, not an account of itself.
Tests
tests/tests_autogen_testimony.py, 28 checks, run against a real
autogen_core workbench. CI installs the library and fails if the suite skips.
MIT. Copyright 2026 Garnet Taurus Ltd. The specification: https://datatracker.ietf.org/doc/draft-clifford-testimony-record/
Metadata
Release files for testimony-autogen 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| testimony_autogen-0.2.1.tar.gz | 38.8 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| testimony_autogen-0.2.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 80.2 kB
Release files / testimony_autogen-0.2.1.tar.gz
| Download URL | testimony_autogen-0.2.1.tar.gz |
|---|---|
| Size | 38.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
e82334831d42419c169bdffbb89ad1c61cb1544eb4d976ef0ae9a64e0f6140aa
|
|
BLAKE2b-256 checksum How to use checksums |
902f54334c1136b9d378ba2ffb7269e20f08566273cea0bf859930be2a05078d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.
Transparency logRelease files / testimony_autogen-0.2.1-py3-none-any.whl
| Download URL | testimony_autogen-0.2.1-py3-none-any.whl |
|---|---|
| Size | 41.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5cae77d235100313cdb6be485315d9fd7eb029b2311e9b527a0942f07f61ae7f
|
|
BLAKE2b-256 checksum How to use checksums |
c5b82ab15ea6ce656cf5d9a3136e545f651f6d5c10d0e7742aa9e9f28f24af5a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.
Transparency logSecurity for testimony-autogen 0.2.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for testimony_autogen-0.2.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.