Multi-Agent Orchestration

Complex tasks benefit from specialization. Tribunus Desktop supports multi-agent orchestration where a coordinating agent — running in the Electron main process — delegates subtasks to worker agents, each configured with its own model backend, tool set, and system prompt. Communication flows through the Agent Communication Protocol (ACP), a JSON-encoded wire format with schema-versioned envelopes for routing, payload, and capabilities negotiation.

Agent Topologies

Desktop supports three orchestration topologies:

• Star — a single orchestrator delegates to N workers and aggregates results. The most common pattern for parallelizable tasks such as multi-file code review or batch analysis. Each worker agent runs in its own event-sourced session, isolated from the others.
• Pipeline — agents are arranged in sequence; each agent’s output becomes the next agent’s input. Used for staged transformations: investigation agent discovers relevant context, writer agent produces a change, review agent validates the result.
• Swarm — agents discover each other dynamically through a shared registry and negotiate task assignments without a fixed orchestrator. Suitable for long-running background workflows where agents join and leave over time.

Context Isolation and Security

Each agent in a multi-agent configuration operates in its own context — system prompt, conversation history, tool registry, and session state. Cross-agent data sharing is explicit: a worker only sees the information the orchestrator includes in the delegation message. The secure IPC bridge in the Electron preload layer enforces process boundaries between agent runtimes, preventing one agent from reading another’s memory or tool outputs without authorization.

Practical Use Cases

Reviewer + Writer Pair. A writer agent generates code changes based on a feature description. It hands the diff to a reviewer agent configured with stricter tools (linter, security analyzer, dependency checker) and a lower model temperature for deterministic analysis. The reviewer returns issues; the writer revises. This loop continues until the reviewer approves or the iteration budget is exhausted.

Investigation + Execution Split. An investigation agent reads project files, scans for relevant patterns, and builds a context summary. It passes the summary to an execution agent that applies changes. The execution agent has file-system write tools; the investigation agent does not — reducing the risk of unintended modifications.

Parallel Batch Processing. A research agent spawns N worker agents, each analyzing a different codebase module. Workers stream intermediate findings back via ACP. The orchestrator merges results and produces a consolidated report. This pattern leverages Desktop’s event-sourced sessions: each worker can be resumed independently if it hits a timeout or error.

Coordination via ACP

ACP messages carry routing metadata, a correlation ID for tracing across agents, and a payload schema version. Desktop includes an ACP inspector panel that visualizes the message flow between agents, making it possible to debug coordination issues or identify bottlenecks. Retry policies — max attempts, backoff intervals, fallback agents — are configurable in the orchestrator’s agent definition.