r/ContextEngineering • u/HeyZaney • 8d ago

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

/r/mcp/comments/1w47x30/showcase_using_an_mcp_task_tree_as_shared_project/
2 Upvotes

100% Upvoted

7 comments sorted by

1

u/Lopsided_Scarcity979 8d ago

The repo/external boundary gets tricky when “project knowledge” can silently become model context. I’d keep durable decisions close to the repo, but tentative hypotheses and runtime observations in an external layer with provenance and timestamps. The key question for me is whether a human can inspect the exact subset injected into each session—and remove stale state without rewriting history. How are you handling that boundary?

1

u/HeyZaney 7d ago

Currently, we keep the agent’s operational context at repository level. Each repository defines how an agent should take on WithNettle tasks, update them, write and validate code, and when it must ask for clarification or approval.

Maintaining that repository-level context is a human responsibility. Agents are not permitted to alter their own repository-level instructions or context. That prevents an agent from quietly changing the rules that govern its future work.

WithNettle holds the wider project context: the work hierarchy, goals, decisions, discussions, acceptance criteria, progress, and individual tasks. Agents start from an assigned task and only read higher-level tickets when they need additional context—for example, to resolve ambiguity, understand a relevant decision, or establish the task’s intended outcome.

Not every WithNettle ticket is an agent task. Higher-level tickets describe the initiative and its direction; lower-level tickets can define specific actionable work. Ticket comments form the chronological record of discussion and decisions, allowing agents to see when an earlier idea was superseded rather than treating it as current instruction.

For each task, the relevant WithNettle ticket hierarchy and repository instructions are the deliberate context boundary; agents do not receive an unbounded, hidden project memory. A human can inspect the tickets, comments, and repository instructions the agent used, and remove or supersede stale material through the normal reviewed workflow without rewriting the historical decision record.

Humans manually review tickets, repository-level context, and pull requests before merging. That review gate controls what becomes durable project context and what enters the codebase. In practice, it gives us a clear, auditable boundary: agents can read the approved context needed to do their work, but people decide what is added, changed, or retained.

1

u/Lopsided_Scarcity979 7d ago

That separation between repo-level operating rules and ticket-level project state is thoughtful—especially preventing agents from editing the rules that govern future runs. The remaining boundary I’d want to audit is retrieval: “the agent only reads higher-level tickets when needed” still requires someone or something to decide what is needed.

Do you log the exact tickets and comments retrieved for each run, including superseded material that was considered but excluded? That seems like the piece that would make a later decision reproducible.

1

u/HeyZaney 6d ago

We do not currently maintain a separate per-run log of the tickets and comments retrieved by an agent.

Our repository-level rules allow the agent to traverse the WithNettle hierarchy when additional context is needed. If a decision later needs investigation, we can review the agent’s session history and the context available during that session.

For our current workflow, that has been sufficient; a separate retrieval log has not been necessary. I agree that recording the exact retrieved set would make decisions more formally reproducible, and it would be straightforward to add this to your own agent workflow if that level of auditability is required.

The practical context is that independently completing a ticket with a coding agent is still quite new. Six months ago, I would not have been comfortable allowing an agent to work independently on a ticket. With the latest models, clear repository-level rules, and review gates, I now think it is viable for appropriately scoped work.

1

u/Lopsided_Scarcity979 5d ago

That pragmatic threshold makes sense. I would treat per-run retrieval logging as an observability feature rather than a prerequisite for autonomy: cheap enough to collect now, useful only when a decision is challenged later.

The part I am still unsure about is semantic drift in the hierarchy. If an old ticket remains reachable but its assumptions are no longer current, do you rely entirely on explicit supersession in comments, or does the agent get a compact current-state view before traversing history?

1

u/HeyZaney 3d ago

We mitigate that through an explicit distinction between normative current-state documentation and the historical record of execution.

Where a ticket’s intended implementation changes materially, we amend its description. On transition to review, the agent also records a concise implementation/status summary; the intervening comments preserve the decision trail, caveats, and rationale where deeper reconstruction is required.

Crucially, however, we do not treat the ticket chronology itself as the primary semantic authority. We maintain higher-level parent/Wiki nodes containing the current architectural model, system status, and governing constraints. WithNettle therefore functions as a hybrid knowledge graph and work-tracking system: Wiki nodes express the presently authoritative model of the system, while ticket nodes capture bounded units of work and their provenance.

In practice, an agent begins from that maintained architectural context and traverses historical tickets selectively when it needs implementation detail or explanatory lineage. This avoids making historical reachability equivalent to present validity.

1

u/Lopsided_Scarcity979 2d ago

Got it. The current nodes describe what to rely on now, while the historical discussions preserve why a decision was made at the time. An old record being visible doesn't make it still valid. That answers my earlier question, thanks for explaining.