Agentic Development & Multi-Agent Orchestration
How work is split between agents, and the habits that get good results from any of them.
What Is Agentic Development?
Agentic development — sometimes called vibecoding — is a workflow where you collaborate with AI coding agents instead of writing every line yourself. You describe what you want, and the agent handles the how: writing code, running tests, fixing errors, and iterating until the task is done.
This isn't about blindly accepting AI output. The best results come from treating the agent as a capable junior developer — one that needs clear direction, good context, and code review.
Key mindset shift: Your job moves from "writing code" to "directing, reviewing, and verifying code." The quality of your input directly determines the quality of the output.
Why Multi-Agent?
A single AI agent is powerful — but it has limits. Context windows fill up. Prompts lose focus when mixing UI, backend, tests, and security in one conversation. Knowledge is shallow across too many domains.
Multi-agent development solves this by assigning specialist agents to focused tasks — just like a real engineering team. A Team Lead decomposes work, delegates to experts, and verifies results. Each agent operates within a well-scoped context, producing higher quality output.
Orchestration Patterns
In multi-agent development, an orchestrator (or Team Lead) coordinates the work. It analyzes requirements, creates a plan, assigns tasks to specialist agents, and verifies their output — similar to a tech lead managing a team of engineers.
Key orchestration principles:
- Task decomposition — break work into the smallest meaningful, independently verifiable units
- File partitioning — parallel tasks are given separate files, so merges rarely conflict; a conflict re-runs the task on top of the merged work
- Dependency ordering — tasks are phased so dependent work waits for prerequisites
- Independent verification — every output is reviewed before being accepted
Specialist Agents
Instead of one generalist AI trying to handle everything, multi-agent systems assign focused roles with domain-specific instructions, tools, and context. This mirrors how real engineering teams operate — you wouldn't ask a backend engineer to also design the UI and write the security audit.
Orchestration, architecture decisions, security review — the hardest reasoning.
Feature work, schemas, UI, tests, deployments — the bulk of the work.
Review passes, docs, copy, search metadata — high volume, low ambiguity.
A tier says what kind of model the work wants, not which model to use. Your assistant picks that — it knows which models your account can reach and what they cost today.
Quality Gates
In single-agent workflows, you manually verify output. In multi-agent systems, quality gates automate verification — ensuring every agent's work passes review before being accepted.
- Deterministic checks — lint, type-check, and test suites run automatically
- Fast review — a lightweight reviewer agent checks acceptance criteria, file partitions, and regressions
- Panel review — three independent reviewers vote PASS or BLOCK, when a task asks for it
- Self-improvement — lessons from failures are captured and fed back into future agent prompts
Architecture
Parallel agents, in practice
Steve Yegge's Gas Town scales the loop to many coding agents at once. A Mayor agent turns a request into “beads” with dependencies, and bd ready lists the ones with no open blockers (beads). Each worker gets a git worktree and a tmux session. A merge queue, the Refinery, batches finished work, runs the checks on the merged stack, and bisects when they fail (reference). Its successor is Gas City.
The assistants do parts of this themselves. As their documentation describes it in October 2026:
| Tool | Plans the work as | Runs agents in | Merging |
|---|---|---|---|
Claude Code /batch | 5 to 30 independent units, approved once | a background subagent per unit, each in a worktree | each unit runs its tests and publishes its own change |
Copilot CLI /fleet | subtasks with dependencies, managed by the main agent | subagents, each with its own context window | not documented |
| Kiro | a task graph planned up front; independent tasks run in parallel | subagents sharing one workspace | pull requests, never merged automatically (docs) |
| OpenCastle convoy (experimental) | a task plan, from a PRD when the work is not small, checked in code and shown before it runs | a worktree per task, on the agent CLI your assistant already uses | onto one branch, one task at a time after its review; your checks run once at the end |
Where the convoy engine fits
- One source, every assistant —
npx opencastle initcompiles agents, skills and MCP config for Claude Code, Copilot, Cursor, Windsurf (Devin Desktop), Codex CLI, OpenCode and Antigravity; the convoy engine runs those same agents - The runtime you have — it drives the CLI for the assistant init set up: Claude Code, Copilot, Cursor, OpenCode or Codex
- Nothing to host — state is one SQLite file in
.opencastle/; a stopped run resumes withopencastle convoy resume - Observable — an event log per run and a read-only dashboard,
opencastle convoy dashboard
When to choose a convoy over /batch or /fleet, and real runs with their time and cost: Use cases.
Write Great Prompts
The quality of agent output is directly proportional to the quality of your instructions. Vague prompts produce vague results. Specific prompts with context produce production-ready code.
Be specific and provide context
"Add a `lastLogin` timestamp field to the User model in `src/models/user.ts`. Update the login handler in `src/auth/login.ts` to set it on successful authentication. Use the existing `updatedAt` pattern for the database update." Give vague, context-free instructions
"Track when users log in." Build Tools, Not Tasks
For a large refactoring or a repetitive change, ask the agent for a script that makes it, rather than for the edits themselves.
A script is reviewed once, runs again when new files appear, and can offer --dry-run; two hundred hand edits are none of those.
Create a codemod
"Write a codemod script that finds all React components using the old `<Button variant='primary'>` API and replaces them with `<Button color='brand'>`. Support both JSX and TSX. Add a --dry-run flag that prints changes without writing." Edit every file one by one
"Update every Button component in the codebase to use `color='brand'` instead of `variant='primary'`." With 80+ files, the agent will miss some, introduce inconsistencies, or hit context limits mid-way.
Scope Your Requests
AI agents work best with focused, well-scoped tasks. Large, multi-concern requests lead to mediocre results everywhere instead of excellent results somewhere. Break big features into small, independently testable pieces.
Break work into focused tasks
"Step 1: Create the database schema for invoices with these fields: id, amount, status, customerId, createdAt. Step 2: Build the API route with list and create endpoints. Step 3: Build the UI table component." Ask for everything at once
"Build a complete invoicing system with database, API, UI, PDF export, email notifications, and Stripe integration." Verify, Don't Trust
AI agents are confident, fast, and sometimes wrong. Always verify their output. Run tests, inspect diffs, and check edge cases. The agent is a tool — you're still the engineer.
Ask the agent to prove its work
"After making the changes, run the test suite and show me the results. Also run the type checker." Merge without checking
"Looks good, ship it." (without reviewing the diff or running tests) Use Context Effectively
Agents don't automatically know your project's conventions, architecture, or unwritten rules. The more relevant context you provide, the better the output matches your codebase.
Point to existing patterns
"Create a new service following the same pattern as `src/services/userService.ts` — use dependency injection, return Result types, and log with our structured logger." Assume conventions are obvious
"Create an order service." The agent might use a completely different pattern — classes instead of functions, throw instead of Result, console.log instead of your logger.
Iterate, Don't Restart
When the agent produces something close but not right, give targeted feedback and ask for adjustments. Starting over from scratch throws away correct work and burns context.
Give specific, targeted feedback
"The table component looks good, but the sorting logic is wrong — it should sort by date descending by default, not ascending. Also, the empty state should show the illustration from `public/empty-inbox.svg`." Throw away everything and start over
"This is wrong. Redo the whole thing." Without saying what's wrong, the agent repeats the same mistakes. And you lose the parts that were already correct.