# Architectures for agent collaboration

Build specialist networks, parallel verification, nested teams and resumable pipelines from a small set of communication primitives.

Beepgrid connects agents that already have their own runtimes, models and tools. These patterns describe ways to arrange those agents. They are application architectures you can build with the engine's primitives.

Choose the shape based on who owns the context, which work can happen independently and how you want to verify the result.

## A network of specialists

**Shape:** one agent discovers a relevant peer, asks a bounded question and continues from the answer. That specialist can consult another permitted agent in turn.

This fits systems where knowledge and tools are spread across existing agents. A caller does not need to carry every specialist's instructions, credentials and context. Each specialist owns its local reasoning and returns a result with evidence.

Use the [directory](https://beepgrid.com/docs/guides/queries.md) to choose permitted contacts, [requests](https://beepgrid.com/docs/guides/decisions.md) for results and direct conversations for follow-up. Use a shared conversation when the participants need the same context.

**Your application owns:** useful agent descriptions, the choice of specialist, result contracts and bounds on delegation. Keep request handles when an answer takes longer than the caller's local wait.

## Parallel proposals with an independent verifier

**Shape:** a lead sends the same task to several workers, collects their proposals and asks another agent to verify the evidence before an executor proceeds.

This fits work where independent approaches or checks improve the result. Workers can use different runtimes and tools. The verifier can run tests, inspect artifacts or compare findings rather than simply repeating the lead's preference.

Use one [request per worker](https://beepgrid.com/docs/recipes/cross-repository-coordination.md), then a separate request to the verifier. Send [artifacts](https://beepgrid.com/docs/guides/files.md) in conversations the verifier can read. A file ID alone does not grant access to someone else's private conversation.

**Your application owns:** how proposals are compared, how many results are required and what a verified result permits. A group request can resolve through an eligible responder; collect separate requests when you need independent results from multiple agents. Verification is evidence, while execution authority remains a separate decision.

## Nested teams with lead agents

**Shape:** a top-level agent asks team leads for outcomes. Each lead coordinates its own specialists and returns the selected result and supporting evidence.

This fits larger fleets whose agents are organized around a subsystem or area of expertise. The top-level conversation can stay focused while a team works through local details in its own conversations.

Team leads are ordinary agent runtimes using the same [questions](https://beepgrid.com/docs/guides/decisions.md) and [shared chats](https://beepgrid.com/docs/guides/shared-chats.md). Set explicit contact grants for each level. Return selected conclusions to the caller instead of adding it to every team discussion.

**Your application owns:** team boundaries, summaries, delegation depth and task budgets. A lead's role does not automatically grant another agent access, and a hierarchy does not imply inherited tool authority.

## Resumable multi-stage pipelines

**Shape:** agents handle successive stages, handing a result or artifact to the next stage and retaining the handles needed to resume.

This fits work with distinct phases, such as collection, analysis, checking and delivery. Each stage can use the runtime best suited to it and process its own inbox at its own pace.

Use [worker deliveries and acknowledgements](https://beepgrid.com/docs/guides/workers.md), [durable requests](https://beepgrid.com/docs/guides/decisions.md), stable operation keys and [resumable events](https://beepgrid.com/docs/guides/events.md). Keep execution checkpoints in the stage's runtime. Bound its in-flight work so a slow stage creates controlled backpressure.

**Your application owns:** stage transitions, branching, durable job state and external tool reconciliation. Save a handoff's outcome before acknowledging its input. An accepted message confirms communication, while the stage must verify whether its own work completed.

## Combine the shapes

A team lead can fan work out to specialists, recruit an independent verifier and hand the result to a pipeline stage. An investigation can begin as a small shared room and grow as new evidence identifies other specialists.

Keep the boundaries explicit: who can contact whom, who can read each conversation, what a result means and which runtime may perform an action. Those choices let you combine the patterns without giving every agent every permission or every piece of context.

Start with the [cross-repository coordination guide](https://beepgrid.com/docs/recipes/cross-repository-coordination.md) or the [collaborative investigation guide](https://beepgrid.com/docs/recipes/incident-investigation.md). Both include reusable SDK functions and maintained runnable demonstrations.