The problem with agents that live in chats
If you use a coding or ops agent every day, you already know the pattern. You ask for something, it works for a while, and then you either wait on it or it waits on you. Status lives in a conversation nobody else can read. When you close the window, the context is gone. When the agent is blocked, it either guesses or interrupts you.
Teams solve this for people with a board: one place where every piece of work, its owner and its state are visible. Agents need the same thing. The difference is that an agent has to be able to read and write that board itself.
What MCP is, in one paragraph
The Model Context Protocol (MCP) is an open standard that lets an AI client such as Claude Code, Claude Desktop or Cursor call tools exposed by another program. Instead of pasting data into a chat, you give the agent a small set of tools. For a Kanban board those tools are things like list the jobs, create a job, move it to Review and post a progress note. Several project tools now publish an MCP server; the questions that matter are what the tools can do and how safely.
What a good agent workflow looks like
- Read the board. The agent lists stages and jobs, so it knows what exists and what state it is in.
- Claim a job. A claim carries a lease (for example 30 minutes). Other agents skip a job that is claimed, and if the agent crashes the lease expires, so the job is never locked forever.
- Work and report. While it works, the agent posts short progress notes and attaches evidence such as a link to the change. Humans read the timeline instead of asking.
- Ask when blocked. If a decision is needed, the agent opens a structured request with two to six options and waits. Someone on the team answers once, the answer is recorded, and the agent continues.
- Move the job. When it is done the agent moves the card to the next stage, with a one-line reason the team sees in the job history.
The point of step 4 is to replace the interruption ("what should I do about X?" in a DM) with something that keeps state: the question, the options, who answered and when.
Connect an agent to QodFlow
QodFlow ships an MCP server, qodflow-mcp, and it is included in the Free plan. In short: create a token in Settings → API Keys, give it only the scopes it needs, and register the server with your client. For Claude Code that is a single command plus the token in the environment:
claude mcp add qodflow -- npx qodflow-mcp
export QODFLOW_API_TOKEN=qf_live_…Cursor and other clients use a small JSON config. The full steps and the list of tools are in the MCP guide, and the source is on GitHub under the MIT license.
Keep it safe
- Scoped tokens. A token can be limited, for example to reading and writing jobs but not assigning them. Give each agent its own token.
- Revocable. Revoke a token and the agent loses access immediately; nothing else on the board changes.
- Audit trail. Every action done with a token is logged, so you can see what an agent did and when.
- Untrusted text stays untrusted. Notes and descriptions written by people or other agents come back marked as untrusted, so a client can treat them as data and not as instructions.
- No destructive tools. The server does not expose actions such as deleting a team.
When it is worth doing
A shared board pays off as soon as more than one thing is in flight: two agents, or one agent and a person who needs to know where it is. If you only run a single agent on a single task, a chat is fine. The moment you want to hand a job over, review the work later or run agents in parallel, you want a board with a history.
If you are new to the board part, start with how to organize work with Kanban. Then create a free workspace, make a token and let an agent claim its first job.