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.

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:
| Layer | What it answers | Example |
|---|---|---|
| Project | What larger product or workspace does this belong to? | E-commerce platform |
| Work unit | What feature or initiative are we trying to complete? | Shopping cart checkout |
| Task | What concrete piece of work is ready to run or review? | Add cart API endpoint |
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.
| State | Best home | Why |
|---|---|---|
| Feature goal and non-goals | Work unit | Every task needs the same boundary. |
| Task sequence and dependencies | Work unit | The assistant needs to know what should happen before what. |
| Task-level implementation detail | Task | Keeps the active job focused. |
| Acceptance criteria summary | Work unit | Defines what "done" means for the feature. |
| Task-level criteria and test notes | Task | Lets review happen at the smallest useful unit. |
| Decisions that affect several tasks | Work unit comments | Keeps later sessions from re-litigating the same call. |
| Screenshots, logs, generated files, reports | Artifacts | Evidence should survive the session and stay attached to the work. |
| Environment values or credentials | Vault entries | Secrets should not be pasted into prompts or prose. |
| Concurrent execution boundaries | Workflow locks | Prevents two sessions from writing over the same scoped work. |
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:
- Create a work unit with the goal, non-goals, dependencies, and acceptance criteria.
- Break the work into tasks small enough to run and review.
- Attach the task order and any cross-task decisions to the work unit.
- Give the assistant scoped access to the work unit or task.
- For each task, update status, run the implementation, attach artifacts, and record test evidence.
- Use comments for handoff notes when the work changes session, person, or assistant.
- Use workflow locks when two sessions might touch the same feature, files, environment, or deployment path.
- 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:
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 stubBoring 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:
| Signal | Why a work unit helps |
|---|---|
| The feature spans multiple tasks | The assistant needs a feature-level goal and sequence. |
| The work crosses sessions | Decisions and progress need to survive context resets. |
| More than one person or assistant is involved | Handoffs need an explicit record. |
| The feature changes shared files or environments | Locks reduce collisions and stale assumptions. |
| Review needs evidence | Artifacts keep logs, screenshots, and generated outputs attached. |
| Acceptance criteria are feature-level | A single task status cannot prove the whole deliverable. |
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:
| Metric | What it tells you |
|---|---|
| Sessions per feature | Whether feature work is fragmenting. |
| Context reload time | How much time is spent reconstructing state. |
| Tasks reopened | Whether acceptance criteria were clear enough. |
| Review rounds | Whether handoffs and artifacts were useful. |
| Criteria missed | Whether task completion matched feature completion. |
| Artifacts attached | Whether claims have evidence. |
| Lock conflicts | Whether concurrent agents are stepping on the same scope. |
| Lead time | Whether the whole feature moved faster, not just the first diff. |
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:
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.
Related Resources
- MCP Project Management Is Real. Nobody Owns It Yet.
- Why AI Coding Agents Lose the Plan
- Claude Code Tasks Limitations
- MCP Integration Table Stakes
- Multi-Agent Orchestration with Claude and Codex
- Introducing the Agiflow CLI
References
- Anthropic, Introducing the Model Context Protocol. Captured 2026-07-04.
- Model Context Protocol docs, Introduction. Captured 2026-07-04.
- Anthropic Engineering, Effective context engineering for AI agents . Captured 2026-07-04.
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts . Captured 2026-07-04.
- Cemri et al., Why Do Multi-Agent LLM Systems Fail?. Captured 2026-07-04.
- OpenAI Agents SDK, Handoffs. Captured 2026-07-04.
- Agiflow, llms.txt documentation index. Captured 2026-07-04.
More to read
Claude Code Tasks Limitations: Where Native Tasks Stop for Teams
Claude Code Tasks is useful local orchestration, but it is not a shared system of record. This refreshed guide maps what Tasks stores, how it differs from sessions, memory, and artifacts, and when teams need an MCP-readable project board.
13 min readHow To Run AI Coding Agents Across Machines Without Duplicate Work
More AI coding agents only help when ownership, state, and proof survive outside a single session. This refreshed guide shows how Agiflow uses CLI runners, workflow locks, atomic claims, device identity, and artifacts to coordinate agent work across machines without duplicate branches or lost handoffs.
12 min readHow to Structure Frontend Codebases for AI Coding Agents
AI coding agents generate better frontend code when the codebase gives them reusable components, Storybook states, design tokens, scaffolds, validation gates, and durable task context they can retrieve instead of reinventing.
18 min readPut 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.