The future of AI agents looks a lot like 2010.

Waldo VanderhaeghenBuilding with AI agents
#ai#agents#workflow#claude-code#engineering

The most useful thing I have added to my agent setup is a kanban board. It did more for the results than any new model or better prompt. The board is three Markdown files and an Obsidian plugin. It decides what Claude Code works on, when a piece of work counts as done, and when it comes back to me for a decision. Each of those rules comes from the backlog, the user story and the acceptance criteria that software teams have used for years, now applied to a team of agents.

Letting the agent run

The conversation around AI agents is almost entirely about orchestration: tool use, memory layers, multi-agent routing. Almost none of it is about managing the work, and my own setup had the same gap. I would open a Claude Code session, pick something to build and let the agent run.

Sometimes that worked, and often it drifted. Context would bleed from one session into the next. When I came back three days later, I had no idea what state things were in or why something had been built the way it was. The problem was never the agent: I had stripped every management structure out of the workflow and expected nothing to change.

The kanban board

The board file

The board is one Markdown file that the Obsidian Kanban plugin renders as three columns: Backlog, In Progress and Done. Each card is a wikilink to a story file, and nothing else goes on a card. Two cards waiting and one finished look like this:

## Backlog
- [ ] [[CVR-019-bedrock-card-rendering|CVR-019 Replace card rendering]]
- [ ] [[CVR-020-dashboard-rollout|CVR-020 Dashboard full rollout]]

## In Progress

## Done
- [x] [[PRJ-008-deploy-pipeline|PRJ-008 Deploy pipeline refactor]]

The story files

Every card has one story file, named CVR-NNN-slug.md. Here is one, abridged:

## CVR-019: Replace card rendering
Goal: cards render from the new classifier output; old path deleted.
Hard gates:
- [ ] all golden cases render identically
- [ ] old renderer removed, not flagged off
Blocker: none
Work log:
- session 1: classifier clean in shadow mode, opening render work

Hard gates are the definition of done, and the story does not move until every one of them is checked. When something cannot proceed, the card stays in Backlog marked ⚠️ BLOCKED. The agent does not skip it silently or abandon it: it marks the card, explains the blocker and stops.

Who moves the cards

I ask Claude to tackle the next story. Stories move to In Progress as the agent works, and they come back to me when they need a human call. Claude is the only thing that moves cards, which is why the board cannot lie about the state of the work. Nothing gets worked on without a story.

Before a story moves to Done, there is a context update step. The work log and the project’s CLAUDE.md are the place to capture what was decided and why, on top of what was built. A story with zero checked boxes is not valid, and durable learnings don’t survive on vibes.

The team

The team is a Markdown file of named roles, each called at a specific point in the process. The most useful one is /refinement-team-deep, the planning council. Six sequential agents go through a plan: Critic, Contrarian, Tech Lead, Software Architect, Engineering Manager, and finally a Revised Planner who synthesises the other five. Each one addresses a flaw the previous one didn’t.

Two stories instead of one

I was redesigning a campaign analysis pipeline when the council flagged a problem with my plan. Shipping the new classification layer and the rendering change together would make it impossible to isolate regressions. The revised plan split them into separate stories: ship the classifier first in shadow mode, verify it on known cases, and only then open the rendering work. It cost two minutes of latency, and the output was two stories instead of one, each with clearer hard gates.

The other roles

The Orchestrator is the default mode: it reads the board, routes work and breaks epics into stories. The Tech Lead is called before anything architectural ships, and the Designer runs /ux-review before a line of markup is written. For a fast single pass, the Critic runs /critique and returns PROCEED, REVISE or ABORT in under a minute. Together with the board, that gives every story the same path from plan to done.

How a story moves through my agent team: the council refines the plan into a story with hard gates. The agent builds it, the roles review it, and the hard gates are checked. An open gate sends it back to building, a blocked story comes back to me, and only after a context update is it done.Council refines planStory with hard gatesAgent buildsRoles reviewHard gates checkedUpdate contextDoneGate open: keep buildingBlocked: my callHow a story moves, stacked: the council refines the plan, a story gets hard gates, the agent builds, the roles review, the hard gates are checked, the context is updated, and the story is done. An open gate returns to building; a blocked story comes back to me.Council refines planStory with hard gatesAgent buildsRoles reviewHard gates checkedUpdate contextDoneGate open: keep buildingBlocked: my call
Roles review means the Tech Lead before anything architectural ships, the Designer before any markup, and the Critic for a fast pass. Only Claude moves the cards.

The retro

The next SDLC primitive I am working on is the retro, with two experiments in progress. A weekly review skill gives me a structured moment to step back, reflect on how the week went and carry the useful parts forward. An agent retro skill looks for patterns across sessions: which skills I reach for, which tasks get repeated or abandoned, and where the gaps are. Both are still rough. The retro is the one SDLC ritual whose job is turning mistakes into process, and agents cannot yet do that for themselves.

Where this is going

A workshop room with a team standing at two whiteboards covered in sticky notes, coffee cups and croissants on the tables, and the author taking a selfie in the foreground

Backlog, stories, acceptance criteria, roles and reviews: we have been working this way for fifteen years. AI agents did not invent a new way of working; they gave us a new team to manage. That is the bet I am making. The SDLC patterns transfer, and the more closely we follow them, the better agent-driven development gets.

The open problems remain. Context does not fully survive session boundaries, and decision rationale evaporates from transcripts. Shared context across sessions and collaborators is unsolved. At AI Bar Camp Berlin last week, every room circled back to the same questions, and nobody has cracked it.

My guess is that the answers look a lot like the questions: better story handoffs, better session summaries, and better ways to make the work log the source of truth. That would mean deeper investment in the old practices rather than inventing new ones, though I am not sure yet. Until then, the part of my setup that keeps a team of agents on track is a board of three Markdown files, embarrassingly low-tech and doing the job it always did for human teams.