A collision is coming that most teams have not noticed yet.
On one side you have the workflow your team actually uses. If you run a platform or operations team, it probably looks something like Kanban: pull-based flow, WIP limits, design sessions before implementation, a small number of states that everyone understands. The workflow exists to serve the people. You have spent years tuning it. It works.
On the other side you have the lifecycle your AI agent needs. If you are using an agentic framework — Swamp, or something like it — the agent operates through a state machine with enforced transitions, upfront planning, adversarial review gates, and checks that physically prevent skipping steps. The lifecycle exists to constrain the agent. It works.
The problem is that they disagree on almost everything that matters.
Where they collide
Who drives the work
A mature Kanban workflow is pull-based. Team members finish what they are working on, check their WIP limit, and pull the next highest-priority item from the ready queue. Nobody assigns work. The system trusts the people to self-organize.
An agent lifecycle is operator-initiated. A human tells the agent to start working on a specific issue. The agent cannot pick up work on its own — and for good reason. If any agent could grab any issue the moment it was filed, the issue body becomes an attack surface. Requiring an operator in the loop is a security boundary.
These are not just different mechanics. They reflect different theories of trust. Pull-based flow says: trust the worker to choose well. Agent lifecycles say: constrain the worker because it cannot be trusted to choose at all.
How planning works
In a team workflow, design sessions are collaborative explorations of the problem space. The whole team asks questions: What are the risks? What do we not know? What is the simplest experiment? The value is in the inquiry itself, not in producing a document. Planning happens just-in-time, at the appropriate level of detail, because requirements change and early detail is waste.
In an agent lifecycle, the agent generates a complete implementation plan against the repository’s conventions, then an adversarial review tears it apart across defined dimensions. The human reviews the plan and either gives feedback or approves. Planning is a production activity — the agent writes a plan, the system validates it, the human signs off. Implementation is blocked until the plan passes.
One approach says: do not plan details too early because context will change. The other says: plan everything upfront because the agent needs a verified specification to execute against. Both are right for their context. They are incompatible if applied to the same work.
How many states you need
A well-designed Kanban workflow uses as few states as possible. Six as an example: New, Design, Ready, In Progress, Review, Closed. Adding more states is explicitly an anti-pattern — it creates confusion, harms flow metrics, and breaks standardization.
An agent lifecycle needs granular states because each one is a checkpoint the agent can resume from. Ten phases could be common: created, triaging, classified, plan_generated, approved, implementing, pr_open, pr_failed, releasing, done. Each phase has specific entry conditions and exit checks. The granularity is not bureaucracy — it is what makes the agent resumable and auditable.
If you try to map one onto the other, you lose something either way. Collapse the agent states into your six Kanban columns and you lose the guardrails that prevent the agent from skipping steps. Expand your Kanban board to match the agent lifecycle and you drown your human team in states that exist to constrain a machine.
What failure means
A team workflow optimized for learning treats failed work as information. A hypothesis that was worth testing but did not pan out is a successful experiment. You close it, capture the learning, and move on. The system encourages experimentation by making failure safe.
An agent lifecycle treats failure as something to be prevented. The adversarial review exists specifically to catch bad plans before they reach implementation. Failed work means the process failed — the review should have caught it, the checks should have blocked it. The model has no concept of a hypothesis worth running that produced a negative result.
These are different organizational values about risk. One optimizes for learning velocity. The other optimizes for execution correctness.
Where hierarchy lives
A team workflow typically has a work hierarchy: strategic goals break down into initiatives, which break down into deliverable stories, which break down into tasks. Different stakeholders care about different levels. The hierarchy is how you connect daily work to organizational direction.
An agent lifecycle is flat. Each issue is an independent instance of the lifecycle model. The agent working issue #47 has no awareness that it is part of a larger initiative, that three other issues depend on it, or that its priority comes from a quarterly goal. The lifecycle governs how a single issue moves through phases, not how issues relate to each other.
Why this matters now
This collision is not theoretical. If you are integrating AI agents into an existing team workflow — and you should be — you will hit it.
The naive approach is to pick one side. Either you force the agent into your existing workflow (and lose the guardrails that make agents reliable) or you force your team into the agent’s lifecycle (and lose the human-centric principles that make your workflow effective).
The better approach is to recognize that these are two different systems optimized for two different actors, and to design the integration boundary deliberately.
The agent needs a state machine with enforced transitions and adversarial review. Give it one. But that state machine does not need to be your team’s Kanban board. It can live underneath it.
Your team needs pull-based flow with minimal states and collaborative design. Keep it. But recognize that when a story involves agent execution, the agent’s lifecycle runs inside your “In Progress” state as a sub-process, not as a replacement for it.
The design session where your team explores the problem space happens in your workflow. The implementation plan the agent generates happens in the agent’s lifecycle. The design session produces the constraints the agent plans against. The agent’s plan is one possible execution of what the team decided.
This is not a merge. It is a composition. The human workflow governs what work matters and why. The agent lifecycle governs how a specific piece of that work gets executed. They operate at different levels of abstraction, and trying to flatten them into one system is where teams will get into trouble.
The work ahead
Most teams have not hit this yet because most teams are still using agents for one-off tasks — generate this code, fix this bug, write this test. The agent does not need a lifecycle for that. It needs a lifecycle when it is doing multi-step work that spans hours or days, involves planning and review, and needs to be resumable and auditable. See for example Paul Stack’s description of six parallel workstreams across eight days.
That is where we are headed. And when you get there, you will discover that your carefully tuned workflow and your agent’s carefully designed lifecycle want fundamentally different things.
The answer is not to pick one. It is to figure out where one ends and the other begins.