When One Agent Is Not Enough: Groups and Orchestration

A LobeHub Agent can search, reason, and act alone, but some work is difficult precisely because it needs different perspectives or more than one sustained line of effort. This chapter examines how LobeHub turns several persistent Agents into a Group, how a supervisor chooses between shared discussion and isolated execution, and why context must be relabeled before one Agent reads another’s work. The practical judgment is simple: add Agents when their responsibilities are genuinely different, not merely because parallel model calls sound more powerful.

The distinction matters because a Group is not just a longer prompt containing several personalities. It is a persisted roster, a role system, a coordination policy, and a set of operations that may share a conversation or run apart from it. The same Agent operation model still applies—context, decision, action, state, and control—but a Group adds another question: who is speaking, who is responsible for the next move, and what should each participant be allowed to see?

A Group is a role and context boundary

LobeHub stores a Group as a chat container connected to a roster of Agents. Each membership record can carry an enabled state, an order, and a role such as supervisor or participant. The supervisor is the coordinating Agent for the Group; participants contribute specialized responses or execute assigned work. This creates a division that a loose collection of chat windows would not provide. The supervisor can decide which capability or person is relevant, while each participant remains a persistent Agent with its own model, prompt, tools, and configuration.

There is also a lifecycle distinction between an Agent created for the Group and an existing Agent invited into it. Group membership logic classifies these as owned or referenced. A Group-created virtual Agent belongs to the Group’s lifecycle and can travel with it or disappear when it is removed. A standalone Agent linked into a Group remains independently owned; removing the link should not delete the Agent, and moving the Group should not silently move that Agent into a different scope. This distinction is easy to overlook in the interface, but it protects the meaning of persistence. A Group may use an Agent without owning the Agent’s whole life.

Every participant needs an explicit identity inside the Group. LobeHub injects the current Agent’s name, role, internal identifier, Group title, purpose, and member list into the context. The identifier helps the runtime correlate messages, but the Group instructions say it must not be exposed to users; names are the human-facing identity. That separation allows the system to maintain precise routing without asking the model to communicate in database keys.

The context engine then solves a harder problem: how can one model read peer output without confusing the peer with itself? Messages from the current Agent remain assistant messages, because they are the current model’s own conversational history. Messages from other Agents are transformed into user messages with a speaker marker. Peer tool results are also represented as user-side tool-result content rather than as the current Agent’s own tool execution. From the model’s perspective, another Agent’s output is therefore external input to evaluate, not a role it should imitate.

This transformation is a form of provenance preservation.