How OMA works.
Two diagrams, one system. The architecture is the structure — what OMA is. The
flow is time — what happens when you call runTeam(). Same visual language,
translated from the brand system.
The architecture.
Five layers, top to bottom: the orchestrator you call, the team it coordinates, the pool and queue that schedule the work, the agent that does it, and the adapter, runner, and tool interfaces underneath. Every box maps one-to-one to a type in the framework.
- accent borderUser entry point — the class you instantiate. Exactly one per diagram.
- solidConcrete type — a class with one implementation: Team, AgentPool, TaskQueue, Agent, AgentRunner.
- dashedInterface with multiple implementations — LLMAdapter providers, ToolRegistry tools.
- arrowOwns / contains — the source instantiates or owns the target. Read top-down.
One runTeam() call.
Goal in, result out. The coordinator decomposes the goal into a task DAG, fans the agents out in parallel, carries intermediate results over the MessageBus, and synthesizes the final answer. Read it left to right — the horizontal axis is time.
- vertical = which agentEach agent gets its own horizontal track, like a voice in a music score.
- horizontal = whenTracks aligned at the same x run at the same logical time; a track that ends earlier finished first.
- reviewer waitsThe reviewer is offset right — a TaskQueue dependency on the architect and the two developers.
- message busThe dashed-emerald band is the channel any agent can publish to and subscribe from during execution.