Skip to content

Latest commit

 

History

1 Commit

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

A committed-state read as an Arize Phoenix integration

This is a small, runnable demonstration of Fathom reading an agent's committed state off an OpenInference trace, the same trace format Arize Phoenix captures. It shows the read catching a failure that the run's own signals report as a success, from the tool spans alone, with no model call.

Fathom is a coherence harness for long-horizon agents, built on an information theory that decomposes an agent's error into two sources: intrinsic task difficulty, and the reflexive burden an agent carries once its own past actions become part of the state it has to reconcile against. This demo is the surface of that instrument that reads the action-and-tool-return channel, which is the channel a reasoning agent still emits even when its deliberation moves into a hidden trace.

What it shows

The scenario is a five-file rename refactor: rename guest_id to customer_id everywhere, then run the tests. The tests do not import report.py, the ordinary coverage gap every suite carries. The same task runs under two configurations, each emitted as an OpenInference trace and read from its tool spans.

run (config)                 platform signals   committed-state   Fathom read
--------------------------------------------------------------------------------
coherent (capable model)     tests PASS + done  renamed           clean; silent
starved  (weak model)        tests PASS + done  5/5 unrenamed     FLAGGED: 5 outstanding

In the starved run the agent made no successful edit, then ran the suite, which passed on the unchanged original, and reported the rename complete. Both the completion message and the green suite read as success. The committed-state read is the only check that recovers the gap, and it attributes it: this is a self-tracking failure, so a stronger model is the wrong repair.

How it plugs into Phoenix

The reader consumes OpenInference TOOL spans, tool name, parameters, and the tool return with its success flag. Those are the spans Phoenix already stores for any instrumented agent, so nothing new needs to be captured. The one rule the read applies that a transcript does not: a tool return marked failure is a no-op, so an attempted edit that did not take effect leaves nothing behind in the reconstructed state.

demo.py runs the read over spans built in memory (no server needed). phoenix_ingest.py sends the identical spans to a live Phoenix instance over OTLP, so they render as a normal agent trace, and runs the same read over them.

Run

pip install -r requirements.txt
python demo.py              # the readout above
python demo.py --selftest   # power + specificity checks, exits non-zero on failure

Against a live Phoenix, see RUNBOOK.md.

Scope

This demonstrates the read on the committed-state channel. The information-theoretic decomposition that scores how much of a run's error is task difficulty and how much is reflexive burden is the hosted Fathom instrument and is not included here. The read is deterministic and oracle-free: it reconstructs from the repository the agent was handed and applies only the agent's own successful edits.

License

Apache-2.0. See LICENSE and NOTICE. Fathom™ is a trademark of Embedded Risk Analytics. OpenInference, Phoenix, and Arize are the property of Arize AI, Inc.; named here to identify the trace format this integration reads.


Embedded Risk Analytics · embeddedriskanalytics.com · Fathom™ is a trademark of Embedded Risk Analytics.

About

A committed-state read over OpenInference traces (Arize Phoenix). Fathom's coherence check, run off the tool spans Phoenix already captures.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages