Inspiration
Every time an agent repeats a task, it leaves a trace: what it did, in what order, and whether it worked. The knowledge of what actually works is buried in those logs, and flat files make the most valuable facts the hardest to ask for. Which steps have to happen in which order? Which step is only worth doing under one condition? What do the failures have in common? Those are relationship questions, so the traces belong in a graph.
What it does
TraceGraph on Relate ingests 200 traced episodes of Dispatch Day, a simulated home-service dispatch task, into a single-file Relate graph store: 200 runs, 9,115 steps, 13 actions, and every recorded failure, modelled as Run, Step, Action, and FailureCause nodes joined by HAS_STEP, PERFORMS, NEXT, NEXT_ON_JOB, and HAS_FAILURE edges.
Cypher queries over that graph then compute the compressed skill:
- The core method: the shared per-job action sequence of the successful runs, 9 actions.
- A conditional rule: episodes containing a provisional job succeeded 1.0 of the time when a reverify step exists in the graph and 0.0 when it does not, across 155 episodes.
- An ordering rule: one adjacency query over NEXT_ON_JOB edges shows the action immediately before schedule was check_tech_skill in 183 of 183 scheduled jobs in successful runs.
- The exclusion evidence: failure causes counted from HAS_FAILURE edges, so the skill can say what not to do, and how often each mistake appears in the traces.
The output is a portable SKILL.md whose every rule carries its trace evidence, plus the honest label that shortest means shortest among observed verified successes.
How I built it
Python with relate-db 1.0.1. ingest.py builds the persistent single-file store traces.rl from the raw trace JSONL, in transactions, and verifies node counts against the source file. compress.py opens the store read-only and runs the compression as Cypher: sequence extraction from successful runs, the provisional split, the NEXT_ON_JOB adjacency pattern, and the failure-cause counts. The same queries run through the relate CLI, so a judge can open the committed store and reproduce every number in the README without running my code.
Single-file mode was a deliberate choice: one trace set is one file, inspectable, portable, and versioned with the code that built it.
Challenges I ran into
Relate is brand new software, version 1.0.1, released days before this build. Parts of Cypher I reached for first, like relying on collect ordering for sequence extraction, behaved differently than in Neo4j, so sequence assembly reads ordered rows from the graph and the modal selection happens client-side. That split is documented in the code rather than hidden. The adjacency and evidence queries, the parts where the graph earns its place, are single Cypher patterns.
Accomplishments that I'm proud of
The graph compressor reproduces the exact output of the original flat-file compressor for this corpus, verified field for field against its published skill.json: same 9-action core, same conditional rules, same failure counts. The graph version is not an approximation of the result. It is the same result, computed from relationships, in a store anyone can open and query.
What I learned
Ordering facts are graph facts. The single most valuable rule in the corpus, the tech check must be the action immediately before scheduling, is invisible to frequency counting and obvious to an adjacency query. And failures are not noise to discard: as first-class edges they become the evidence that tells the next agent what not to do.
What's next
Ingest traces from real agent runs rather than a simulation, add the trace viewer over the same store, and connect the graph to the open trace format so any tool that emits traces can compress them this way. The separate question of whether an LLM agent follows the emitted skill better than a verbose procedure stays an open experiment, and its first small-model test did not pass its bar. That result stands as recorded.
Built With
- cypher
- graph-database
- python
- relate-db
