What should AgentTrace observe next

[VeloraTech]

AgentTrace started with a simple question:

Which AI coding agent is actually running on my machine?

It can now detect supported coding agents, separate concurrent instances, follow their process trees, continuously observe them, record local history, supervise commands, and optionally track workspace changes.

The next question is more interesting:

What should AgentTrace actually be able to observe?

The longer-term goal is a local flight recorder for AI coding agents.

That means being able to distinguish things like:

• Which agent/process was running?
• Which child processes did it create?
• Which commands did it execute?
• Which files did it actually access?
• Which files did it create, modify, or delete?
• Did it access sensitive files such as .env?
• Which process performed the access?
• When did the access happen?
• What happened to that process afterwards?
• Can we distinguish observed evidence from what an agent claims it did?

For example, if an AI coding agent unexpectedly accesses .env, I don't want AgentTrace to simply say:

.env changed

I want to eventually be able to answer:

Which process accessed .env, what type of access occurred, when did it happen, and which agent did that process belong to?

That's the direction I'm thinking about.

I'm especially interested in hearing from developers who regularly use Claude Code, Codex, Gemini CLI, or other coding agents.

What would you actually want a local agent recorder to observe?

Feel free to suggest something specific, even if it sounds difficult to implement.

I'm using these discussions to help shape the next phases of AgentTrace.

[Keesan12]

I would add one event before expanding the recorder. Capture the acceptance check that was requested, who launched it, its exit code, and whether the agent could edit that check during the run. Process and file history tell you what happened. That binding tells you whether the agent actually proved the task was done.

I built MartinLoop. It is open source. If you want, I’d be glad to compare one AgentTrace session with a MartinLoop dossier and send back the gaps.

[VeloraTech]

Yeah, I think you’re right on that boundary. AgentTrace should stay focused on recording the evidence of what actually happened, while MartinLoop can use that evidence together with its own objective, verifier and constraints to decide whether the task actually passed.

And honestly, I’m definitely interested in trying the handoff. I think the interesting question now is exactly what you mentioned: what’s the smallest, cleanest piece of evidence AgentTrace should expose so something like MartinLoop can consume it without AgentTrace becoming coupled to MartinLoop. I’d be happy to work that out with you and test it against one real run. I think that could make for a pretty interesting integration between the two projects.

[VeloraTech]

Hey man, what’s good?

I’ve been working on the project -well, actually another project that I wanted to eventually layer on top of it — and then I realized I never actually heard back from you, so I figured it wouldn’t be nice of me not to check in lol 😊.

Hope everything’s good on your end. I’m guessing work might have gotten a bit hectic or something. Whenever you are up for it, I’d still really like to hear your thoughts on the handoff idea and how you think the two projects could interact, especially around having some agreed, accessible object/event definition that both sides can work with without either project being tightly coupled to the other.

[Keesan12]

I’d start with a neutral evidence envelope. Run ID, repository identity, start and end commit, ordered actions and failures, timestamps, process exit, artifact paths plus hashes, and the AgentTrace version that produced it. MartinLoop can keep the objective, verifier, budget, and final status on its side. That keeps observation separate from judgment and avoids coupling either project to the other’s schema. Pick a small repo and task and I’ll run the paired test.

[VeloraTech]

I’ll create the repo now. For now, let’s use TraceBridge as the default name; we can always decide on a different name later if you have a better one in mind.

I’ve also sent you an invite as a collaborator on that specific repo.

For development, let’s keep the main branch clean. We should each work on our own branches and only merge changes once they’ve been tested properly. That way, we don’t end up pushing broken or experimental code directly into main.

Before anything gets merged into main, we’ll run the relevant tests and use the actual test results to confirm that everything is working as expected.

The TraceBridge README will also document the objects/data that both AgentTrace and MartinLoop need to expose so that TraceBridge has a clear foundation to build against. That way, we can define what each project needs to provide before we start connecting everything together.

That should keep the repo stable while we build.

[VeloraTech]

hey @Keesan12 i have been expecting your response concerning the joint collab, but it seems you near-to ghosted me. Whats wrong?