The Agentic Loop: Turning a Task Board Into a Full Dev Team

July 19, 2026 • 9 min read • Copy URL •

Abstract illustration of a product board flowing through a cluster of connected agents to a merged pull request, with a faint loop closing the cycle

Illustration: product board → agent team → merged PR (original)

I keep coming back to one picture. You're looking at a task board — Notion, Jira, ClickUp, whatever your team uses. There's a ticket: "Add a GET /invoices endpoint with pagination and filtering." You hit a button labeled Develop. You close your laptop, go for a walk, and by the time you're back there's a pull request waiting for you — tested, documented, with a screenshot of the endpoint actually working — and the only thing left for you to do is press merge.

No terminal. No IDE. No standup about who's picking up the ticket. Just a board, a button, and a review.

That's the idea I want to lay out here: an agentic loop — a pipeline that connects your product management app to a host that can run coding agents, wired so that a team of specialized agents can pick up a task, build it, test it, and hand it back as a reviewable PR, without anyone sitting behind a keyboard while it happens. The diagram above lays out the whole shape; the rest of this post walks through it piece by piece.

I've been designing this on top of Claude Code and the Claude Agent SDK, and it turns out most of the pieces already exist — they're just not usually wired together this way. Let me walk through the idea, where I've had to correct my own assumptions along the way, and what the actual flow looks like.

The trigger: from ticket to sandbox

The first piece is boring by design, and that's the point. Your product management app doesn't need to understand agents — it just needs to fire a webhook when someone changes a ticket's status to "Ready for Agent" or clicks a custom button. That webhook hits a host: a CI runner, a self-hosted server, or — the option I like most for getting started — Claude Code on the web, which runs sessions on Anthropic-managed cloud infrastructure. Sessions persist even if you close the browser, you can configure the environment (Docker image, network access, setup scripts), and — this matters — your git credentials never actually sit inside the sandbox. Auth goes through a scoped proxy, so a compromised sandbox doesn't mean a compromised repo.

The host clones the repository, creates a new branch, and hands the ticket's description to an agent as its starting prompt. This is functionally identical to what already happens with Claude Code's GitHub Actions integration: mention @claude on an issue, and it clones the repo, does the work, and opens a PR. The same pattern exists for GitLab CI/CD. Your product board doesn't need a bespoke integration with Anthropic — it needs a webhook into a pipeline that already knows how to do this.

For teams that want more control than a hosted sandbox, the same loop runs through the Agent SDK in headless mode (claude -p "<task>" --allowedTools ...) on your own infrastructure, or through Managed Agents, a hosted REST API where Anthropic runs the agent and the sandbox and your app just streams events in and results out. Three ways to host the same loop, depending on how much infrastructure you want to own.

One correction I had to make to my own thinking here: the task description isn't a nice-to-have, it's the actual API contract between your product process and the agent team. A vague ticket produces a vague implementation — garbage in, garbage PR out. That's a big enough topic that it deserves its own article; for now, assume the ticket is rich: acceptance criteria, edge cases, examples, links to related code. Everything downstream depends on it.

Meet the team (they're all just files)

Here's the part that surprised me when I actually looked at how this works under the hood: a "team member" is not some elaborate piece of infrastructure. It's a markdown file.

Claude Code calls these subagents — specialized assistants defined as a .md file with YAML frontmatter, living in .claude/agents/. Each one gets a name, a description of when to use it, a restricted set of tools, and a system prompt. That's your backend developer, your API designer, your QA engineer, your performance reviewer. Nothing more exotic than a well-written file and a role.

The advice I found in Anthropic's own docs, and now follow, is to keep these tight — a short, sharp description of identity and responsibility, not a novel. The temptation is to write a two-page personality bible for your "Senior Staff Backend Engineer." Resist it. Each subagent runs in its own context window, so a bloated prompt is pure overhead on every single task it touches.

A realistic starter roster for a full-stack feature:

Architect — decides where new code belongs, keeps service boundaries clean.
API designer — owns the interface: routes, schemas, status codes, versioning.
Backend developer — writes the implementation.
Frontend developer — builds the UI and wires it to the API.
Tester / QA — writes and runs tests, checks edge cases against the ticket.
Code reviewer — reads the diff for style, safety, and dumb mistakes.
Performance engineer — checks for N+1 queries, unbounded loops, obvious hot paths.

Swap roles in or out based on what the ticket actually touches — a payments ticket might add a security reviewer, a pure backend job might drop the frontend developer entirely. The set isn't fixed — it's whatever roles your team would actually staff for the work.

The four things that make an agent good, not just present

This is where I had to untangle my own thinking, because I was originally lumping four different concepts into one blob called "agent config." They're actually distinct layers, and Claude Code treats them as such:

Subagents are who — identity, scope, and which tools they're allowed to touch. The architect probably shouldn't have Bash access to run arbitrary shell commands; the backend developer probably needs it.

Skills are how — packaged, reusable capabilities. A SKILL.md bundle with instructions and optional scripts, loaded dynamically only when relevant, so your context window isn't paying rent on a skill nobody's using this turn. "How to scaffold a new REST endpoint in our framework" is a skill. "How to run our test suite and interpret failures" is a skill.

Rules are the house style — your API design conventions, your entity-naming scheme, your error-handling patterns. In practice these live in a project-level CLAUDE.md (context every agent reads) plus, critically, hooks — shell commands that fire automatically at points in the agent's lifecycle. Format code after every edit. Block a commit if lint fails. Refuse a Bash command that touches .env. Rules you hope an agent follows are suggestions; rules enforced by a hook are guarantees.

MCP connections are reach — the Model Context Protocol is the open standard for wiring an agent to external tools: your ticket tracker, your database, your Git host, and — genuinely one of my favorite pieces of this whole design — a browser. The Playwright MCP server lets an agent spin up a real browser, click through the feature it just built, and take a screenshot. That screenshot goes straight into the PR description. You stop reviewing a diff and start reviewing evidence that the thing works.

Four layers, four jobs: identity, capability, convention, reach. Confusing them is how you end up with a "backend developer" subagent whose system prompt is secretly trying to also be a linter, a skill, and a security policy.

Here's the whole loop end to end — board to merge — before we go on to how the team inside it actually talks to each other:

Diagram of the agentic loop: a product board trigger flows through a host/CI runner, a team lead agent, a seven-role agent team with direct messaging, a verification loop, and out to a pull request for human review — Diagram: the agentic loop, from product board to pull request (original)

How the team actually talks: subagents vs. agent teams

I need to correct something here — not one of my own assumptions this time, but a gap in how I first described the tooling. My instinct was to model this as pure hub-and-spoke: a lead agent assigns work, each specialist does its piece in isolation, and everything reports back through the lead, full stop. That's accurate for subagents, Claude Code's default delegation model — each one gets its own context window, but it only ever reports results back to whoever spawned it. Subagents don't talk to each other.

But there's a second, separate mode built for exactly the picture I originally had in mind: agent teams. One session becomes the team lead; teammates spawn as full, independent Claude Code sessions, each with its own context window — and, this is the part I'd undersold, they can message each other directly through a mailbox (the SendMessage tool), not only report upward. They also share a task list: the lead can hand out work explicitly, or a teammate can finish its task and self-claim the next unblocked one straight off the shared board.

That maps much more closely onto "the backend developer hands off to the tester, who flags the reviewer" than hub-and-spoke does. It's still coordinated, not a free-for-all — there's a shared task list with real dependencies, and the lead can require any teammate to submit a plan for approval before it touches code — but teammates aren't forced to route every exchange back through the lead first.

Two catches before you build on this. First, agent teams are experimental and off by default — you turn them on with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, which is close to the literal "flip a setting to let the team communicate" switch I was picturing before I knew it already existed. Second, teams don't nest: teammates can't spawn their own teammates, only the lead manages the roster, and permission prompts still bubble up to the lead's session — a teammate can't approve its own risky action, and it can't relay a fake "approval" from another teammate to sneak one past the check either. There's also a quieter wrinkle: if you reuse a subagent definition as a teammate, its own skills and mcpServers frontmatter don't carry over — a teammate always loads skills and MCP servers from your project and user settings, same as any other session. So the project-level Rules and MCP wiring matter more, not less, once you're in team mode.

For a small ticket, plain subagents under one lead are cheaper and plenty. For the kind of small, self-contained feature team this pipeline assumes, agent teams is the mode that actually matches the picture: a lead spun up per ticket, with named teammates that message each other, claim tasks off a shared board, and only escalate up when something needs a decision.

Landing the work

Once the loop closes, the closing agent does the unglamorous but important stuff: a conventional commit message, a short doc update describing what changed and why, and a pull request — with that Playwright screenshot or short demo clip attached if the ticket touched anything visual. This part isn't hypothetical; it mirrors what Claude Code's GitHub Actions integration already does today: it can watch a PR after opening it, react to a failing CI check or a human review comment, and push a fix automatically. So "done" doesn't mean "opened a PR and walked away" — it means the agent stays attached to that PR through the first round of real feedback, human or automated, before disappearing.

Then the loop ends where it should: with a person. You read the PR, look at the screenshot, check the tests passed, and click merge. That's the one step I'm not trying to automate, and I don't think anyone should.

Where this gets hard

I don't want to sell this as a solved problem, because it isn't yet, and glossing over the sharp edges would make this a worse article, not a better one.

Cost scales with the size of the team. Every teammate is a full, independent session with its own context window and its own token bill — agent teams cost noticeably more than plain subagents, and it scales roughly linearly with headcount. A seven-agent team for a small ticket is expensive relative to just writing the endpoint yourself in twenty minutes. Anthropic's own guidance is to start with three to five teammates and size tasks so each one gets five or six items, not one. This pipeline earns its cost on work that's tedious, well-specified, and repetitive — not on every single ticket regardless of size.

Agent teams are still labeled experimental for a reason. They're off by default, there's no nesting a team inside a team, in-process teammates don't survive a /resume, and shutdown can lag while a teammate finishes its current step. None of that rules the approach out — it means you should treat today's version as a v1 that will keep changing under you, and keep a human checking in rather than walking away for a week.

The task description is the bottleneck, not the agents. I said this above and I'll say it again because it's the thing most people underestimate: a mediocre ticket produces a mediocre PR, agents or not. Getting from "a rough idea" to "a ticket rich enough to hand to a team of agents unsupervised" is a real design problem, and it's the subject of the next article.

Whichever mode you pick, the lead needs to be good, not hopeful. If the lead's task breakdown is bad, everything downstream inherits that mistake, faster than a human team would, because nobody's in the loop asking "wait, why are we doing it this way?" until the PR shows up.

Security is a first-class design constraint, not a footnote. Scoped credentials, sandboxed hosts, hooks that hard-block dangerous commands — these aren't optional hardening you add later. An unsupervised agent team with real repo access and real deploy paths is exactly the kind of system you want boring, boxed-in, and well-audited from day one.

None of that is a reason not to build it. It's a reason to build the guardrails at the same time as the pipeline, not after something goes wrong.

What's next

This piece was about the shape of the loop: trigger, host, team, PR, review. Two things I deliberately left out, because each deserves its own space: how to actually write task descriptions rich enough for a team of agents to run unsupervised, and how to build the product management layer that turns a raw product idea into a tree of epics and tickets in the first place — the thing that feeds this whole loop. Both are coming.

For now, the honest summary is this: the individual pieces — subagents, agent teams, skills, hooks, MCP, headless execution, hosted sandboxes — already exist and are documented, mostly built for a human sitting at a terminal. Wiring them into a loop that starts from a product board and ends at a merge button is a matter of assembly, careful role design, and guardrails. Not invention. Assembly is still work — but it's work you can start this week.

AI Agents Claude Code Automation DevOps CI/CD

* * *