I’ve been building an open-source project called TraceMotive.
It started from a problem I kept running into with AI agents:
When an agent run fails, the place where the error appears isn’t always where the execution first started going wrong.
That makes debugging agent workflows harder than it looks.
So I built TraceMotive, a local-first tracing and debugging tool for AI agent execution.
What TraceMotive does
The current v0.1 includes:
- Python SDK
- canonical traces and spans
- a local Collector backed by SQLite
- a React UI for inspecting agent runs
- optional OpenAI Agents SDK integration
TraceMotive is local-first, and content capture is disabled by default.
I’m intentionally keeping the first version small. I’m not trying to add replay, automatic root-cause analysis, cloud sync, or support for every agent framework yet.
Why?
I’d rather get real feedback before adding a lot of features.
Right now I want people who actually build AI agents to try it and tell me:
- where setup is confusing
- what breaks
- what information is missing from traces
- what feels awkward in the API
The longer-term direction is:
“The causal debugger for AI agents.”
Eventually, I want TraceMotive to help identify where an agent execution first started going in the wrong direction, instead of only showing where the final error appeared.
But first, I want to make the basic observation and debugging layer solid.
Try it
PyPI:
pip install tracemotive
GitHub:
https://github.com/doraemonfv-glitch/tracemotive
If you build AI agents, I’d really appreciate you trying it for a few minutes and telling me what you run into.
Even small feedback is useful.
Top comments (5)
The local-first default is the important choice here. Agent traces get sensitive fast, especially when tool calls include prompts, file paths, or customer data. Are you planning to make redaction part of the trace schema, or leave it to each adapter?
Good question. I don't want redaction to be adapter-specific.
In v0.1, adapters normalize framework data into the canonical representation, and redaction happens before anything enters the transport queue. Content capture is also independently opt-in and disabled by default.
So it's not really “schema vs adapter” — I'm treating redaction as a core privacy boundary in the SDK path, so every adapter gets the same behavior instead of having to implement it correctly on its own.
Quick update: your question made me realize this boundary wasn't clear enough in the docs, so I clarified it in the README.
It now explicitly explains that redaction is handled at the shared pre-transport privacy boundary rather than being left to each adapter.
Thanks for pointing that out.
Nice writeup. I have been testing a system prompt as an AGENTS.md contract instead of a prompt and it changed how the model behaves more than any instruction tweak. Curious how you handle long context though, that is where mine still drifts.
That's actually one of the cases I'm interested in.
TraceMotive doesn't try to prevent or correct context drift in v0.1. Right now the goal is to make the execution observable enough that you can inspect what happened around the point where the behavior started changing.
Longer term, I'd like to make that kind of “where did this run first start going off track?” question easier to answer, but I want to get the observation layer right before trying to automate diagnosis.