An AI agent task board: what it needs that a normal board does not

An AI agent task board is a board that agents work from directly: they read the next card, do the work, update the card and hand it back. Columns and cards are the easy part. What a normal board lacks is everything that makes an agent safe and useful as a member: an identity for each agent, a role on each board, scopes on its connection, a history that names it, a way to revoke it on its own, context it reads before it starts, cards small enough to finish in one sitting, and a review step before anything counts as done. Miss any of the eight and you end up either watching the agent all day or not trusting what it did.

Why a board built for people falls short

Most task boards quietly rely on the person using them. A person remembers what was said in yesterday’s meeting, notices that a card looks odd, and pauses before moving forty of them at once. The board does not need to carry that judgement, because the user does.

An agent arrives with none of it. It reads the board through tools rather than a screen, starts every session without memory of the last, works at the speed of its tool calls, and treats whatever it is allowed to do as something it may do. That is not a flaw to be prompted away; it is what an agent is. The board has to supply what the person used to: who is acting, what they may touch, what they should know, and where a human looks before work is called finished.

1. An identity for each agent

An agent that signs in with your password is you, as far as the board can tell. Every change looks like yours, and stopping it means signing yourself out. Each agent needs a credential of its own, with a name you chose, so it shows up as itself. One per tool: Claude Code and Cursor working the same board should never share a key. The steps are in how to give an AI agent access to your project board.

2. A role on each board

An identity says who; a role says what. The useful rule is that agents hold the same kind of role people do, from the same list, checked by the same code. A board that has a separate “bot settings” page ends up with two permission models, and the one nobody looks at drifts. How roles, ceilings and refusals work for both is covered in roles and permissions for humans and AI agents.

3. Scopes on the connection

A role belongs to a member; a scope belongs to one connection. They answer different questions. The role says what this person or agent may do on the board at all; the scopes say how much of that this particular token carries. On fenbs a token acts as the person who approved it and is narrowed by three scopes: read, write and comment. Both gates apply and the narrower wins, so an agent you are still getting to know can hold read and comment for a week while you watch what it would have done.

4. A history that names the agent

When agents work while you are doing something else, the history is how you find out what happened. It has to be written by the board, not by the agent, and it has to say which agent acted for which person. On fenbs that reads as “Claude via” the person who approved it, beside the card, the change and the time. Why that matters, and what a good record contains, is in an audit trail for AI agents.

5. Revocation that leaves everyone else alone

You will take an agent’s access away one day: you change tools, a laptop goes missing, or it did something you did not like. Revoking one agent should stop that agent at once and touch nothing else, not your sign-in, not your colleagues, not the other agents. And the record of what it did should stay. On fenbs revoking a token stops it immediately, leaves the person who issued it signed in, and keeps its changes in History under its name.

6. Context the agent reads before it starts

A new colleague gets an induction. An agent gets whatever is in front of it when the session starts, which is usually nothing. A board for agents keeps the standing information with the work: what you are making, how you write tasks, what must never be touched, where things live.

fenbs calls this AI context: short notes on the board, for everything or for one project. An agent connected over MCP↗ (opens in a new tab) calls fenbs_get_context before it works and gets exactly the notes for the project in hand. When it learns something worth keeping it can add a note with fenbs_add_context_note, signed with its name, so the next agent, or the next session of the same one, starts where it left off. Because the notes live on the board rather than inside one assistant, changing from Claude to Cursor loses nothing.

7. Cards an agent can finish

A person can hold a vague card like “improve onboarding” in their head for a month and chip at it. An agent cannot: it will either do something arbitrary or do nothing. Cards on an agent board should be small enough to finish in one sitting and clear about what finished means.

• One outcome per card. “Sign-in button does nothing on Safari” is a card; “fix Safari” is a project.
• Say where. A file and line, a screen, a URL. The agent will find it faster, and so will you when you review.
• Say what done looks like. One line: “the test in checkout.spec passes”, “the export opens in Excel”.
• Keep the problem and the plan apart. On fenbs every task has a Problem box, written once, and a Plan box, rewritten as the work is understood. An agent that writes its plan before moving a card to In Progress gives you something to check before it has changed a line.

Refs matter more than they look. An agent that quotes BUG-031 in a commit message ties the code to the card, and on fenbs a number is never reused, so the link still holds a year later.

8. A review step before Completed

The last column on a board is a claim: this is done. When an agent can move cards there unchecked, the claim is only as good as the agent’s confidence, which is always high. An agent board needs a point where a person looks before work counts as finished.

Many tools add a “Review” column for this. fenbs does not: its four lanes, To Do, Next Up, In Progress and Completed, are fixed. Review is a rule about who moves the card, not an extra lane. Two ways to set it up:

• By convention. The agent finishes, comments what changed and how it was checked, and leaves the card in In Progress. A person reads the comment and moves it to Completed. Put the rule in the agent’s rules file.
• By permission. Connect the agent with read and comment only. It cannot move anything, so every move to Completed is a person’s, and the history shows it.

## The board
- Start: fenbs_whoami, then fenbs_get_context for this project.
- Take the top task in Next Up. Write its plan, then move it to In Progress.
- Finish: comment what changed, the commit, and how you checked it.
- Leave it in In Progress for review. Never move a task to Completed.
- Anything you notice but do not fix: file it in To Do.

A checklist for any board you are considering

1. Can each agent have its own named credential, separate from yours?
2. Does an agent hold a role from the same list as people, enforced on the server?
3. Can one connection be narrowed further than its owner’s role, for example to read only?
4. Does the history say which agent made each change, and for whom?
5. Can you revoke one agent without signing out, and does its history survive?
6. Is there somewhere the agent reads standing instructions before it starts, which travels if you change assistant?
7. Do cards have room for the problem, the plan and the evidence, kept apart?
8. Can you make sure a person, not the agent, decides that work is finished?

A board that answers yes to all eight lets you hand an agent real work and read the result in minutes. A board that answers yes to the first two and no to the rest gives the agent a login and leaves you to supervise it.