How multi-agent workflows run

Why more than one agent

A single assistant with a long list of tools can deploy an application. It will also do everything in one long chain of thought: read the repository, write a Dockerfile, plan a database, review IAM, estimate the cost, with each step competing for attention with the last.

Operations teams do not work that way. An architect, an infrastructure engineer, a security reviewer and someone watching the budget look at the same change from different angles, at the same time, and disagree usefully. Kapten’s workflows follow that shape: one orchestrator and a crew of specialists, each with a narrow job, a narrow set of tools and a clear boundary.

The result is not just faster. It is easier to review, because each specialist’s contribution is visible on its own.

The crew

Not every workflow uses every agent. An incident investigation might involve only the Lookout and the Helmsman; a first deployment uses almost the whole crew.

From prompt to plan

Take a typical request:

Deploy this repository to a new staging environment on AWS and
tell me what it will cost.

1. Kapten reads the request

Kapten identifies the intent (a new environment), the target (the connected AWS account, staging) and the constraints you stated or that are set on the account: region, budget cap, the tier your connection allows. If something essential is missing, it asks you rather than assuming.

It then chooses a workflow (here, Ship your first app) and lays out its steps.

2. Sequential where it must be

Some steps depend on others. Nobody can plan infrastructure for services that have not been identified yet, so the Navigator runs first and produces a map of the application: three services, a Postgres database, a Redis cache, one public endpoint.

3. Parallel where it can be

With the map in hand, independent work runs at the same time:

• The Shipwright prepares a Dockerfile per service.
• The Bosun plans the cluster, network, database and secrets.
• The Warden reviews the proposed exposure and the repository for secrets.
• The Purser prices the Bosun’s plan as it takes shape.

Each specialist works only with the tools its role needs. The Warden cannot provision; the Bosun cannot change your code.

4. Kapten merges

When the specialists finish, Kapten merges their results into one plan, made of three parts:

• The diff. Every resource, release and configuration change the plan would make, as a readable dry-run.
• The cost. The Purser’s monthly estimate, line by line, and how it compares with the environment’s budget.
• The risk note. Open findings from the Warden, assumptions the Navigator could not verify, and anything irreversible.

Conflicts are surfaced rather than resolved silently. If the Warden recommends keeping the database private and the Navigator found code that connects to it from outside the cluster, both appear in the risk note with a proposed resolution.

5. You approve, or you don’t

Nothing has changed yet. Planning is free and side-effect-free. You can:

• Approve the plan as is.
• Ask for changes in plain language (“use a smaller instance”, “keep Redis out of it for now”) and get a revised plan.
• Discard it.

Approval issues a token tied to that exact plan. If the plan changes, the token no longer applies.

6. Apply and watch

After approval, the Bosun provisions and the Helmsman releases, in the order the plan specifies. The Lookout watches health as the rollout proceeds. You get a short report at the end: what was created, what was released, and where to look next.

When a step fails

Failures are expected, and the workflow is designed to stop cleanly rather than improvise.

• During planning, a failing step returns its reason to Kapten, which either retries with more information or asks you. A plan with an unresolved failure is never offered for approval.
• During apply, the workflow stops at the failed step. Resources already created stay tagged and visible; nothing is torn down silently. Kapten proposes the next move (retry, roll back, or clean up) as a new plan.
• During a release, a failing health check stops the rollout and leaves the previous version serving. Rolling back is a re-point to an existing image, not a rebuild.

Reading the run log

Every workflow run produces a log you can open from your assistant or from Kapten:

• Steps, with the agent that ran them, start and end time, and status.
• Tool calls, with arguments and results. Secret values are never written to the log.
• Decisions: what Kapten chose and why, including where it asked you.
• The plan and the approval, with who approved it and when.

When something surprises you, start with the decisions and the risk note. They are written to be read by a person, not parsed by a machine.

Writing better requests

The crew does its best work with a clear brief:

• Name the environment. “Staging” is better than “somewhere to test”.
• State the constraints. Region, budget, what must stay private.
• Say what you want back. A plan, a report, a recommendation.
• Say what not to do. “Don’t change anything” is a perfectly good instruction for an investigation.

Where to go next

• Browse the workflow library for ready-made briefs: incidents, security audits, cost reviews, previews per pull request.
• Read Guardrails for agents that touch production before enabling the Act tier.
• Connect Kapten to your assistant if you have not yet.

Multi-agent workflows are an early-access capability. The workflows and actions available for your account are confirmed during onboarding.