Coordination

Agent coordination is the problem of getting multiple agents to work together without stepping on each other or requiring a central orchestrator to manage every interaction. Omnigraph solves this by making the graph itself the coordination surface.

The coordination loop

Every coordinated agent system follows the same loop:

1. Read -- An agent queries the graph to understand the current state.
2. Act -- The agent does work (calls an API, runs a model, makes a decision).
3. Write -- The agent writes results back to the graph on a branch.
4. Review or continue -- Other agents or humans discover the new state by reading the graph, a branch, or commit history.

The graph is the shared memory. Branches provide isolation. Queries define what each agent sees. Commits and snapshots make the work inspectable without inventing a second state system.

Reading: scoped queries as contracts

Each agent reads the graph through a query. The query is a contract -- it defines exactly what the agent sees and what shape the data takes.

query pending_reviews() {
    match {
        $t: Ticket { status: "pending" }
        $t assignedTo $a: Agent
        not {
            $t hasReview $r
        }
    }
    return { $t.slug, $t.title, $a.name }
}

This agent sees only tickets that are pending and unreviewed. It doesn't need to know about the rest of the graph.

Writing: branches as isolation

When an agent writes to the graph, it does so on a branch. The branch isolates the agent's changes from other agents until the changes are ready to merge.

omnigraph branch create --uri ./repo.omni --from main review-agent-run-17
# Agent writes reviews on the branch
omnigraph branch merge --uri ./repo.omni review-agent-run-17 --into main

Two agents can work on the same graph concurrently without conflicts. Each works on its own branch. Changes are merged when ready.

Reacting: query-driven work discovery

Current Omnigraph releases do not expose a built-in hook system. The coordination pattern is instead:

1. Store work state in the graph.
2. Define a query that identifies the next unit of work.
3. Have an agent, scheduler, or human runner execute that query and act on the result.

That still gives you explicit, reviewable coordination without a separate queue format.

Coordinating multiple agents

A typical multi-agent system on Omnigraph:

Each agent has a clear scope. They coordinate through the graph state, not through direct messages to each other.

Good fits for graph-based coordination

• Pipeline agents -- Each stage reads the output of the previous stage via graph queries.
• Monitoring agents -- Watch for conditions (gap detection, threshold breaches) via scheduled queries.
• Enrichment agents -- Read raw data, write enriched data back, trigger downstream agents.
• Review agents -- Read unreviewed items, write reviews, and advance state for the next agent.

When you still want an orchestrator

Graph-based coordination works when agents can discover their work from the graph state. It does not replace an orchestrator when:

• Agents need to execute in a strict sequence with error handling and retries at each step.
• The workflow requires human approval gates that exist outside the graph.
• You need to fan out to hundreds of parallel agents with backpressure control.

In these cases, use an orchestrator for the workflow and Omnigraph for the shared state.