A 3-tier agent topology backed by a real-time database where agents react to state changes via subscriptions instead of polling — enabling responsive, observable multi-agent orchestration.

The Pattern

Three tiers with strict communication boundaries:

User --> Controller --> Orchestrator --> Worker A
                                    --> Worker B
                                    --> Worker C

Controller is the single entry point. It receives user intent, validates it, and creates an orchestrator record in the database. One controller per user session.

Orchestrator decomposes work into atomic tasks, spawns workers, and monitors their progress through database subscriptions. It doesn't do work — it manages work.

Workers execute atomic tasks and report results by writing to the database. Workers never communicate with each other directly. All coordination flows through the orchestrator.

The real-time database (Convex, Supabase Realtime, Firebase, etc.) is the communication backbone. Every state change — task created, progress updated, result submitted, blocker raised — is a database mutation that triggers reactive updates.

Communication contracts are typed and finite:

• Handoff: "Here's a task with these inputs"
• Progress: "I'm X% done, here's intermediate state"
• Blocker: "I can't continue because of Y"
• Question: "I need clarification on Z"
• Heartbeat: "I'm still alive and working"
• Result: "Here's my output"

Key Decisions

Bounded topology. Controllers spawn orchestrators. Orchestrators spawn workers. Workers spawn nothing. No peer-to-peer communication, no worker-to-worker coordination. This makes the system debuggable — you can trace any state change through exactly two hops.

Database as message bus. Using the database for agent communication (instead of a separate message queue) means your debugging tools, your monitoring, and your communication layer are all the same system. Query the database to understand what every agent is doing and has done.

Subscriptions over polling. Agents react to state changes in real-time instead of checking every N seconds. This eliminates the latency-vs-cost tradeoff of polling intervals and makes the system feel responsive.

Scale workers, not orchestrators. When work takes too long, add more workers. Don't make the orchestrator smarter — keep it as a simple dispatcher. Orchestrator complexity is the most common scaling bottleneck in multi-agent systems.

When to Use It

Multi-step workflows where you need observability (dashboards showing agent progress), recoverability (resume from last known state after crashes), and scalability (add workers without redesigning the architecture). Particularly strong when you already have a real-time database in your stack and want to avoid adding a separate orchestration layer.