I stopped babysitting my coding agents. Here's the setup.

Coding agents are good at writing code. That stopped being my problem a while ago.

My problem showed up on bigger work, the kind that runs for days across several Claude Code and Codex sessions. Three questions kept coming back:

• Who made this call? An agent quietly settled a product decision on its own, because nothing stopped it. "Ask me before you decide X" lived in a prompt, and prompts get forgotten.
• Why did we do it this way? The reasoning was somewhere in a chat log, a PR description, a Slack thread, or nowhere.
• Is it actually done? The same agent wrote the code, wrote the test and reported success. CI helps, but it doesn't tell you whether every thing we agreed on has evidence behind it.

And then there were the terminals. Four agents, four windows, each one asking me something: delete these migrations? Discount before or after tax? Skip this flaky test? Is this new dependency OK? No way to tell which question was urgent, which one blocked half the plan, and which could wait until tomorrow. I was context-switching every minute and some agent was still always waiting on me.

So I built Teamtrail: a trail map for big work done by AI coding agents.

The idea: the work is a map of decisions

You describe where you want to go. An agent charts the work as a map of tickets with blocking edges between them. The unit isn't "task", it's a decision:

• research: find out how something works today
• prototype: try the risky thing first
• junction: a decision that belongs to you
• task and execute: build it and ship it
• review: a different agent checks the work, never the author

Agents claim tickets that aren't blocked, work in parallel (each in its own git worktree if you want), and when they hit a junction, they ask you instead of guessing.

That screen is the Lookout, a web app the teamtrail command serves on your own machine. Left: everything waiting on you, in one list, most important first, with the reason it's ranked there ("blocks 4 tickets"). Middle: the map. Right: the ticket you're looking at.

One inbox instead of four terminals

When an agent asks, the question lands in the inbox with the agent's suggested answers. You click one or type your own, and the agent picks it up and moves on. Your answer is tied to that exact question and ticket, so later nobody has to guess who decided.

Only urgent questions interrupt you. The rest waits in order. You can set focus hours, and Scout (Teamtrail's assistant) briefs you on what happened while you were away.

Decisions are records, not chat history

Every decision becomes a record: the question, the call, the alternatives that were considered, the rationale, who made it and where (you in the Lookout, you in Slack, or an agent on its own).

Agents can still settle low-risk things themselves. But they have to record them, so you can review and overturn them. What's always yours is set in a risk policy, one file in the repo:

{ "v": 1, "categories": { "data-deletion": "high", "billing": "high", "dependencies": "low" }, "paths": [{ "glob": "**/migrations/**", "level": "high" }] } 

An agent that tries to record a high-risk decision itself gets refused, in code, not in a prompt. And it's judged by the files git actually saw change, not only the ones the agent said it would touch.

"Done" means proven

Before implementation starts, each ticket gets acceptance criteria. When an agent reports completion, it has to bring evidence for every criterion. Teamtrail runs your checks itself (your tests, your lint) rather than trusting the agent's word, records the git evidence, and, at the verification level you choose, has a second agent review the work.

When an agent finds that an assumption in the plan was wrong, it doesn't quietly work around it. It challenges the assumption with evidence and proposes a reroute, and nothing in the plan changes until you approve it.

What it isn't

• It never calls a model. Lifecycle, gates, ranking and verification are deterministic code. The agents do the thinking; Teamtrail gives them structure and enforces the rules. It works with Claude Code, Codex or any MCP client.
• It doesn't run your agents. You start them the way you always do. Teamtrail is the map and the rules, not an orchestrator.
• It's local-first. Trails are plain markdown files in .teamtrail/ in your repo, or issues in GitHub or Linear if your team lives there. No server, no account. The optional Slack app (Scout answers questions and takes your answers in Slack) is the one part that goes through a service.
• It's not for everything. A bug fix or one endpoint? Just ask your agent. Teamtrail is for work that runs for days.

Try it

In a repo you want to work on:

npx teamtrail@next connect claude # or: connect codex npx teamtrail@next 

The first command registers Teamtrail's MCP server with Claude Code and adds a /scout command. It also keeps the agent out of Teamtrail's own config folder, and offers to turn on Claude Code's sandbox so its shell commands can't reach it either. The second opens the Lookout in your browser.

Then in Claude Code:

/scout new "the big thing you've been putting off" 

Scout asks a few questions to frame it, the agent charts the trail, and the first question for you shows up in the inbox.

(@next is the current build. It's early: expect rough edges, and please tell me about them.)

• Site: https://www.teamtrail.app/?utm_source=devto&utm_campaign=launch-nov
• GitHub: https://github.com/teamtrailhq/teamtrail?utm_source=devto&utm_campaign=launch-nov

If this matches a pain you have, a star on GitHub helps a lot. And I'd really like to hear how you keep track of what your agents decide today. Tell me in the comments.

A note on the license, because someone will ask: Teamtrail is source-available under FSL-1.1-ALv2. You can read, run and modify it for any purpose except offering a competing product, and every release becomes Apache 2.0 two years later.
Coding agents are good at writing code. That stopped being my problem a while ago.

My problem showed up on bigger work, the kind that runs for days across several Claude Code and Codex sessions. Three questions kept coming back:

• Who made this call? An agent quietly settled a product decision on its own, because nothing stopped it. "Ask me before you decide X" lived in a prompt, and prompts get forgotten.
• Why did we do it this way? The reasoning was somewhere in a chat log, a PR description, a Slack thread, or nowhere.
• Is it actually done? The same agent wrote the code, wrote the test and reported success. CI helps, but it doesn't tell you whether every thing we agreed on has evidence behind it.

And then there were the terminals. Four agents, four windows, each one asking me something: delete these migrations? Discount before or after tax? Skip this flaky test? Is this new dependency OK? No way to tell which question was urgent, which one blocked half the plan, and which could wait until tomorrow. I was context-switching every minute and some agent was still always waiting on me.

So I built Teamtrail: a trail map for big work done by AI coding agents.

The idea: the work is a map of decisions

You describe where you want to go. An agent charts the work as a map of tickets with blocking edges between them. The unit isn't "task", it's a decision:

• research: find out how something works today
• prototype: try the risky thing first
• junction: a decision that belongs to you
• task and execute: build it and ship it
• review: a different agent checks the work, never the author

Agents claim tickets that aren't blocked, work in parallel (each in its own git worktree if you want), and when they hit a junction, they ask you instead of guessing.

That screen is the Lookout, a web app the teamtrail command serves on your own machine. Left: everything waiting on you, in one list, most important first, with the reason it's ranked there ("blocks 4 tickets"). Middle: the map. Right: the ticket you're looking at.

One inbox instead of four terminals

When an agent asks, the question lands in the inbox with the agent's suggested answers. You click one or type your own, and the agent picks it up and moves on. Your answer is tied to that exact question and ticket, so later nobody has to guess who decided.

Only urgent questions interrupt you. The rest waits in order. You can set focus hours, and Scout (Teamtrail's assistant) briefs you on what happened while you were away.

Decisions are records, not chat history

Every decision becomes a record: the question, the call, the alternatives that were considered, the rationale, who made it and where (you in the Lookout, you in Slack, or an agent on its own).

Agents can still settle low-risk things themselves. But they have to record them, so you can review and overturn them. What's always yours is set in a risk policy, one file in the repo:

{ "v": 1, "categories": { "data-deletion": "high", "billing": "high", "dependencies": "low" }, "paths": [{ "glob": "**/migrations/**", "level": "high" }] } 

An agent that tries to record a high-risk decision itself gets refused, in code, not in a prompt. And it's judged by the files git actually saw change, not only the ones the agent said it would touch.

"Done" means proven

Before implementation starts, each ticket gets acceptance criteria. When an agent reports completion, it has to bring evidence for every criterion. Teamtrail runs your checks itself (your tests, your lint) rather than trusting the agent's word, records the git evidence, and, at the verification level you choose, has a second agent review the work.

When an agent finds that an assumption in the plan was wrong, it doesn't quietly work around it. It challenges the assumption with evidence and proposes a reroute, and nothing in the plan changes until you approve it.

What it isn't

• It never calls a model. Lifecycle, gates, ranking and verification are deterministic code. The agents do the thinking; Teamtrail gives them structure and enforces the rules. It works with Claude Code, Codex or any MCP client.
• It doesn't run your agents. You start them the way you always do. Teamtrail is the map and the rules, not an orchestrator.
• It's local-first. Trails are plain markdown files in .teamtrail/ in your repo, or issues in GitHub or Linear if your team lives there. No server, no account. The optional Slack app (Scout answers questions and takes your answers in Slack) is the one part that goes through a service.
• It's not for everything. A bug fix or one endpoint? Just ask your agent. Teamtrail is for work that runs for days.

Try it

In a repo you want to work on:

npx teamtrail@next connect claude # or: connect codex npx teamtrail@next 

The first command registers Teamtrail's MCP server with Claude Code and adds a /scout command. It also keeps the agent out of Teamtrail's own config folder, and offers to turn on Claude Code's sandbox so its shell commands can't reach it either. The second opens the Lookout in your browser.

Then in Claude Code:

/scout new "the big thing you've been putting off" 

Scout asks a few questions to frame it, the agent charts the trail, and the first question for you shows up in the inbox.

(@next is the current build. It's early: expect rough edges, and please tell me about them.)

• Site: https://www.teamtrail.app/?utm_source=devto&utm_campaign=launch-nov
• GitHub: https://github.com/teamtrailhq/teamtrail?utm_source=devto&utm_campaign=launch-nov

If this matches a pain you have, a star on GitHub helps a lot. And I'd really like to hear how you keep track of what your agents decide today. Tell me in the comments.

A note on the license, because someone will ask: Teamtrail is source-available under FSL-1.1-ALv2. You can read, run and modify it for any purpose except offering a competing product, and every release becomes Apache 2.0 two years later.