Agent Architecture

How Fulcrum's 13 agents work together as an autonomous team

The Paradigm Shift

Stop thinking about AI agents like humans. Humans are expensive, slow, and get tired. Agents are infinite, instant, and free. This changes everything about how you should structure work.

Key Insight: Never queue work for "later" when you can spawn 10 agents right now. The only cost is context window, and that's cheap.

Agent Categories

Fulcrum organizes 13 specialized agents into four categories, each with distinct responsibilities in the development lifecycle:

Category	Agents	Role
Strategy	PM, Tech Lead, Work Orchestrator	Planning, architecture, coordination
Engineering	Frontend, Backend, Database, AI, DevOps, Firmware	Implementation across the stack
Quality	QA Backend, QA Frontend, QA Firmware	Testing, validation, quality gates
Domain	Domain Expert	Business context, industry knowledge

The Communication Model

Agents communicate through two mechanisms: @ mentions for synchronous handoffs and Agent Mail for async coordination in parallel execution.

@ Mentions (Synchronous)

Use @ mentions when you need immediate, blocking collaboration:

// Ask @tech-lead to review an architecture decision
"@tech-lead Should we use PostgreSQL or DynamoDB for this use case?"

// Hand off to @backend after frontend work
"@backend The API contract is defined in api-spec.yaml, implement endpoints"

Agent Mail (Asynchronous)

Agent Mail enables parallel agents to coordinate without blocking. Each agent can send and receive messages through a shared mailbox:

// Agent 1 discovers a dependency
agent-mail send @frontend "Database schema changed, update types"

// Agent 2 checks mail before starting
agent-mail check

When to @ Mention vs. Let Orchestrator Dispatch

Opinion: Default to letting the orchestrator dispatch. Only use direct @ mentions when you have specific context the orchestrator doesn't.

Scenario	Approach	Why
General feature work	Orchestrator dispatch	Maximizes parallelism automatically
Specific architectural question	@ tech-lead	Synchronous decision needed
Multi-component feature	Orchestrator dispatch	Creates optimal dependency waves
Code review for specific file	@ relevant agent	Domain expertise match
Bug investigation	@ domain expert first	Context about business rules

Spawn Many, Spawn Often

The mental model shift: you're not managing a team of 13 people. You're conducting an orchestra that can have 13 × N musicians, where N is limited only by your context budget.

# Anti-pattern: Sequential thinking
1. Ask frontend to build component
2. Wait for completion
3. Ask backend to build API
4. Wait for completion
5. Ask QA to test

# Fulcrum pattern: Parallel execution
Wave 1: frontend, backend, database (all independent)
Wave 2: integration tests (depends on Wave 1)
Wave 3: QA validation (depends on Wave 2)

Don't starve your agents. If you find yourself waiting for one agent to finish before starting another, you're probably not using Fulcrum correctly. Check if the dependency is real or just habit from human team management.

Agent Specialization

Each agent has deep context about their domain. This isn't just a prompt prefix—it's a complete worldview that affects how they interpret requirements and make decisions:

@frontend thinks in components, accessibility, and user experience
@backend thinks in APIs, data flows, and system boundaries
@database thinks in schemas, indices, and query patterns
@devops thinks in pipelines, infrastructure, and observability
@qa-* agents think adversarially—finding edge cases and failure modes

Next Steps

Now that you understand how agents work together, learn how to encode reusable workflows in the Skills System.