Can an AI agent approve its own work in Flux?

Flux does not stop it. An agent with a Write key can move a card to any column on the board, including Done. Keep approval with people by writing "never move a card to Done" into the agent's instructions, giving agents that only report a Read-only key, and checking the Done column for cards that skipped review.

Do AI agents need a paid seat?

No. Agents that connect through the REST API or the MCP server use a member's API key and never take a seat, on any plan. Pro and Expert are billed per workspace member. Board guests are not workspace members, so they are not billed either.

How can a client approve work on a board?

Invite the client to that one board as a board guest with the member role. Member guests can comment on and move cards on that board only, and they are not billed. A viewer guest can see the board but cannot comment or move cards, so they cannot sign off on the board itself.

Can I get notified when an agent sends a card to review?

The Slack extension posts board events such as card moved and new comments to a Slack channel. It covers changes made in the app and through the REST API. Changes made over MCP do not post to Slack, so check the Needs review column directly.

Does Flux pause or run my agents?

No. Flux, task management for AI agent teams, is the board your agents connect to. You keep running Claude Code, Cursor, Codex or your own scripts. The agent stops when its instructions tell it to, and the card holds the state, so the next session or a person picks up where it left off.

Human-in-the-Loop for AI Agents on a Kanban Board

How do you keep a human in the loop when AI agents work your task board?

Make the board the checkpoint. Agents create, update and move cards as far as a Needs review column. A person reads the card, the agent's comments and any linked pull request, then moves it to Done or sends it back. In Flux, Read-only API keys and workspace roles back that rule up.

This works with any agent that reaches Flux over the Flux MCP server or the REST API. Flux does not run your agents. It is the board they and your team share, so review happens where the work is already tracked.

What does human-in-the-loop mean for AI agents?

Human-in-the-loop (HITL) is a way of designing agent work so that the agent stops at agreed checkpoints. A person then signs off, fixes or redirects the work before anything risky happens. Atlassian's guide to human-in-the-loop patterns for AI agents frames it as three patterns:

Approval: sign-off before a high-risk or irreversible action.
Review: checking the agent's output before it ships.
Escalation: the agent hands off when it is unsure, missing context or out of bounds.

Cloudflare's Agents docs on human-in-the-loop patterns list why teams add it: compliance, safety for payments, deletions and external messages, quality and trust. Addy Osmani's agentic engineering glossary counts code review as human-in-the-loop too.

What is the difference between human-in-the-loop and human-on-the-loop?

In the loop, the agent waits for a person before the work goes ahead. On the loop, the agent acts on its own while a person monitors and steps in to correct it. The EU's High-Level Expert Group on AI ties human-on-the-loop to the system's design and to monitoring its operation, not every decision. It uses human-in-the-loop in a stricter sense than the checkpoint pattern above: a person in every decision cycle.

Mode	Who acts	When the person steps in	On a Flux board
Human-in-the-loop	The agent proposes, then waits	Before the work counts as done	The agent stops at Needs review; a person moves the card to Done
Human-on-the-loop	The agent acts on its own	While it runs, to stop or correct it	The agent moves its own cards to Done; a person watches the board and reopens mistakes
Human-out-of-the-loop	The agent acts on its own	After the fact, through audits and spot checks	Rarely a fit for agent work that reaches customers or production

Sources: the HLEG's Ethics Guidelines for Trustworthy AI (2019, "Human oversight", printed page 16 of the PDF), which notes that intervening in every decision "in many cases is neither possible nor desirable", and Atlassian's guide above. Most teams mix modes: in the loop for work that ships, on the loop for low-risk chores. Watching from the loop is harder over MCP, because MCP changes don't appear in the activity log.

Where should you put human checkpoints in agent work?

Put a checkpoint wherever a mistake is expensive or the agent lacks context. Four places cover most agent work: before the agent starts, when it is unsure, before Done, and before anything you can't undo. On a board, each one becomes a column or a rule about who may move cards out of it.

Before the agent starts. A person moves a card into Ready for agent once the task and its acceptance criteria are clear. Agents pick up only from that column.
When the agent is unsure. The agent comments its question on the card, moves it to Needs input and stops. A person answers in a comment and moves it back.
Before Done. The agent moves finished work to Needs review with a comment saying what it changed and how to check it.
Before anything you can't undo. Deploys, deleting data, spending money or messaging a client wait for a person's go-ahead on the card. This is the approval pattern.

Clear criteria speed up the first and third checkpoints. See how to write acceptance criteria for AI agents.

How do you set up a review gate on a Flux board?

Add a Needs review column, give each agent its own API key, tell agents in their instructions to stop at Needs review, connect them over MCP, and have a person move reviewed cards to Done. All six steps below work on the Free plan, using the board Flux creates when you sign up.

Set up the columns. New accounts get a Project Board with Backlog, Planning, In Progress, Review and Complete. Rename Planning to Ready for agent, Review to Needs review and Complete to Done, then add a Needs input column. On a paid plan, a new blank board starts with To Do, In Progress and Done, and Done is already marked as its Done column.
Create one API key per agent. In Settings, open API Keys. Keys always include the Read scope, for viewing boards and cards. Tick Write, for creating, updating and deleting, only for agents that do the work. Name the key after the agent and set an expiry date if the agent is temporary.
Write the rules into the agent's instructions. Use the file your agent reads at the start of every session, such as CLAUDE.md for Claude Code (it reads AGENTS.md only when no CLAUDE.md exists, so import one from the other if you keep both) or AGENTS.md, which many coding agents read.
Connect the agent over MCP. Add the server URL and the key to your client, as shown in the Flux MCP server setup.
Review the card. Open it, read the agent's comments and any linked pull request, then move it to Done or back to Ready for agent with a comment that says what to change. The get_card tool returns every comment, so the agent's next session reads your feedback.
Check Done once a day. Instructions are guidance, not locks. A card in Done that no person reviewed means the rules need tightening.

An example of step 3, to adapt to your column names:

## Flux board rules (example)
- Only take cards from "Ready for agent". Move a card to "In Progress" before you start.
- Start every comment with your agent name, for example "[backend-agent]".
- If you are unsure or blocked, comment your question, move the card to "Needs input" and stop.
- Never deploy, delete data or contact a client until a person approves it on the card.
- When you finish, comment what you changed, how to check it and the PR link,
  then move the card to "Needs review". Never move a card to "Done".

Anthropic's Claude Code memory docs say Claude treats these files as context, not enforced configuration. To make the client itself ask you first, Claude Code supports ask rules, which prompt for confirmation whenever Claude Code tries to use a tool. With the server named flux, this in .claude/settings.json makes Claude Code ask before every card move, through either of the two tools that move cards (if you registered the server under another name, use that name in the rule):

{
  "permissions": {
    "ask": ["mcp__flux__move_card", "mcp__flux__reorder_cards"]
  }
}

It prompts on every move, not only moves to Done, because rules in settings files can't match an MCP tool's parameters. create_card can still put a new card straight into any column. In dontAsk mode Claude Code denies those calls instead of asking. Other clients have their own approval settings.

Who can do what on a review board?

People get access through a workspace role (owner, admin, member or viewer) or as a guest on a single board. Agents get access through API keys, which act as the person who created them, so an agent never has more access than that person. Reviewers need the member role or higher, as a workspace member or a board guest.

Who	Sees	Can create, move and comment	Billed on Pro and Expert
Owner or admin	Every board in the workspace	Yes, and can invite or remove members	Yes
Member	Every board in the workspace	Yes	Yes
Viewer	Every board in the workspace	No: viewers can't comment, move cards or undo	Yes
Board guest	One board	Member and admin guests yes, viewer guests no	No
Agent with a Read key	What its key's creator sees	No	No
Agent with a Read and Write key	What its key's creator sees	Yes, if its key's creator can	No

Over MCP, read tools need the key's creator to hold any workspace role, and changes need the Write scope plus the member role or higher. Keys can't reach a board over MCP through board-guest access, so create agent keys from a workspace member account. More on roles: workspaces and roles.

What does Flux not enforce?

Flux does not lock columns or block card moves. The review gate is a rule your agents follow and your team checks, not a permission. Know these gaps before you rely on the board for sign-off. This is what is missing:

No column permissions. An agent with a Write key can move a card to Done. The review step lives in its instructions.
No approve button. Approval is a person moving the card and, if you like, a comment saying "approved".
No WIP limits on columns, so nothing caps how many cards wait in Needs review.
Automation is narrow. On Pro and Expert, a rule can assign members when a card is created in a column. No rule fires when a card is moved to Needs review.
MCP changes are not in the activity log. Changes made in the app and through the REST API are recorded in the activity log. MCP changes do not appear there or in Slack.
Agents act under a person's name. Comments an agent posts appear under the name of its key's creator, and cards it creates record that person as creator.

The workarounds: one key per agent, signed comments, Read-only keys for agents that only report, a daily look at Done, and a separate board for agent work if clients share yours. For several agents, see how to coordinate multiple AI coding agents. For the wider layout, see the kanban board for AI agents.

Human-in-the-loop for AI agents.