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. React -- Other agents are notified via hooks when relevant state changes.

The graph is the shared memory. Branches provide isolation. Hooks trigger reactions. No message bus, no queue, no orchestrator.

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 --from main review-agent-run-17
# Agent writes reviews on the branch
omnigraph branch merge 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: hooks on conditions

Hooks let agents react to changes in the graph without polling. A hook watches for a condition -- a graph change or a query result -- and fires when that condition is met.

A graph-change hook fires when specific entities are created, updated, or deleted:

{
  "trigger": "on_create",
  "node_type": "Ticket",
  "filter": { "priority": "critical" },
  "action": "notify_oncall_agent"
}

A query-result hook fires when the result of a query changes:

{
  "query": "pending_reviews",
  "condition": "result_count > 0",
  "action": "wake_review_agent"
}

The query-result hook is more powerful: it can watch for complex conditions across multiple entity types and relationships.

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 query-result hooks.
• Enrichment agents -- Read raw data, write enriched data back, trigger downstream agents.
• Review agents -- Watch for unreviewed items, write reviews, trigger action agents.

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.