Track execution

Tracking execution is how the context network stays accurate over time. You drive it in plain language. The agent does the recording as it works: it claims the task, reads its context, builds, and writes back what it built so the next task starts from ground truth.

Pick up a task

You do not open the MCP tools yourself. You ask the agent what to work on, then point it at a task.

what should I work on next?

The agent reads the graph and names the top ready task on the critical path. Tell it to start, and it claims the task as it begins, moving it to in_progress so no one else picks up the same work.

let's do MET-1

When a task may have drifted since it was written, ground the agent before it claims:

MET-1. Read the task, then explore the codebase and the current library docs
before you claim it. Validate the plan against what shipped and flag anything
stale. No speculative decisions: search and read first. The task is done when
review returns nothing critical.

This grounds the work against live code and current docs instead of trusting a task that may be out of date.

Let the agent build with context

Before writing code, the agent pulls the task's full context on its own: the implementation plan, the execution records of upstream tasks, the prerequisites, and the acceptance criteria. You do not fetch any of this by hand. You review what it surfaces, correct it where needed, and let it work.

Record the outcome

When the work is done, the agent records three things on the task:

• Execution record: a few sentences on what was built, with function names, file paths, and patterns.
• Decisions: one line per technical choice, the choice and why.
• Files: every file created or modified.

It opens a pull request if the work changed code, then marks the task in_review. That is the agent's terminal write. It does not move the task to done; you do that after you approve the PR. See Task lifecycle for the full sequence and Human on the loop for the approval gate.

You can drive the close-out with a prompt:

move MET-1 through the completion protocol. The PR body uses the repo template and
contains only what the PR actually ships. Rewrite the execution record to match the
shipped diff, not the original plan.

Once you have reviewed and merged the PR, the status flip is short:

PR merged. Flip MET-1 to done.

Context flows downstream for you

Once the task lands, its execution record is available downstream on its own: when a dependent task is worked on later and its agent asks for context, it receives:

• Your task's execution record (what was built).
• The edge note explaining why the dependent task depends on yours.
• Your task's status (confirming the dependency is satisfied).

No manual forwarding or copy-pasting. If a decision you made changes a downstream task, ask the agent to check impact ("does this change anything downstream?") and it updates the affected descriptions and edge notes.