Value Stream of the Swarm. Why Agentic Delivery Needs a Different Team.

Picture a mid-tier accounting firm's tax practice building a portal its clients will use to send in documents for multistate filings. The practice leader has promised a live demo to one of the firm's largest clients in three weeks.

The work moves through the practice the way it always has. A business analyst turns the practice leader's requests into stories. Developers build them, a test group checks the build against the stories, and the firm's platform team deploys it. Every one of those groups has AI tools now, and every one of them works faster than it did a year ago.

Early on, the practice leader tells the analyst that no client should ever see a raw error message. The analyst agrees and notes it. But it isn't a feature, so it doesn't belong to any one story. The analyst's AI assistant drafts the stories one screen at a time, and each one is accurate. Developers build each screen to its story, and testers check each screen against its story. Every group does its part well, and the rule doesn't belong to any of them. Then, in a dry run during week three, an upload times out and the screen fills with a stack trace.

The AI tools made each group faster at its own piece. Nobody was holding the rules that apply to all of them. That's the problem we build our delivery teams around. We call the team a Swarm.

What a Swarm Is

A Swarm is three to four senior people and the AI agents they direct. It's one of three parts of how we deliver, next to the Pulse (our five-day agentic loop) and Amplify (our agentic framework accelerator).

The small team is deliberate. With agents doing most of the drafting, development, testing and review, we can keep the key delivery decisions with a few experienced people. They share the same understanding of the product, the architecture and the client's priorities, so there's less context to rebuild as work moves from requirements to release, and fewer places for a rule like the one about error messages to fall out.

They're senior because their main job is judging what the agents produce, and that takes people who've built systems like yours before. Humans drive the decisions. Agents handle the volume. It's the team behind an argument we've made before, that agents make output cheap and judgment scarce (The Drafting Got Cheap. The Thinking Didn't.).

The portal is an example. The model is already in use: we're delivering this way today in Big 4 and mid-tier accounting, consumer lending and field services. Our founders spent 15 years building global tax and audit platforms for Big 4 and mid-tier firms, so practices like the one in our example are familiar ground.

Requirements Stay Connected From Request to Release

Run the portal project with a Swarm and follow the error-message rule through it.

A Swarm doesn't remove every handoff. Your platform team still owns its platform, your security team still reviews what it reviews, and your release controls still apply. What changes is that the same few people carry the context and the accountability through all of them. That's the value stream of a Swarm.

For the practice leader, it means one accountable team from her first request to release, and fewer surprises before her client sees anything. For the firm, it means the AI tools it already paid for start changing how work gets delivered, on the systems it already runs.

This is most useful on existing systems, which is where all of our clients are. Systems people spent years building are full of rules nobody wrote down, and a team that changes every few stages loses them fastest. Greenfield vs. Brownfield. One Swarm. Two Playbooks. covers how the work differs.

Three Decisions, Clear Owners

Agents work at every stage of a Swarm. Three decisions each have a named owner.

• Product Delivery Lead: what gets built. Directs the agents drafting stories and acceptance criteria in your format, approves them with your product owner, and is your single point of accountability.
• Product Engineer: what's good enough. Owns code quality and sets the rules agent review runs by. Agent review checks every pull request, and the Product Engineer steps in wherever your team wants a person reading the code.
• Product Engineering Architect: what's safe to release. Guards the systems you've already built, shows the path to where your platform is going, and owns the release decision after agents run the security scans, regression and impact checks.

Before work starts, we agree with you which of those decisions also need a named approver from your side. Where you require one, nothing moves until that person signs off, and every approval is recorded in your own work tracking system. No agent deploys anything on its own.

Your Rules, Applied Consistently

Halfway through the portal project, the practice's own senior engineer gets pulled onto another engagement. She knew every call to the firm's document management system has to go through a queue, because it throttled the team during last year's extension deadline. That rule lives in her head and a wiki note. On a conventional team, her replacement finds out by breaking it.

In a Swarm, that rule gets found at the start, while she's still on the project. Every engagement begins with Amplify's environment setup, where the agents, the review gates and your standards get configured inside your tools. During setup, our Product Engineering Architect and Product Engineer work with your engineers to identify existing integration constraints, business rules and architectural decisions, including the ones that aren't consistently documented. They capture what they learn where the agents can use it, and keep adding rules as new information comes up during delivery. The agents don't have to rediscover what your people already know.

The queue rule exists because the document management system has real limits. Ignoring it can work fine in testing and fail in the middle of a filing deadline. Once it's captured, agent review checks every change against it. The rule says where it applies, what to flag and what to do instead, links to the decision record that explains why, and names an owner for anyone who thinks it's wrong. The team no longer depends on someone remembering it, and your engineers keep the authority to change it. The firm keeps both the knowledge and the checks that enforce it. The judgment about when a rule should change still belongs to people, which we covered in You Can Outsource Execution. You Cannot Outsource Understanding.

Working Software Uncovers What the Requirements Missed

The Pulse is our five-day agentic loop, and it replaces the two-week sprint. Each loop ends with working results you can run, review and approve, plus a plain-English summary of what was delivered, what's at risk and what we need from you.

The rules catch what someone wrote down. The Pulse uncovers what nobody thought to ask. At the end of the second loop, the practice leader tries the upload screen herself and sees that clients would have to send their state forms one at a time. Nobody had asked how many documents a client sends at once, so no rule covered it. She finds it in a Pulse review, with time to fix it, instead of in a dry run the week of the demo.

Your Team Learns It Too

Your firm may already have Copilot licenses, AI platforms or agent development tools. That doesn't mean they're changing how software gets delivered. A Swarm brings the senior people, the agent configuration and the delivery rhythm that put those tools to work across the whole process.

The engagement is built to leave your team able to run this way on its own. Your people work inside the framework alongside ours the whole way through, maintaining the rules and owning gates as they go. When we leave, the way of working stays with them, in your version of Amplify.

Where It Can Go Wrong

A Swarm has failure modes too, and we'd rather you hear them from us.

The rules drift. The code moves and the knowledge base doesn't, and agent review enforces last quarter's architecture with total confidence. Every rule needs an owner, and drift flags go on the backlog like any other defect.

Agent review becomes the only review. If people wave through whatever the agents pass, review got faster and worse at the same time. The gates that need a person get agreed up front and stay staffed.

Nobody rehearses the handoff. The knowledge base and agent configuration go to your team at the end. That only works if your engineers have been maintaining them for a while beforehand.

When a Swarm Makes Sense

You've invested in AI tools, and software still reaches production at the same pace. Or you've got a prototype that works in a demo and now has to work in production. Or your teams already build with agents, and getting the work through review, testing and release still takes as long as it always did.

Those are the problems a Swarm is built for. Senior people direct the agents, work inside the architecture you already have and stay accountable from the first requirement through release, with your team alongside them the whole way.

Critical Propulsion is an AI Native Services firm. Senior people and AI agents, delivering working software and data products on the systems you already run. Bring us a real project, and we'll show you how we'd take it on.