Agentic Kanban: the team practice I am developing

A working draft for onboarding developers into the systems I use: shared work, human decisions, focused agents, review, acceptance and learning. The practices below are marked running, piloting or planned. The four-minute version has the core. Version 0.2.0, October 16, 2026. By Hamed Taheri.

I am building this alongside The 20× Developer Playbook, from our own software-development experience. I want more developers on our team to use the systems without inheriting my chat history, and I want other teams to help test and improve the approach. This draft keeps the current contracts and implementation details inspectable while we learn what makes adoption repeatable. A 20× delivery gain remains a goal.

What changed

Agile was built to ration and coordinate scarce developer hours. Sprints, story points and the daily standup all assume that the expensive thing is a person writing code.

On my team, AI agents now do most of the building. Execution became cheap and parallel. The scarce resources moved: human decisions, review and acceptance capacity, context, and budget. When I measured my own pipeline, more than half the runs ended waiting on me, not on an agent. Agentic Kanban organizes a team around those scarce things.

Agentic Kanban is the team layer for agent-built software. Per-task tools already handle how one person and one agent build one change; this handles the team around them: who decides what, what it costs, and what counts as done.

The name says what it is: Kanban's flow (visible work, limited work in progress, measured flow), run by people and their agents. Several tools use "agentic Kanban" for a board that dispatches agents; this is the operating method around such a board, not a board.

It has two layers. People learn a small core: three verbs, four ceremonies, two ways to describe work, four numbers and three setup questions. Agents carry the rest, in the contract and the AI guide. If the core ever grows larger than Scrum's (three accountabilities, five events, three artifacts), it has failed.

Works with the tools you already use

Developers have converged on per-task tools. Agentic Kanban uses them instead of competing with them: their output becomes the brief, and Agentic Kanban adds a budget, the kind of work and the agent's autonomy.

Thoughtworks' Technology Radar (April 2026) lists Spec Kit and OpenSpec in "Assess" and describes two camps: teams that trust ever-better agents with little structure, and teams that want defined workflows. Agentic Kanban takes the second camp's discipline at the team level and keeps each task as light as the first camp wants.

The mapping

Each Agile practice, what replaces it, and why. The Scrum terms follow the Scrum Guide (2020).

Continuous flow comes from Kanban. The Kanban Guide (May 2025) asks teams to control work in progress and track throughput, work item age and cycle time. Agentic Kanban keeps those measures and changes what limits work in progress: not agent count, but how many decisions and reviews people can absorb.

The loop and the roles

The loop is align, prepare, run, review, accept, learn. People decide what is worth doing and what risk is acceptable (align), resolve product choices (prepare), accept results against evidence, and choose what to change (learn). Agents draft briefs, build, investigate and review in between. Delivery to production is recorded separately: accepted and delivered are different facts with different dates.

People: a product owner, the accountable developer, the accepting authority, and an admin. Agents: a personal agent for each developer, a coordinator, workers and reviewers. These are responsibilities, not a requirement to run a permanent agent for each.

Every attempt records four roles: the accountable person, the operator (the session or agent, with its model), the reviewer and the acceptor. That keeps agent work and human work apart in every report.

How much an agent may do alone is set per kind of work: read_only, draft, act_within_limits or needs_approval. Running agents unattended, on a schedule or a queue, is a separate switch that starts off; Running the board unattended describes what it takes.

Where a person's time goes

The agent capacity is already paid for. The investment is made; what decides the return is how a person spends their attention. So the scarce input is not agent hours but the hours a person can spend deciding and checking.

I watched my own weekend from October 17 to 19, 2026, with two or three coordinators running at once. I wrote almost no code. My time went to five activities, over and over:

Two consequences follow. The limit on running work is coordinators per person, one to three, set by how much a person can decide and verify, not by how many agents can run. And the morning brief is built for these activities: decisions first, then what to verify, then what is stuck. How the hours split across the five will be measured in the pilot with the minutes question, not estimated here.

Right-size every change

The most common complaint about agent workflows is overhead: heavy specs and fixed steps for changes that did not need them. Ceremony here matches the change.

The agent proposes the lane; the person can change it. When a quick change turns out bigger, it moves up a lane instead of growing quietly.

Ceremonies

Four ceremonies make up the core. Each gathers its data with a plain query, no model; the agent only narrates and asks. Personal ceremonies happen once per developer per day, not once per session.

Agent chores are scripted, not meetings. Backlog hygiene (backlog_hygiene) releases stale claims, closes interrupted sessions, and queues duplicate candidates and finished epics for the next decision round. A guideline check (guideline_check) looks for contradictions and stale guidance each month.

The personal agent is proactive. It offers to track untracked work with an overlap check and a cost estimate, warns on budget, collisions and context limits, and leads the brief and the wrap. Its limits: a quiet setting for each person; it never reads message bodies without consent; it batches its own proposals into the next decision round instead of asking one by one; and it never claims work, exceeds a cap or changes another person's task without the authority the rules give it.

Work items

Work is described along four dimensions. People choose two of them; the agent records the rest.

Size and risk are optional fields the agent fills; they guide model choice and comparisons, not ceremonies. Priority uses one scale, p0 to p3.

A follow_up is new scope found after earlier work. It never reopens finished scope to hide new work. A decision is not a kind of work: a choice is recorded as a decision, and the task it blocks waits on a person.

States and acceptance

The states are proposed, backlog, in_progress, blocked, in_review, human_review, awaiting_human, done and cancelled.

• proposed: suggested, often by an agent, not yet accepted. Answered in the next decision round.
• human_review is for a pull request that needs a person's decision or merge. awaiting_human is for any other human action, with the exact ask (human_ask), the kind of need (human_need) and what happens after (resume_with).
• done means accepted: the evidence for the kind of work is attached, and the accepting person (or a delegated reviewer, for low-risk kinds) and the revision are recorded. Merged to an integration branch is not, by itself, done: an agent that lands its own change there moves the task to human_review, and a person accepts it.
• Delivered is an event (a deploy or release), not a state.
• Ready is derived, not stored: the task is in backlog, has a checked brief, its blocked_by items are done, nobody holds a live claim, and a person said go. It is checked again when work starts, because a stored ready flag goes stale.

A missing test is not "not applicable" unless a reason is given.

Handoffs

A handoff is never a new task. It moves the same task between hands, in one of four directions.

Creating a "finish X" task for unfinished work is not allowed: it counts the same work twice.

Routines

Recurring ceremonies run as routines.

• A template holds the purpose, cadence, time zone, scope, owner, inputs, required output, autonomy and a cost cap.
• An occurrence is a task of kind routine, created once per template per period. A retry updates the same occurrence. It is done only when its report is attached, or when it is skipped with a reason.
• Reminders appear inside the morning brief ("weekly review due today; draft ready"), never as separate pings.
• Missed occurrences stay visible, so the weekly report shows the health of the ceremonies too.

Running the board unattended

The unattended switch can be turned on for a night. I first tried it from October 17 to 18, 2026: a coordinator ran my backlog while I slept. It then kept running, with me dropping in during the day, until October 19. This is the setup that held and what broke. It is one run of about three days, so it is piloting at most.

The coordinator routes; it never builds. It picks ready work, starts focused headless workers and reviewers, and records what happened. Building in its own session would spend its context and blur who did what.

Decisions follow a written order. First a never list: production and deploys, customer-facing writes, merges into shared branches, secrets, budget increases, data migrations, removing anything whose outside use is unknown, and reversing a decision a person made. Then rules the person approved in advance: when every precondition of a rule holds, the coordinator acts, logs it, and lists it in the morning pack with a box to confirm or undo. Otherwise it records its recommended answer and waits. Each act is tied to the exact revision and checked again just before it happens, because the board moves at night too.

A question never blocks the run. Asking the person through a prompt that waits for an answer stopped everything: one question sat unanswered for three and a half hours, and no lane moved. The coordinator now asks in plain text with its recommended answer, keeps working on everything else, and takes the recommendation if no answer comes and the choice is not on the never list.

Judgement calls get a peer from another model family. For a decision that needs a second opinion, a reviewer from a different model family checks the brief against the code and must copy back the exact revision it read. One such peer disagreed with a "land as is" and was right: it found two reachable bypasses that peers from the coordinator's own family had missed. A disagreement, or no clear verdict, means wait.

Each pull request gets a bounded review loop. A bot review and a deep model review run; fixes go on the task's own branch; tests must pass before a fix is merged in; a review thread is closed only when its fix is verified; after a fixed number of rounds the loop stops and waits for a person. Past the sixth round only blocking findings are fixed, and hardening nobody asked for is never built (section 3 of the playbook has the numbers). Landing in the integration branch moves the task to human_review, never to done. Work a person put on hold is never landed by the coordinator.

Landing is a serial queue. One script lands one pull request at a time: it merges the integration branch in, reruns tests and the build on that exact result, and lands only if both pass. A part stacked on a sibling's branch is retargeted and landed only after its parent merged; otherwise it is skipped, never forced. A failure is logged and the queue moves on. In one evening the queue landed 17 of 22. The other five had small causes it refused to guess at: two merge conflicts, a generated file gone stale, a constant that a landed PR and the next one had both added to the same file (Git saw no conflict; the build did), and the stacked child of that last one. Each fix took minutes, and a second pass landed four of them. The fifth hit a test that fails on the integration branch too whenever cloud credentials are missing; the queue held it for a person rather than land past a red test.

Hold a placeholder until its successor is ready. When a part ships a temporary stand-in that the next part replaces, landing it alone puts the stand-in into the integration branch. Green tests are not enough: hold it and land both together.

Know which gate actually runs. The integration branch had no full CI; only a few path-filtered checks ran on it. The real gate was the local test-and-build run on the merged result. A landing script that waits for CI that never comes either hangs or, worse, gets edited to stop waiting without anyone deciding that.

Plan the person's time, not only the agents'. The permission layer correctly refused landings and release-line work while the agent ran alone. About fifteen minutes with me present cleared that: I approved the batch, the agent did the few steps that needed me, and the queue then ran without me. Put that window in the morning brief or the desk session instead of letting work wait for it.

Scheduling respects dependencies and money. A task starts only when its blocked_by items have landed, and a failure never releases the tasks behind it. A global limit caps parallel runs, and a budget stop sits below the hard cap so running work can finish. Only a person raises either. When the scheduler itself was replaced mid-run, the old one had to stop before the new one started, or both would claim the same work.

Breaking an epic into parts passes a two-tier gate. A reviewer separates structural problems (a missing part, the wrong order, a part too large) from details. Structural problems block; details travel into the acceptance checks of the part they concern. The gate allows at most about ten parts and two revisions, and runs only for tasks a person already approved. Parts that touch sensitive areas are created but held for a person, together with everything that depends on them.

Context has to survive the night. The coordinator keeps a handoff file, gets a short digest of its rules and latest handoff after each compaction, and compacts well before the default limit, so it never loses its rules mid-decision.

What broke, so you can skip it:

• Fix branches cut before a fix to their base kept the old failure. Merge the base in and check again.
• A readiness check saw "not ready" inside "NOT READY: none" and blocked a ready plan. Read a verdict field, not prose.
• A docs-only change with no test files ran the whole suite and timed out. Choose the tests from the change.
• Editing a shell script while it runs changes what the running copy does. Copy it and edit the copy.
• One unrelated failing test is not a red build. Rerun it alone on the change and on its base before blocking.
• A fix brief that asked the worker to merge the base or edit the pull request description stopped the worker: it had no permission for either. The coordinator merges the base before the fix and applies description changes after it.
• "Charge the same rate as X" was read as the wrong rate. Trace what X really does before writing the brief.
• A brief that forbade touching "other files" blocked plumbing the change needed, such as a test's list of copied files. Name the harness files a change may have to touch.

What it shows. Over about three days the guardrails held: 81 pull requests landed in the integration branch (77 during the run, four more the next morning with me present), each checked again on its merged result, and the morning pack let a person check every act. The run cost about $990 in model spend, the coordinator included, about a third of it the coordinator. It also shows where unattended work stalls: the first night landed 23 while I slept, the second landed none because every chain waited on a person or on review rounds that would not converge, and the last 21 landed only after a short window with me present. It does not show that unattended work is cheaper or better than daytime runs; that needs more runs and the four numbers.

Numbers and reports

Data. Every stage (preparation, each attempt, each review and deep review, each fix round) writes a record linked to its task: the attempt number, model and provider, tokens, cost, outcome or verdict, and the exact revision. Costs are computed from tokens with a dated price table, because tool estimates can be wrong. API-equivalent cost and cash are kept apart. Work that could not be priced shows as unknown, never as zero. Spend against a budget adds up every ledger that bills: workers, reviews, planning and second-opinion calls, and the coordinator itself. Leaving one out makes a run look cheaper than it was. Every state change is logged, so time in each state can be computed.

The four in the core are accepted_outcomes, cost_per_accepted_task, decision_wait and first_attempt_acceptance. The flow tools compute the brief and the weekly report from records, with no model.

Delivery lines up with DORA's software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. DORA applies them per application or service, to improve over time rather than to compete.

Comparing models. Models are not assigned at random: sensitive code already goes to the strongest model. So a report compares models only within the same kind and risk, on first-attempt acceptance against cost. A strong claim needs a controlled comparison.

Three views from the same records.

• Developer: what I accepted, what waits on me, what I wait on, my spend against budget, and how my agents did.
• Team lead: each developer's accepted work, reviews, deep reviews, fix rounds, cost and models, plus flow, queues, review capacity, aging work, budget and ceremony health.
• CTO, monthly: cost per accepted task over time, output over time, the model mix and quality after acceptance.

Four safeguards keep the per-developer view fair: agent work counts under the agent, linked to the developer who directed it; comparisons stay within the same kind and risk, never one ranking number; decision waits and blockers sit beside output; and developers see exactly what their manager sees. This follows SPACE (Forsgren and colleagues, 2021): productivity is not one number or activity counts alone, so use a few measures across individual, team and system levels and across dimensions. The weekly pulse covers SPACE's satisfaction dimension.

Adopting it

The admin's first session asks three questions: which repositories and people, how much agents may do alone, and the budget per attempt, task and week. Everything else starts from a default the admin can change later: the source of truth (GitHub, Jira or the memory store), ceremony times and time zone, report visibility, and folders agents must never touch. It reads the existing setup first, then shows a plan to approve: what changes, what it costs, how it is checked and how to remove it. Then it installs the records and guidelines, invites developers, and runs a read, write and read-back check plus a dry-run brief.

A developer accepts the invite, receives a personal key through a secure flow (never pasted into a chat), and runs one install command. Their first session starts with a brief. Their work is logged under their own identity, checked from the key itself, not from an email typed into a record. Tools without session hooks get an instructions-file version with the same rules.

People and keys. When someone leaves, their key is revoked, their tasks are reassigned and their history stays. Keys rotate. No secrets, customer personal data or raw transcripts are stored.

Pilot in stages (the pilot checklist covers each day and week), each with an exit check: a baseline on a few comparable tasks; resumable work; the morning brief; the weekly review; and only then more parallel runs. Before starting, choose a target such as less decision wait or fewer repeated investigations. Day one should give a useful brief; week one should give a report whose totals trace to real records, with no duplicate work and no unpriced spend.

Budget for the framework itself: the brief, the coordinator and the ceremonies cost money too. In my own measured runs, coordination was a large share of the total.

Run it on Personize (piloting): one setup session for the admin, an invite and a personal key for each developer, and the agent helps from the first session. Run it elsewhere: any store works if it has typed records with stable keys, conditional updates for claims, links between records, retrieval, and per-person identity. The starter kit includes a small local store for trying it.

Evidence and related work

This comes from my own team: two developers and a few weeks of records. It is a direction backed by a working system, not a proven standard.

Others are working on the same question, and the critics are worth reading too:

• AWS's AI-Driven Development Life Cycle (July 2025) replaces sprints with "bolts" of hours or days and epics with "units of work", and adds whole-team Mob Elaboration and Mob Construction sessions. It is the closest published successor to Agile, and it makes the opposite bet on meetings: it brings the team together for each bolt, while Agentic Kanban takes the meeting out and batches decisions one to one.

• OpenAI's Building an AI-Native Engineering Team splits each lifecycle phase into what to delegate to agents, what engineers review and what they own. That split matches the autonomy levels here; it defines no team rhythm or budget.

• Steve Yegge's Gas Town (January 2026) orchestrates many coding agents with a coordinator, short-lived workers, a merge queue and Beads, a git-backed memory. It is the nearest relative of the runner behind this playbook. Reports describe it as alpha and expensive; Agentic Kanban adds the human decision layer and the budget.

• Birgitta Böckeler's review of spec-driven tools (October 2025) found heavy review overhead ("I'd rather review code than all these markdown files"), fixed workflows that are overkill for small changes, and a false sense of control. The lanes above exist because of that critique.

• Mike Mason's January 2026 review argues that coherent software at scale comes from orchestration and human oversight, not autonomy.

• IBM's Radical application development (July 2026) makes a spec folder the source of truth and expects standups and planning to shrink. It defines no ceremonies or metrics.

• SDAD (Nguyen and Nguyen, 2026) maps Scrum onto agentic development. It keeps Scrum's roles with agents as tools inside the Developers' accountability, argues the two-week sprint is obsolete, and keeps short human stand-ups.

• Agentsway (Bandara and colleagues, 2025) proposes a methodology with a human orchestrator and specialized agents, positioned against Agile, Kanban and ShapeUp.

• Microsoft's Agentic-Agile treats agents as contributors inside Agile.

• Park and colleagues (2026) studied 19 developers supervising coding agents and found that supervision concentrates in planning.

What is different here: it is the team layer, not another per-task method; a personal agent for each developer replaces the team standup with a one-to-one brief; decisions and budget are the planned resources; cost per accepted task is a first-class number; ceremonies take records in and leave records out; the contract and kit are open; and it comes from a working team's records.

Adoption levels

Your answers in Check where your team stands place you: mostly first options means assisted; mostly last options means coordinated or beyond.