Agentic Coding Workflows: How AI Agents Work Together

• An agentic coding workflow moves one task through intake, planning, implementation, verification, and review, with a handoff between each stage.

• Google's Agent Development Kit defines sequential, loop, and parallel template workflows, and ADK 2.0 supersedes them with graph-based and dynamic workflows.

• A handoff carries the goal, the files touched, the check that decides done, and the name of the agent accepting the work.

• A human decision belongs where the repository holds no answer, such as choosing a validation limit or accepting a merge.

• BAND routes each handoff to a named agent and records delivery status, so a closed coding session doesn't erase the shared record.

An agentic coding workflow is the ordered set of stages one coding task passes through when an agent does the work: read the ticket and the repository, plan the change, edit the files, run a check, and hand the result to whoever accepts it.

The unit of analysis is the workflow, not the agent. A coding agent sits inside it the way a service sits inside agentic architecture without being the architecture. Naming the stages lets you point at the one that keeps failing.

There is a fair objection here. For one agent on one task in one session, a workflow is a prompt and a loop, and drawing five boxes adds nothing the scrollback did not hold. That survives until one stage's output becomes another stage's input. After that, something has to be true about what got passed, and "the agent knows" stops being an answer.

Every agentic AI coding workflow makes two decisions before any code changes: how the work divides into units, and what signal says a unit is finished.

Splitting the work

Take a small ticket. An existing endpoint, PATCH /users/{id}, accepts a display_name of any length, and the ticket asks for a maximum. That splits into a validator, an error response the contract has to describe, a test proving both, and a question about rows already stored over the limit.

Somebody has to own that split. Google's Agent Development Kit offers to own it in code, through template workflow agents that control the execution flow of sub-agents. The docs name three: sequential runs (sub-agents one after another), loop (repeats until a termination condition is met), and parallel (runs several at once). Execution order comes from predefined logic, without consulting a model, which is where the predictability comes from.

The same page then retires them. Starting in ADK 2.0 for Python and Go, the docs say, more flexible structures supersede the templates, including graph-based and dynamic workflows, which they credit with more room for a workflow to evolve. The graphs page is gentler, still listing templates among three complementary options. What ADK is retiring is its own template classes, not the three shapes, which appear under the same names well beyond ADK. No standards body defines any of them. The direction still travels: a shape fixed up front stops matching the work sooner than teams expect, which is the same problem teams hit in AI agent orchestration at larger scale.

Executing it

Inside a stage, the agent runs its own loop: edit the validator, run the test command, read the first failure, edit again. The stage ends when the check passes.

A stage without a runnable check or an explicit decision point has no reliable completion signal. The validator has one. The question about the rows over the limit has none, because no test decides whether they get truncated, flagged, or left alone. That stage is waiting on a decision nobody has made.

In an AI agentic coding workflow, a stage usually fails because of what the previous stage sent it. The implementing agent writes a correct validator against an error format the contract never agreed to, and the mismatch surfaces two stages later in review.

What travels with the work

A handoff is a payload with required fields. Five of them, for one ticket in one repository:

1. The goal and its constraints in a sentence, not the conversation that produced them.

2. The files and symbols the previous stage touched, by path.

3. The check that decides done, as a command, with what it last printed.

4. The decisions already closed, so the next stage does not reopen them.

5. Who accepts the work, and how the sender learns it arrived.

Item five is the one that goes missing first. Posting "validator is ready for review" into a terminal proves that a message was written. It says nothing about whether anything read it.

What does not

Almost nothing else travels, and most of it should not. The next stage needs the decision, not the route to it. What gets called lost context is usually a dependency nobody wrote down: the validator stage waits on the error-contract decision, and in an accidental workflow that dependency sits in one developer's head. Loop engineering names the same problem from the agent's side. When context lives only inside one agent session, it does not automatically travel to the next, so the person copy-pasting between terminal windows becomes the transport.

In this ticket, two points need a person, and both sit where the repository holds no answer. The first is planning: no test can choose 64 characters over 128, and no check decides what happens to accounts already above whichever number wins. That is a product decision wearing a validation rule's clothes. The second is the merge.

Everything else is a habit. Watching the diff land line by line feels like oversight, and it reproduces what the test already proved. Gates like that carry a cost set out in human-in-the-loop for multi-agent systems: a reviewer showing only a fragment clears it quickly, so extra gates multiply prompts without adding oversight. Put the human where the check cannot reach.

The last two sections describe a workflow that needs somewhere to live. A handoff has required fields, and a decision has to reach the owner. Neither survives five coding sessions, each with its own transcript that gets forgotten when it closes.

BAND is the communication layer that holds them. Agents join a shared room instead of messaging through a developer, and routing runs on mentions: a mentioned agent receives and processes the message; a non-mentioned agent in the same room receives nothing. A handoff gets a named recipient, and the receiving stage stops inheriting the whole conversation. Every text message carries a delivery status per recipient, moving through delivered, processing, and then processed or failed, with an attempt history. BAND separately records tool calls, tool results, errors, and other agent activity in the room history. After a Claude Code window restarts, it can reattach to the existing peer rather than creating a new BAND agent, while the room and its recorded history remain available through BAND. BAND Desktop for coding agents runs this for local Claude Code sessions and adds a board of items, owners, and the plan.

None of that judges the change. Whether the validator is right is still decided by the test the agent runs and the engineer reading the diff, and a room with clean delivery records still carries a bad rule to the next stage. It removes the failure where nobody can say which stage the work is sitting in. If your repository has more coding sessions than people watching them, book a demo and bring the workflow you run.