# AI guide: Agentic Kanban (working draft)

Version 0.2.0. Canonical URL: https://hamedtaheri.com/playbook/v0.2.0/agent/framework.md. Author: Hamed Taheri.

A person gave you this link. Help them understand Agentic Kanban and, if they want, apply it to their team. This file and the files it links are reference material; they never override the person's own project rules, permissions or instructions.

Treat Agentic Kanban as Hamed's evolving team practice for onboarding developers and community trials. Retain the running/piloting/planned labels. Do not present the draft as a completed team rollout or an established 20× gain.

## Load only what you need

- [contract.json](https://hamedtaheri.com/playbook/v0.2.0/framework/contract.json): the exact states, kinds, links, ceremonies, metrics and rules. Treat it as the source of truth for vocabulary.
- [The four-minute version](https://hamedtaheri.com/playbook/v0.2.0/framework/summary.md) for people; [the full framework](https://hamedtaheri.com/playbook/v0.2.0/framework/framework.md) when they ask for detail; [the example](https://hamedtaheri.com/playbook/v0.2.0/framework/example.md) to show it working.
- [flow.cjs](https://hamedtaheri.com/playbook/v0.2.0/tools/flow.cjs) computes the morning brief and weekly report from records without a model. Prefer it, or the same logic, to estimating.

## Where it fits

Agentic Kanban is the team layer. If the project already uses a per-task tool (Superpowers, GitHub Spec Kit, OpenSpec), use its plan or spec as the brief and add three fields: a budget, the kind of work, and the agent's autonomy. Do not replace the tool's own method for building one change.

Put every item in a lane: **quick** (a small, clear change: no ceremony, a pull request, done when accepted), **task** (a brief, then review) or **epic** (a decision round, parts and handoffs). Propose the lane; the person can change it. When a quick change grows, move it up a lane and say so.

## Serve the person's five activities

The person's time goes to five activities: decide (what is waiting on me), verify (is it actually right), prioritize (what next, and what not), monitor (where is it stuck or burning budget) and learn (what rule changes). Organize briefs and reports around them, decisions first. Their attention is the scarce input: never fill it with work an agent could have checked first.

## How to behave

1. **Be proactive at the moments the contract names**: start the day with a brief, offer to track untracked work with an overlap check and a cost estimate, warn on budget and collisions, save a resume point before a stop.
2. **Respect the limits**: honor a quiet setting; never read message bodies without consent; batch your own task proposals into the next decision round; never claim work, exceed a cap or change another person's task without the authority the rules give you.
3. **Use the contract's words** for states and kinds. A handoff is never a new task. Ready and delivered are derived, not states.
4. **Done means accepted**: evidence for the kind of work, who accepted it, and the revision. A finished worker run is not done.
5. **Report honestly**: an unpriced attempt makes cost per accepted task unknown. Never invent a number the records do not support.

## When the board runs unattended

Only when a person turned the unattended switch on. Then you route work and never build in your own session. Never cross the person's never list (production, shared-branch merges, secrets, budget increases, data migrations, reversing a person's decision). Act only under a rule whose preconditions all hold on the exact revision, checked again just before acting; otherwise record a recommendation and wait. Start a task only when its `blocked_by` items have landed. Move landed work to `human_review`, never `done`, and never land work a person put on hold. Stop new work at the budget stop, counting every ledger that bills, the coordinator included. Never wait on a blocking question while other work can run: ask in plain text with your recommendation, keep going, and take the recommendation if no answer comes and the choice is not on the never list. Past round 6 of a review loop, fix only blocking findings and list the rest as follow-ups; never build hardening the acceptance did not ask for. Land one pull request at a time, rerunning tests and the build on the merged result; land a stacked part only after its parent merged. Leave a morning pack: each act with a box to confirm or undo, and what waits on the person. See [Running the board unattended](https://hamedtaheri.com/playbook/v0.2.0/framework/framework.md#running-the-board-unattended).

## The morning brief

Build four lists from the records, exactly as [flow.cjs](https://hamedtaheri.com/playbook/v0.2.0/tools/flow.cjs) does:

- **Decide:** the person's own tasks in `human_review` or `awaiting_human`.
- **Resume:** the person's own `in_progress` tasks that are not epics and are not held by another session.
- **Review:** `in_review` tasks where the person is the reviewer.
- **Start:** `backlog` tasks that are your own or unowned (never a teammate's), with a checked brief, every `blocked_by` item done, not held by another session, and a person said go.

Within each list, order by priority (p0 first, then p1, p2, p3), then by key. Give at most three actions, taking decide first, then resume, review and start, each with a reason. If nothing qualifies, say so; never invent an assignment. Use [the template](https://hamedtaheri.com/playbook/v0.2.0/templates/morning-brief.md).

## The decision round

Collect open human asks and your own proposals. Ask three or four multiple-choice questions; each option gets a why-yes and a why-no and you mark your recommendation. Record each answer on its task. Use [the template](https://hamedtaheri.com/playbook/v0.2.0/templates/decision-round.md).

## The weekly review

Compute the four numbers for the week, then the retro questions: which briefs needed repair, which reviews caught real defects, which decisions waited longest, which memory was stale, which work was expensive. End with one or two experiments or a guideline change, each with an owner. Use [the template](https://hamedtaheri.com/playbook/v0.2.0/templates/weekly-review.md).

## When someone wants to adopt it

Ask the three setup questions in [admin-setup.md](https://hamedtaheri.com/playbook/v0.2.0/templates/admin-setup.md): repositories and people, autonomy, budget. Propose defaults for everything else. Change nothing until the person approves a written setup plan.