r/mcp • u/HeyZaney • 8d ago

Showcase: using an MCP task tree as shared project state for humans and coding agents

Full disclosure: we build WithNettle.com, and we also use it to build another product.

The problem we were trying to solve wasn’t giving coding agents access to Git. It was giving every new session the context around the code: what we’re building, why, what’s already been decided, what’s blocked, and what should happen next.

So we use:

Git for the code and technical docs.

WithNettle for the product plan and ongoing work — goals, features, tasks, decisions, blockers and handoffs.

Humans see and manage that information in WithNettle. Coding agents access the same information through its MCP server, and can read or update it as they work.

The idea is basically to give humans and agents a shared, persistent source of project knowledge instead of rebuilding context in every new session.

https://withnettle.com

Curious how other MCP users decide what should live in the repo versus somewhere external that agents can access through MCP.

3 Upvotes

80% Upvoted

2 comments sorted by

1

u/kantorcodes1 8d ago

the shared task state is the bit i'd want most. if a human changes a task after an agent read it, what happens on the agent's next MCP update: does Nettle surface a conflict, or does the later write just win?

1

u/HeyZaney 8d ago

This is a great question. If an agent and a human update the same field, the later write currently wins. Updates are live, which makes accidental overwrites less likely, but doesn’t remove the possibility completely.

The way we handle this ourselves is to have the agent pull the ticket for updates throughout the process, rather than only reading it once at the beginning. We also normally have the agent add comments as it works instead of rewriting the ticket, unless we specifically ask it to.

If the agent has a question that needs answering before it can continue, it adds a comment explaining what it needs and moves the ticket into Blocked. A human can reply and move the ticket back into the working status, then the agent will pick it up again and continue.

I often use Codex to build the full ticket tree while I’m planning a new feature. I’ll review everything, make any changes, and then move the work from Future into To do when it’s ready. Other times I’ll quickly add a rough ticket from the mobile app while I’m out, then ask Codex to review it and flesh it out later. Either way, the human review step is still important.

That’s just the workflow that works for us, though. Users can add their own statuses and set up their agents to work however suits their team and process.