Skip to content
Best Practices
Updated 15 min readVuong Ngo

MCP Project Management: Work Units for AI Coding Agents

AI coding agents do not need a longer chat transcript to finish multi-task features. They need a durable work unit that keeps scope, tasks, acceptance criteria, artifacts, decisions, and locks outside the model context window and available through scoped MCP access.

MCP Project Management: Work Units for AI Coding Agents

AI coding agents are good at finishing a clear task. They are much worse at staying aligned when one feature stretches across several tasks, sessions, branches, or people.

The fix is not a larger chat transcript. For multi-task AI coding work, the useful coordination layer is a work unit: a durable feature-level record between a project and a task. It keeps the goal, task sequence, acceptance criteria, decisions, artifacts, comments, and workflow locks outside the model context window. With MCP project management, an external assistant can read and update that record through approved scope while Agiflow remains the board and state layer, not the agent runtime. [1] [2] [7]

That distinction matters. If the only source of truth is a chat, every new session starts with archaeology: what did we decide, which tasks are done, what files changed, which acceptance criteria still matter, and who owns the next move?

What Is A Work Unit In AI Project Management?

A work unit is the feature-level container that groups related tasks into one deliverable. In Agiflow terms, the hierarchy is simple:

LayerWhat it answersExample
ProjectWhat larger product or workspace does this belong to?E-commerce platform
Work unitWhat feature or initiative are we trying to complete?Shopping cart checkout
TaskWhat concrete piece of work is ready to run or review?Add cart API endpoint
The work unit is where feature coherence lives. It should hold the goal, non-goals, task order, shared constraints, acceptance criteria summary, decision notes, expected artifacts, owners, status, and lock scope. Individual tasks can stay smaller: one implementation step, one review step, one test step, one docs step. Diagram of a project containing a work unit, tasks, acceptance criteria, artifacts, comments, and workflow locks.

Diagram of a project containing a work unit, tasks, acceptance criteria, artifacts, comments, and workflow locks.

Do not turn the work unit into a junk drawer. Full code dumps, every chat turn, secrets, and vague wishes do not belong there. Secrets should live in scoped vault entries when needed. Evidence should live as artifacts. Discussion should live as comments. The work unit should give the next human or assistant enough state to resume the feature without guessing. [7]

Why Chat History And Repo Memory Are Not Enough

Chat history feels like memory until you need the same feature to survive a context reset, a tool switch, or another teammate. Repo files help, especially CLAUDE.md, ADRs, specs, and local task notes. They are still weak as the shared operational record for feature delivery.

There are two reasons.

First, context is finite and needs curation. Anthropic's context engineering guidance describes long-horizon agent work as a coherence problem across sequences that can exceed a model's context window. [3] The Lost in the Middle paper also gives a conservative warning: long context does not guarantee that a model reliably uses the relevant detail, especially when that detail sits in the middle of a long prompt. [4]

Second, files are usually passive. A repo note can say "implement checkout after cart API," but it does not naturally track live status, task ownership, review state, artifacts, comments, or locks. A local memory file also does not solve team visibility. If you have felt the pain described in why AI coding agents lose context, the missing piece is usually not another reminder in the prompt. It is a durable system of record the assistant can actually use.

Use repo memory for durable engineering knowledge. Use a work unit for live feature coordination.

What State Belongs In The Work Unit Versus The Task?

The clean split is this: put cross-task state in the work unit, and put executable detail in the task.

StateBest homeWhy
Feature goal and non-goalsWork unitEvery task needs the same boundary.
Task sequence and dependenciesWork unitThe assistant needs to know what should happen before what.
Task-level implementation detailTaskKeeps the active job focused.
Acceptance criteria summaryWork unitDefines what "done" means for the feature.
Task-level criteria and test notesTaskLets review happen at the smallest useful unit.
Decisions that affect several tasksWork unit commentsKeeps later sessions from re-litigating the same call.
Screenshots, logs, generated files, reportsArtifactsEvidence should survive the session and stay attached to the work.
Environment values or credentialsVault entriesSecrets should not be pasted into prompts or prose.
Concurrent execution boundariesWorkflow locksPrevents two sessions from writing over the same scoped work.
This is where a work unit earns its keep. It is not another label for an epic. It is the record that tells the next assistant, "Here is the feature, here is what has already happened, here is what you may touch, and here is what proof you owe before this can close."

That also makes review less theatrical. Instead of reading a confident summary and hoping it matches reality, the reviewer can inspect the task, the acceptance criteria, the artifacts, and the comments that led there.

MCP Project Management: How A Work Unit Becomes Assistant-Readable Project State

MCP is the connection layer. Anthropic introduced the Model Context Protocol as an open standard for connecting AI assistants to the systems where data lives, and the MCP docs describe it as a way for AI applications to connect to external systems, tools, data sources, and workflows. [1] [2]

For project management, that means the assistant does not need a human to copy board state into the prompt. With approved scope, it can ask the board for the relevant project, work unit, task, comment, artifact, vault entry, or workflow lock. As of July 2026, the MCP documentation names broad client support, including Claude, ChatGPT, VS Code, and Cursor. [2]

Agiflow's boundary is deliberately narrower than an agent platform. Agiflow is a commercial project board for external assistants. You keep using ChatGPT, Claude, Cursor, Codex, or another compatible client. Agiflow supplies the scoped tools, shared state, artifacts, vault entries, prompt skills, and workflow coordination those assistants can use after approval. [7]

If you are evaluating the category, the deeper question is not "does this tool have an MCP server?" It is whether the MCP surface has the write access, scope controls, and artifact model needed for real work. The checklist in MCP integration table stakes is a useful companion read.

A Practical Work-Unit Workflow For A Multi-Task Feature

Take a shopping cart feature. The feature might need a database migration, repository layer, API endpoints, frontend hooks, cart UI, integration tests, end-to-end tests, and docs. Those tasks are individually suitable for an AI coding assistant. The risk is coordination.

A work-unit workflow keeps the feature state explicit:

  1. Create a work unit with the goal, non-goals, dependencies, and acceptance criteria.
  2. Break the work into tasks small enough to run and review.
  3. Attach the task order and any cross-task decisions to the work unit.
  4. Give the assistant scoped access to the work unit or task.
  5. For each task, update status, run the implementation, attach artifacts, and record test evidence.
  6. Use comments for handoff notes when the work changes session, person, or assistant.
  7. Use workflow locks when two sessions might touch the same feature, files, environment, or deployment path.
  8. Close the work unit only when the feature-level acceptance criteria and task-level evidence agree.

OpenAI's Agents SDK documents handoffs as a way for one agent to delegate to a specialist agent with optional structured metadata. [6] That is a useful design analogy even when you are not using the SDK. The point is that delegation needs a transfer record. Multi-agent systems also fail in predictable ways when system design, inter-agent alignment, or task verification is weak. The MAST failure taxonomy is a good reminder that "more agents" is not a coordination strategy. [5]

In practice, the handoff note can be boring:

markdown
Task completed: cart API endpoints
Files changed: apps/api/src/routes/cart.ts, apps/api/src/services/cart.ts
Acceptance criteria met: add item, update quantity, remove item, empty cart
Artifacts: integration-test-output.txt, OpenAPI diff
Next task: frontend hooks
Risk: checkout endpoint still depends on payment provider stub

Boring is good. Boring can be checked.

When A Simple Task List Is Enough

You do not need a work unit for everything. A simple task is enough when one person or assistant can finish the work in one session, there are no meaningful cross-package dependencies, no handoff is expected, and the proof is obvious from the diff and tests.

Use a work unit when any of these are true:

SignalWhy a work unit helps
The feature spans multiple tasksThe assistant needs a feature-level goal and sequence.
The work crosses sessionsDecisions and progress need to survive context resets.
More than one person or assistant is involvedHandoffs need an explicit record.
The feature changes shared files or environmentsLocks reduce collisions and stale assumptions.
Review needs evidenceArtifacts keep logs, screenshots, and generated outputs attached.
Acceptance criteria are feature-levelA single task status cannot prove the whole deliverable.
This is also the line where local task state starts to strain. Claude Code Tasks limitations covers that narrower case. For larger team memory, spec-driven development tools and AI project memory are better frames.

What To Measure Instead Of Claiming Magic Speedups

The wrong way to sell a coordination layer is to promise a universal percentage improvement. Multi-task AI work varies too much by team, codebase, review discipline, and tool setup.

Measure the operational friction instead:

MetricWhat it tells you
Sessions per featureWhether feature work is fragmenting.
Context reload timeHow much time is spent reconstructing state.
Tasks reopenedWhether acceptance criteria were clear enough.
Review roundsWhether handoffs and artifacts were useful.
Criteria missedWhether task completion matched feature completion.
Artifacts attachedWhether claims have evidence.
Lock conflictsWhether concurrent agents are stepping on the same scope.
Lead timeWhether the whole feature moved faster, not just the first diff.
If first-party benchmark data exists, publish the method with the number. Until then, treat the work unit as an operating model, not a magic speed claim.

How To Structure Work Units In Agiflow

In Agiflow, the product boundary is straightforward: the board is the shared state layer, and the external assistant is still the agent. The public documentation describes scoped assistant connections at organization, project, work unit, and task levels. It also lists tool families for projects, work units, tasks, task comments, members, artifacts, vault entries, and workflow locks. [7]

A practical Agiflow work-unit template looks like this:

markdown
Goal:
Non-goals:
User or technical outcome:
Task sequence:
Feature-level acceptance criteria:
Dependencies:
Known decisions:
Expected artifacts:
Vault entries needed:
Lock scope:
Handoff notes:
Verification checklist:

Keep it short enough that an assistant can use it. The work unit is not a spec dump. It is the durable coordination record that points to the right tasks, artifacts, and comments.

For setup details, start with connecting AI tools, then use project workflows and project organization to decide how much hierarchy your team actually needs. If you are scaling execution across machines, the Agiflow CLI guide goes deeper on artifacts, locks, and runner coordination.

FAQ

What is a work unit in AI project management?

A work unit is a feature-level record between a project and an individual task. It groups the goal, task sequence, acceptance criteria, artifacts, decisions, comments, and workflow locks for a multi-task deliverable.

How is a work unit different from a task?

A task is the smallest useful work item to run or review. A work unit coordinates several related tasks so the feature remains coherent across sessions, assistants, and reviewers.

Why is MCP useful for project management?

MCP gives an AI application a standard way to connect to external tools, data sources, and workflows. For project management, that means an approved assistant can read and update scoped project state instead of relying on pasted context. [1] [2]

Does Agiflow run the AI coding agent?

No. Agiflow is the project board and state layer. The assistant remains external, such as ChatGPT, Claude, Cursor, Codex, or another compatible client. [7]

When should a team use workflow locks?

Use workflow locks when two sessions, agents, or workflows might touch the same feature, files, environment, or release path. A lock is not bureaucracy. It is a visible boundary around shared work.

Should you replace repo docs with a board?

No. Keep repo docs for durable engineering knowledge and decisions that belong with the code. Use the board for live project state: ownership, status, acceptance criteria, handoffs, artifacts, and locks.

Durable State Beats Bigger Prompts

In MCP project management, the goal is not more ceremony or more agents. It is less re-explaining.

When a feature spans several tasks, the assistant needs the same thing the team needs: a stable record of scope, order, decisions, evidence, and ownership. A work unit gives that record a home. MCP makes it reachable by the assistant. Artifacts and locks make the work reviewable instead of merely plausible.

Before your next multi-task feature, use the work-unit checklist: goal, non-goals, task sequence, acceptance criteria, decisions, artifacts, vault needs, lock scope, handoff notes, and verification checklist. If any of those are missing, the next session will probably pay for it.

References

  1. Anthropic, Introducing the Model Context Protocol. Captured 2026-07-04.
  2. Model Context Protocol docs, Introduction. Captured 2026-07-04.
  3. Anthropic Engineering, Effective context engineering for AI agents . Captured 2026-07-04.
  4. Liu et al., Lost in the Middle: How Language Models Use Long Contexts . Captured 2026-07-04.
  5. Cemri et al., Why Do Multi-Agent LLM Systems Fail?. Captured 2026-07-04.
  6. OpenAI Agents SDK, Handoffs. Captured 2026-07-04.
  7. Agiflow, llms.txt documentation index. Captured 2026-07-04.

Put this project board inside ChatGPT

Open Agiflow in ChatGPT to plan campaigns, create tasks, and check what needs attention. Create a free Agiflow account when you are ready to keep the board for your team.