AgentKit 2.0 Production Design Patterns — Strategic Architecture for 16 Specialized Agents
How to compose AgentKit 2.0's 16 specialized agents on a real production project: five orchestration patterns, which four agents earn a permanent seat, AGENTS.md as team standards, and how to split work across a 1M token context with Gemini 3.1 Pro.
The Monday morning after I ran all sixteen agents at once
The first weekend I had AgentKit 2.0 installed, I launched all sixteen agents at the same time. Frontend, backend, security audit — run them in parallel and surely the skeleton of the project would be standing by morning.
What was waiting on Monday was four mutually contradictory API specifications and a repository where nobody could say which branch was authoritative.
Working as an indie developer, being short-handed is the normal condition, which is exactly why I never questioned the instinct that parallelism equals speed. In agent workflows that instinct is only half right. Parallelism pays off when the decomposition is correct. Get the decomposition wrong and raising concurrency simply inflates the integration cost first.
What follows is the architecture I rebuilt after that weekend. It doesn't begin with a feature tour of the sixteen agents. It begins with the wiring: who receives what, and in what order.
Chapter 1: The Full Picture — Understanding AgentKit 2.0's 16 Agents
Agent Classification Framework
AgentKit 2.0's 16 agents naturally cluster into six functional domains:
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦Understanding 16 specialized agents and designing optimal team compositions for different project scales
✦Five production-ready orchestration patterns: hierarchical delegation, pipeline, fan-out, and more
✦Team-unified rules via AGENTS.md and large-scale development strategies leveraging 1M token context
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
Looking at the classification table, the temptation is to deploy all sixteen. In practice I keep four running continuously. The other twelve get woken up only when a specific situation calls for them.
The four that stay resident
Project Coordinator — the only one always on. Its real job is deciding whether the other three need to be called at all
Backend Architect — once the schema and endpoint shapes are settled, downstream rework drops sharply
Test Engineer — agent-generated code tends to be "working but brittle," so having tests written first ends up being faster
Security Auditor — most of the rejections I've seen in App Store review trace back to skipping this step
The twelve I call situationally
Design System Manager and Cloud Architect only pay for themselves once the surface area crosses a certain size. On an app with fewer than ten screens, asking for a full design-token system produced token definitions larger than the implementation itself, and every subsequent change got heavier rather than lighter.
I decide residency on three questions:
Will I reference this output three or more times? If it's consulted once or twice, handle it inline instead of standing up a dedicated agent
Does the output feed another agent? Terminal artifacts such as reports can be generated on demand
Can a human articulate the spec? Delegating a domain you can't articulate returns work you can't review
Running all sixteen means personally carrying sixteen reviewers' worth of accountability. The real concurrency ceiling isn't your plan's parallel-execution limit — it's how many outputs you can actually review. Adopting that framing changed how the tool behaves more than any configuration change did.
Chapter 2: Five Battle-Tested Orchestration Patterns
Pattern 1: Hierarchical Delegation
When to use: Large projects (6+ months) requiring staged responsibility distribution.
Explicit context handoff — Parent agents must provide children with:
The full project picture (where their work fits)
Interface boundaries (who collaborates with whom)
Constraints (tech stack, timeline, budget)
Success criteria (definition of "done")
Manager View inbox tracking — Centralize completion reports to optimize overall schedule and detect bottlenecks early.
Clear escalation paths — When blockers emerge, teams report upward through one level; the coordinator rebalances priorities.
Real-world example: A B2B platform hit a critical path issue in month 3: payment endpoint design was delayed because the Security Auditor needed time for OAuth 2.0 vetting. The coordinator promoted security tasks to parallel execution, containing delay to one week instead of three.
Pattern 2: Pipeline Pattern
When to use: Frequent feature releases (monthly or more).
Spec → Code Gen → Code Review → Test → Docs → Release
↓ ↓ ↓ ↓ ↓
Writer Builders Reviewers Test Docs
(Frontend Team Expert
+Backend)
Implementation essentials:
Sharp input/output contracts — The spec stage must be 100% complete (all endpoints, request/response types, error codes). The code generation stage never blocks waiting for clarification.
Identify parallelizable stages — Frontend UI and backend test suite creation can run in parallel. Visualize the critical path and compress it.
Quality gates between stages — Code passes linting and type checks before moving to testing; tests pass coverage thresholds before performance review. Automate, don't manually approve.
Real-world example: A SaaS company compressed its payment feature cycle from 10 days to 7 days by running spec (Day 1–2), code gen + test design (Day 2–4), and integration tests (Day 4–5) in parallel, with sequential-only review gates.
Pattern 3: Fan-out/Aggregate
When to use: Independent module development or multi-environment deployments.
Set timeouts — Each parallel task has a maximum wait (default 30 min, critical tasks 60 min). Detect hung agents early.
Graceful partial failure — If Dev deployment succeeds but Staging fails, retry only Staging. Full re-execution wastes time.
Result aggregation — Manager View shows "3/3 passed" or "2/3 passed, Staging error: DNS config" for quick diagnosis.
Real-world example: A daily data pipeline pulls from 5 independent sources (API, database, CSV, event log, partner API) in parallel. After aggregation, a unified transformation runs. If one source errors, only that source re-runs.
Pattern 4: Spec-Driven Development
When to use: Requirements are volatile and multiple refinements are expected.
Manager: "Define requirements for feature X"
↓
Backend Architect + Frontend Builder (co-author spec v1.0)
↓ (approved by Manager View)
Project Coordinator (schedule + resources)
↓
All development agents (implement spec v1.0)
↓ (6 weeks later)
Manager: "Customer wants module Y to work differently"
↓
Update spec → v1.1 → impact analysis → schedule adjustment → re-deploy
The specification becomes the single source of truth—not code, not Slack messages, not the manager's memory.
Implementation essentials:
Version control your spec — spec-v1.0.md → spec-v1.1.md (added security requirement) → spec-v2.0.md (API redesign). Always cite version in agent instructions.
Prevent spec drift — If code diverges from spec, stop implementation until they're aligned. Create a new spec version and notify all agents.
Formalize change requests — "I want to change X" → update spec → analyze impact → re-estimate schedule → notify agents. No ad-hoc modifications.
Real-world example: A startup iterated through 5 spec versions over 8 weeks (30% of original requirements changed) but stayed on schedule. Traditional waterfall would've delayed 2 months. Spec-driven approach made changes transparent and measurable.
Pattern 5: Quality Assurance Pipeline
When to use: Production downtime carries real cost (finance, healthcare, e-commerce).
Automate everything possible — If you're manually checking something twice, automate it. Eliminate human error.
Run gates in parallel — Code Quality and Test gates are independent; Performance and Security are independent. Compress 10-day sequential to 6-day parallel.
Handle failures decisively — "Performance baseline not met" → identify bottleneck → optimize → re-test. Don't defer to the next release.
Chapter 3: AGENTS.md — Your Team's DNA
The single most important artifact in AgentKit 2.0 production deployments is AGENTS.md: a document encoding every technical decision, standard, and safety rail that all 16 agents follow.
Essential sections in AGENTS.md
# AGENTS.md — Team Development Standards## Tech Stack Decisions- Frontend: React 18 + TypeScript 5.x + Tailwind CSS 3.x- Backend: Node.js 20 LTS + Express 4.x- Database: PostgreSQL 15 (primary), Redis 7.x (cache)- Testing: Vitest (frontend), Jest (backend)- Deploy: Docker + Kubernetes- Monitoring: Prometheus + Grafana## Code Quality Rules- TypeScript strict mode enabled- ESLint + Prettier mandatory- Test coverage minimum 80%- Cyclomatic complexity < 10- Line length ≤ 100 characters## Security Requirements- All env vars in .env.example (no hardcoding)- Auth: OAuth 2.0 Bearer tokens- DB: Prepared statements only (prevent SQL injection)- CORS: Explicit whitelist- Dependencies: Weekly npm audit, auto-patch low severity## Inter-Agent Communication- JSON format for all task specs- Dependencies as DAG (Directed Acyclic Graph)- Deliverables via Git (commits, PRs, tags)## Deployment Stages- Three environments: dev, staging, production- Canary deployment: 5% → 25% → 100%- Automatic rollback on error rate > 1%
Why does AgentKit 2.0 use Gemini 3.1 Pro? Its 1 million token context window (≈750,000 words)—5x larger than Claude 3.5 Sonnet's 200k window. This isn't just a quantitative upgrade; it's a strategic capability.
Three-stage context utilization
Stage 1: Project-wide understanding on first interaction
1M token allocation:
- AGENTS.md: 15 KB
- Full specification: 200 KB
- Critical codebase (curated): 400 KB
- Dependency documentation: 100 KB
- Available for instructions: ~200 KB
When the Backend Architect receives its first assignment, it gets:
The entire tech stack and AGENTS.md
All API specs (no waiting for clarification)
6 months of Git history (understands past decisions)
Existing related code (avoids reinventing)
Result: No "wait, which endpoint was that?" delays.
[ ] AGENTS.md reviewed for drift (tech updates, new best practices)
[ ] Dependency documentation refreshed
[ ] Past month incidents analyzed → AGENTS.md improvements
[ ] New CVEs evaluated, security guidelines updated
[ ] Cost analysis: AgentKit spend vs. human time saved
Conclusion
All five patterns here — hierarchical delegation, pipeline, fan-out/aggregate, spec-driven, quality assurance — rest on the same precondition: that the decomposition is correct. Which means that when progress stalls, the thing to question is neither your concurrency setting nor your plan tier. It's the granularity of the split.
The concrete next step I'd suggest is writing twenty lines of AGENTS.md. Three sections only: tech stack, code quality rules, prohibited patterns. That alone visibly reduces contradictions between agents. A comprehensive AGENTS.md is something you grow through operation, not something you finish on day one.
My own first AGENTS.md was under twenty lines. It's close to two hundred now, and every line added came from an incident that actually happened. It isn't a document assembled by filling in a template — it's a record of things that went wrong, which is precisely why it gets followed.
Thanks for reading this far. I hope it gives you a usable starting point.
Share
Thank You for Reading
Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.