How to Use AI Agents in Project Management, Step by Step

To use AI agents in project management, start small and make the board the place they work. Pick three or four jobs agents are good at, connect one assistant with less access than you have, write cards it can finish in one sitting, decide who approves finished work, and run it for two weeks. Measure cycle time and rework before and after. Widen it only if both numbers hold. The rest of this post is that plan in order, with the decisions a team lead actually has to make at each step.

If you want the definition first, what is AI project management covers what changes when an assistant becomes a member of the board. This post assumes you have decided to try it and want to know how.

Step 1: pick the jobs agents do well

Do not start with “let the agent run the project”. Start with a short list of jobs where the output is easy to check and a wrong answer is cheap. Four fit most teams:

• Triage. Reading new cards, spotting duplicates, suggesting a kind (feature, enhancement or bug) and a priority, and asking for the detail a report is missing.
• Drafting. First versions of a plan on a card, acceptance checks, release notes, a reply to a client question. A person edits; the agent saves the blank page.
• Status summaries. “What moved this week, what is stuck in In Progress, what is waiting on a person.” The agent reads the board and its history rather than asking five people.
• Small fixes. A failing test, a typo in copy, a broken link, a one-file bug with clear repro steps. Work that fits one session and one check.

Leave out, for now: anything that needs a decision only you can make (scope, pricing, what to cut), anything hard to undo (deleting data, sending email to customers), and large cards that span several days. Those can come later, if at all.

Step 2: connect one assistant, with limited scope

One assistant, one board, one person responsible for it. If three people each connect a different tool in week one, you will not be able to tell which setup caused which result.

Give it less than you have. On fenbs an assistant connects over MCP↗ (opens in a new tab) with a browser sign-in, and you tick its scopes on the approval screen: read the board is always on, and adding and changing tasks, and commenting, are yours to choose. For the first days, read and comment is enough: the assistant can triage and report, and a person makes the moves. The connection acts as you and can never do more than your own role allows, and you can revoke it in Settings without touching your own sign-in. How to give an AI agent access to your project board walks through the approval screen and the choice of scopes.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp
# then run /mcp inside Claude Code, choose fenbs, sign in, tick read + comment

Then write down, once, what the assistant should know before it touches anything: how you name things, what never to change, where the staging data lives. On fenbs that is AI context, which every connected assistant reads with fenbs_get_context before it starts. Five true notes beat fifty stale ones.

Step 3: write cards an agent can finish

An agent works from what is written on the card, not from the corridor conversation behind it. The single biggest lever a team lead has is the quality of the cards going into Next Up. A kanban board for Claude Code goes through what a finishable card looks like in detail; the short version is:

• One outcome per card, small enough for one session.
• The problem written separately from the plan: what is wrong, why it matters, where (file and line, or the screen).
• A check that says it is done: the test that should pass, the page that should load, the number that should match.
• Anything it must not touch, stated on the card or in AI context.

A useful test: could a new starter pick this card up on their first morning without asking you anything? If not, an agent will either ask, guess, or come back half-done, and half-done is the most expensive state to review.

Step 4: set the review rule before the first card moves

Decide who may move a card to Completed, and write it down where the assistant will read it. The simplest rule for a pilot: the assistant moves a card to In Progress when it starts and comments when it stops, and a person moves it to Completed after checking the evidence. Human in the loop for AI agents covers where else a person should step in.

Review rule for assistants on this board:
- Comment before you start: what you intend to do.
- Comment when you stop: what changed, the commit or file, and how you checked it.
- Fill in Testing: what you ran and the result, or say plainly that it was not tested.
- Never move a card to Completed. A person does that after reading your comment.

Once the assistant has earned it, you can relax the last line for certain kinds of work, for example “small bug fixes may go to Completed when the named test passes”. Relax it on purpose, in writing, not by drift.

Step 5: run a two-week pilot

Two weeks is long enough to get past the novelty and short enough that nobody is committed to the result. Set it up like any other experiment:

1. Before you start, note the last two weeks’ numbers for the same board (step 6 says which).
2. Choose 10 to 20 cards of the kinds from step 1 and put them in Next Up. Keep them real; a pilot on invented work proves nothing.
3. Name one person as the reviewer for the fortnight, and give them time for it. Review is where agent work queues.
4. Hold a ten-minute check at the end of week one: what came back right, what came back wrong, which cards were unclear. Fix the cards and the AI context, not the assistant.
5. At the end of week two, compare the numbers and decide: stop, repeat, or widen.

During the pilot, read the board’s History rather than the assistant’s transcripts. Every change on fenbs is recorded with who made it, and an assistant’s changes show as “Claude via” the person who connected it, so a week of its work is a list you can read in minutes.

Step 6: measure cycle time and rework

Two numbers tell you most of what you need, and both come straight off the board.

• Cycle time: from the moment a card enters In Progress to the moment it reaches Completed. Look at where the time goes, not only the total: an agent may finish in minutes and the card still wait a day for review. Kanban for AI agents explains how to read that.
• Rework: cards that came back. Count the ones moved out of Completed, reopened, or followed by a new bug linked to them within the fortnight. A fast agent with high rework is slower than it looks.

Add one qualitative check: ask the reviewer how long review took and whether the comments were enough to judge the work without opening the code. If review is the bottleneck, the fix is usually better evidence on each card, not more agents.

Be honest about the comparison. Two weeks and a handful of cards is a small sample; treat the result as a direction, not a proof.

Step 7: expand one thing at a time

If cycle time fell and rework did not rise, widen the pilot, but change one variable per round:

• More kinds of work (from small fixes to small features), or
• More access (add the scope to add and change tasks, so the assistant can file what it notices and write plans itself), or
• More assistants (a second tool, or a second person’s assistant on the same board), or
• A looser review rule for one kind of card.

If the numbers got worse, look at the cards before you blame the assistant. Unclear cards, missing context and an overloaded reviewer explain most bad pilots. And if a connection is ever doing something you did not expect, revoke it first and investigate second; how to audit AI agents is the routine for the regular check.