Übersicht
Mit „Mehrere Agenten“ kann ein Modell Subagenten parallel starten und koordinieren und ihre Ergebnisse zu einer abschließenden Antwort zusammenführen. Das ist besonders effektiv für Anwendungen mit komplexen Aufgaben, die von parallel delegierter Arbeit profitieren, etwa bei der Erkundung einer Codebasis, der Dokumentation und der Implementierung.
„Mehrere Agenten“ ist als Betafunktion mit allen GPT-5.6-Modellen verfügbar. Prüfe die Modellseite, bevor du „Mehrere Agenten“ in deiner Anwendung aktivierst.
Wann du mehrere Agenten einsetzen solltest
Aufgaben lassen sich oft in unabhängige Teilaufgaben aufteilen, die ein einzelner Agent nacheinander bearbeiten würde, mehrere Agenten aber parallel erledigen können. Mit „Mehrere Agenten“ kann ein Hauptagent Aufgaben an mehrere Subagenten delegieren, die gleichzeitig daran arbeiten. Das kann mehrere Vorteile bieten:
- Parallele Ausführung. Unabhängige Recherche-, Analyse- oder Implementierungsaufgaben können gleichzeitig bearbeitet und dadurch schneller erledigt werden.
- Gezielter Kontext. Jeder Subagent erhält eine klar abgegrenzte Aufgabe und verwaltet seinen eigenen Kontext. Dadurch beeinflussen sich die Kontexte voneinander unabhängiger Arbeiten weniger, was die Leistung verbessert.
- Vom Modell gesteuerte Koordination. Der Hauptagent kann Subagenten erstellen, ihnen zusätzliche Informationen senden, auf Ergebnisse warten und daraus eine abschließende Antwort formulieren. Deine Anwendung muss dafür keine eigene Orchestrierung implementieren.
Die Orchestrierung mehrerer Agenten ist besonders nützlich, wenn sich eine Aufgabe in konkrete, unabhängige Arbeitsbereiche aufteilen lässt, zum Beispiel:
- Verschiedene Teile einer großen Codebasis erkunden
- Mehrere Vorschläge, Dokumente oder Hypothesen vergleichen
- Parallel in mehreren Quellen recherchieren
- Unabhängige Komponenten implementieren oder unabhängige Testsuiten schreiben
- Verschiedene mögliche Ursachen eines Fehlers parallel untersuchen
- Verschiedene Lösungsansätze für ein Problem gleichzeitig untersuchen
Beachte, dass zusätzliche Subagenten den Tokenverbrauch erhöhen können. Sie bieten möglicherweise weniger Vorteile bei Aufgaben, die auf einer einzigen, geordneten Abfolge von Denkschritten beruhen, häufige Schreibzugriffe auf einen gemeinsam genutzten, veränderlichen Zustand erfordern oder deren Dauer bereits überwiegend durch einen einzelnen langsamen externen Vorgang bestimmt wird.
| Nutze mehrere Agenten, wenn | Nutze vorzugsweise einen Agenten, wenn |
|---|---|
| Sich die Arbeit in unabhängige, klar abgegrenzte Aufgaben aufteilen lässt | Jeder Schritt direkt vom vorherigen abhängt |
| Getrennter Kontext gezielteres Arbeiten ermöglicht | Die Aufgabe klein genug ist, um sie in einem kurzen Durchlauf zu erledigen |
| Parallele Untersuchungen die Gesamtdauer verkürzen können | Agenten um dieselbe veränderliche Ressource konkurrieren würden |
| Der Vergleich unabhängiger Erkenntnisse eine umfassendere Untersuchung ermöglicht | Du einen festen, deterministischen Ausführungsgraphen benötigst |
Schnellstart
Die Python- und JavaScript-Beispiele verwenden das Responses SDK in der Betaversion.
Verwende für HTTP-Anfragen client.beta.responses und übergib responses_multi_agent=v1
im Argument betas. Bei direkten HTTP-Anfragen und WebSocket-Verbindungen übergibst du
OpenAI-Beta: responses_multi_agent=v1 in den Anfrage- oder Verbindungsheadern.
Die Schemas der Elemente können sich ändern, solange sich „Mehrere Agenten“ in der Betaphase befindet.
Aktiviere „Mehrere Agenten“ in deiner Responses API-Anfrage mit multi_agent.enabled. Wenn multi_agent.enabled auf true gesetzt ist, kann der Hauptagent einen Baum aus Subagenten erstellen. Die Subagenten nutzen das Modell und die verfügbaren Tools der Anfrage. Die Agenten koordinieren sich über grundlegende Aktionen zur Zusammenarbeit, etwa das Starten von Subagenten, den Nachrichtenaustausch und das Warten auf Ergebnisse (siehe So funktioniert die Zusammenarbeit mehrerer Agenten). Der Hauptagent ist dafür verantwortlich, die Antworten der Subagenten zusammenzuführen und die abschließende Antwort bereitzustellen.
from openai import OpenAI
client = OpenAI()
def review_pull_request(diff: str) -> str:
response = client.beta.responses.create(
model="gpt-5.6-sol",
input=(
"Review the pull-request diff below with three agents: one for "
"correctness, one for security, and one for missing tests. "
"Reconcile duplicate or conflicting findings, then return a "
"prioritized review with file and line references.\n\n"
f"<diff>\n{diff}\n</diff>"
),
multi_agent={
"enabled": True,
"max_concurrent_subagents": 3,
},
betas=["responses_multi_agent=v1"],
)
return "".join(
part.text
for item in response.output
if (
item.type == "message"
and item.agent is not None
and item.agent.agent_name == "/root"
and item.phase == "final_answer"
)
for part in item.content
if part.type == "output_text"
)max_concurrent_subagents legt fest, wie viele Subagenten im gesamten Agentenbaum höchstens gleichzeitig aktiv sein können. Dabei zählen alle Nachkommen mit: direkte Unteragenten, deren Unteragenten und alle weiteren Ebenen. Der Hauptagent wird nicht mitgezählt.
Die API gibt für diese Einstellung keine feste Obergrenze vor. Der Standardwert ist 3 und wird für die meisten Arbeitslasten empfohlen. Auch für die Baumtiefe und die Gesamtzahl der während eines Durchlaufs erstellten Subagenten gibt es bei Durchläufen mit mehreren Agenten keine feste Grenze.
Füge eine Entwicklermeldung hinzu, um genauer zu steuern, wann das Hauptmodell Subagenten starten soll. Diese Entwicklermeldung ergänzt die Anweisungen, die für den Hauptagenten und die Subagenten eingefügt werden.
Beispiele für Entwicklermeldungen:
- „Starte nur dann Subagenten, wenn die nutzende Person ausdrücklich um Subagenten, Delegation oder parallele Arbeit durch Agenten bittet.“
- „Proaktive Delegation an mehrere Agenten ist aktiv. Nutze Subagenten, wenn parallele Arbeit die Geschwindigkeit oder Qualität wesentlich verbessern würde.“
So funktioniert die Zusammenarbeit mehrerer Agenten
Die Responses API stellt den Modellen des Hauptagenten und der Subagenten gehostete Orchestrierungsaktionen sowie Anweisungen zu deren Nutzung bereit. Der Hauptagent heißt /root. Gestartete Subagenten verwenden hierarchische Pfade wie:
/root
├── /root/researcher
├── /root/reviewer
└── /root/reviewer/tester
„Mehrere Agenten“ legt keine feste Grenze für die Gesamtzahl der Subagenten oder die Baumtiefe fest. Verwende für die meisten Aufgaben den Standardwert 3 für max_concurrent_subagents. Diese Einstellung begrenzt die Anzahl der aktiven Subagenten-Turns im gesamten Baum, einschließlich direkter Unteragenten und aller weiteren Nachkommen.
Wenn der Modus „Mehrere Agenten“ aktiviert ist, stellt die Responses API sechs gehostete Aktionen zur Zusammenarbeit bereit. Diese können als Elemente vom Typ multi_agent_call erscheinen. Deine Anwendung sollte sie weder ausführen noch Ausgaben dafür übermitteln.
| Aktion | Zweck |
|---|---|
spawn_agent | Einen Subagenten erstellen und ihm seine erste Aufgabe zuweisen. |
send_message | Eine Nachricht für einen bestehenden Agenten in die Warteschlange stellen, ohne einen neuen Turn zu starten. |
followup_task | Einem bestehenden Agenten, der nicht der Hauptagent ist, weitere Arbeit zuweisen und seinen Turn starten oder fortsetzen. |
wait_agent | Auf eine Aktualisierung im Postfach des aufrufenden Agenten warten. |
interrupt_agent | Den aktiven Turn eines anderen Agenten unterbrechen, ohne dessen Kontext zu löschen. |
list_agents | Den aktuellen Agentenbaum, die Statusangaben und last_task_message jedes Agenten zurückgeben. |
Die Verarbeitung selbst definierter Tool-Aufrufe funktioniert genauso wie ohne aktivierte Funktion „Mehrere Agenten“. Jeder Agent im Baum kann einen function_call ausgeben. Deine Anwendung muss den Aufruf ausführen und eine passende Ausgabe vom Typ function_call_output übermitteln.
Beachte, dass alle Agenten im Baum Zugriff auf die Tools haben, die im Modellaufruf der API-Anfrage konfiguriert sind.
Mehrere Agenten in der Responses API verwenden
Leistungsvergleich von HTTP und WebSocket
HTTP und WebSocket unterstützen dieselben Funktionen für mehrere Agenten. Für Arbeitsabläufe mit vielen Tool-Aufrufen oder langer Laufzeit wird jedoch WebSocket empfohlen. Über die dauerhafte Verbindung kann deine Anwendung Funktionsausgaben zurückgeben, sobald sie vorliegen. Das reduziert den zusätzlichen Aufwand für die Fortsetzung und verkürzt die Wartezeiten der Agenten.
Bei HTTP wird die Antwort abgeschlossen, sobald jeder aktive Agent entweder fertig ist oder pausiert, um auf einen vom Client ausgeführten Funktionsaufruf zu warten. Deine Anwendung führt dann alle ausstehenden Funktionsaufrufe aus und übermittelt deren Ausgaben in einer neuen Responses API-Anfrage. Dadurch können die pausierten Agenten ihre Arbeit fortsetzen.
Mit WebSocket kann deine Anwendung jede Funktionsausgabe in die Antwort einfügen, sobald sie vorliegt, ohne auf den Abschluss der aktiven Antwort zu warten. Der wartende Agent kann sofort fortfahren, während andere Agenten weiterarbeiten. Das verringert Verzögerungen bei der Koordination und vermeidet zusätzliche Anfrage-Antwort-Zyklen, wenn Agenten zu unterschiedlichen Zeitpunkten fertig werden oder Tools anfordern.
HTTP kann für Arbeitsabläufe ausreichen, die mehrere gehostete Tools aufrufen, etwa für parallele Websuchen, oder die mit einer einzigen Anfrage und wenigen Funktionsaufrufen auskommen. Für die meisten Arbeitsabläufe mit mehreren Agenten dürfte WebSocket eine geringere Latenz und eine bessere Gesamtleistung bieten.
Ausführung von Funktionsaufrufen über HTTP

Ausführung von Funktionsaufrufen über WebSocket

HTTP
Diese Beispiele erfordern Beta-Versionen der SDKs, die Zugriff auf die Beta-Version der Responses API bieten. Rufe für HTTP-Streaming client.beta.responses.create auf und übergib responses_multi_agent=v1 mit dem Argument betas. Dadurch werden Beta-Typen und die Autovervollständigung aktiviert. Importiere in Python die Typen für Beta-Antwortelemente aus openai.types.beta, wenn du Typannotationen hinzufügst.
Beispiel für clientseitigen Code:
from __future__ import annotations
import json
import sys
from openai import OpenAI
from openai.types.beta import BetaResponseOutputItem
client = OpenAI()
ROOT = "/root"
PROPOSALS = {
"alpha": {"estimated_weeks": 6, "risk": "medium"},
"beta": {"estimated_weeks": 8, "risk": "low"},
}
tools = [
{
"type": "function",
"name": "get_proposal",
"description": "Return details for a proposal that the agents should compare.",
"parameters": {
"type": "object",
"properties": {
"proposal": {
"type": "string",
"enum": ["alpha", "beta"],
}
},
"required": ["proposal"],
"additionalProperties": False,
},
"strict": True,
}
]
history = [
{
"role": "user",
"content": "Compare proposal alpha and proposal beta.",
}
]
def agent_name(item: BetaResponseOutputItem) -> str:
return item.agent.agent_name if item.agent else ROOT
def render_to_user(delta: str) -> None:
print(delta, end="", flush=True)
def log_subagent_text(agent: str, delta: str) -> None:
print(f"[{agent}] {delta}", end="", file=sys.stderr, flush=True)
def process_tool_call(name: str, arguments: str) -> str:
if name != "get_proposal":
raise ValueError(f"Unknown tool: {name}")
parsed_arguments = json.loads(arguments)
return json.dumps(PROPOSALS[parsed_arguments["proposal"]])
while True:
output_items = []
pending_calls = []
item_agents: dict[int, str] = {}
stream = client.beta.responses.create(
model="gpt-5.6-sol",
input=history,
tools=tools,
store=False,
multi_agent={
"enabled": True,
"max_concurrent_subagents": 3,
},
stream=True,
betas=["responses_multi_agent=v1"],
)
for event in stream:
if event.type == "response.output_item.added":
item_agents[event.output_index] = agent_name(event.item)
elif event.type == "response.output_text.delta":
agent = item_agents.get(event.output_index, ROOT)
if agent == ROOT:
render_to_user(event.delta)
else:
log_subagent_text(agent, event.delta)
elif event.type == "response.output_item.done":
output_items.append(event.item)
if event.item.type == "function_call":
# Handle function calls from both the root agent and subagents.
pending_calls.append(event.item)
elif event.type == "response.completed":
print(f"\nUsage: {event.response.usage}", file=sys.stderr)
break
elif event.type in {
"error",
"response.failed",
"response.incomplete",
}:
raise RuntimeError(event)
history.extend(output_items)
for call in pending_calls:
history.append(
{
"type": "function_call_output",
"call_id": call.call_id,
"output": process_tool_call(call.name, call.arguments),
}
)
if not pending_calls:
breakWenn ein oder mehrere Agenten selbst definierte Funktionen aufrufen, führe alle ausstehenden Aufrufe aus und erstelle eine Fortsetzungsanfrage mit ihren Ausgaben.
WebSocket
Wenn ein Agent im WebSocket-Modus eine selbst definierte Funktion aufruft, führe diese in deiner Anwendung aus und sende ihr Ergebnis mit einem response.inject-Ereignis an die aktive Antwort. Der wartende Agent kann dann fortfahren, ohne auf den Abschluss der gesamten Antwort mit mehreren Agenten warten zu müssen.
{
"type": "response.inject",
"response_id": "resp_123",
"input": [
{
"type": "function_call_output",
"call_id": "call_123",
"output": "{\"temperature\":72}"
}
]
}
Auf eine gültige response.inject-Anfrage antwortet der Server mit einem von zwei Ereignissen:
response.inject.created: Die Eingabe wurde validiert und zum Einfügen angenommen.response.inject.failed: Die Eingabe wurde nicht eingefügt. Prüfeerror.code.
{
"type": "response.inject.created",
"sequence_number": 42,
"response_id": "resp_123"
}
{
"type": "response.inject.failed",
"sequence_number": 43,
"response_id": "resp_123",
"input": [
{
"type": "function_call_output",
"call_id": "call_123",
"output": "{\"temperature\":72}"
}
],
"error": {
"code": "response_already_completed",
"message": "Response 'resp_123' has already completed."
}
}
Wenn eine Anfrage nicht dem Schema von response.inject entspricht, sendet der Server einen allgemeinen Fehler mit dem Status 400 und schließt die WebSocket-Verbindung. Korrigiere die Anfrage und öffne eine neue WebSocket-Verbindung, bevor du ein weiteres Ereignis sendest.
Das Python-Beta-SDK stellt den WebSocket-Modus über client.beta.responses.connect bereit, das TypeScript-Beta-SDK über ResponsesWS. Übergib OpenAI-Beta: responses_multi_agent=v1 in den Verbindungsheadern. Anders als beim HTTP-Streaming akzeptieren die WebSocket-Konnektoren das Argument betas noch nicht.
Speichere die Antwort-ID aus dem response.created-Ereignis und füge sie jedem response.inject-Ereignis hinzu, das du für diese Antwort sendest. Nachdem du ein Element zum Einfügen gesendet hast, lies weiter aus der WebSocket-Verbindung, bis die Antwort abgeschlossen ist und jeder Einfügevorgang entweder ein response.inject.created- oder ein response.inject.failed-Ereignis ausgelöst hat.
from __future__ import annotations
import json
from openai import OpenAI
client = OpenAI()
PROPOSALS = {
"alpha": {"estimated_weeks": 6, "risk": "medium"},
"beta": {"estimated_weeks": 8, "risk": "low"},
}
tools = [
{
"type": "function",
"name": "get_proposal",
"description": "Return details for a proposal that the agents should compare.",
"parameters": {
"type": "object",
"properties": {
"proposal": {
"type": "string",
"enum": ["alpha", "beta"],
}
},
"required": ["proposal"],
"additionalProperties": False,
},
"strict": True,
}
]
def process_tool_call(name: str, arguments: str) -> str:
if name != "get_proposal":
raise ValueError(f"Unknown tool: {name}")
parsed_arguments = json.loads(arguments)
return json.dumps(PROPOSALS[parsed_arguments["proposal"]])
def run_multi_agent(connection):
previous_response_id: str | None = None
pending_input: list[dict[str, object]] = [{"role": "user", "content": input()}]
while pending_input:
request = {
"type": "response.create",
"model": "gpt-5.6-sol",
"store": True,
"multi_agent": {"enabled": True},
"tools": tools,
"input": pending_input,
}
if previous_response_id is not None:
request["previous_response_id"] = previous_response_id
connection.send(request)
next_input: list[dict[str, object]] = []
completed_response = None
response_id: str | None = None
pending_injections = 0
for event in connection:
event_type = event.type
if event_type == "response.created":
response_id = event.response.id
elif event_type == "response.output_item.done":
item = event.item
if item.type == "function_call":
if response_id is None:
raise RuntimeError(
"Received a function call before response.created"
)
output = {
"type": "function_call_output",
"call_id": item.call_id,
"output": process_tool_call(item.name, item.arguments),
}
pending_injections += 1
connection.send(
{
"type": "response.inject",
"response_id": response_id,
"input": [output],
}
)
elif event_type == "response.inject.created":
pending_injections -= 1
elif event_type == "response.inject.failed":
pending_injections -= 1
if event.error.code != "response_already_completed":
raise RuntimeError(event.error)
next_input.extend(item.model_dump(mode="json") for item in event.input)
elif event_type == "response.completed":
completed_response = event.response
elif event_type in {
"error",
"response.failed",
"response.incomplete",
}:
raise RuntimeError(event)
if completed_response is not None and pending_injections == 0:
break
if completed_response is None:
raise RuntimeError("Connection ended before response.completed")
if not next_input:
return completed_response
previous_response_id = completed_response.id
pending_input = next_input
with client.beta.responses.connect(
extra_headers={"OpenAI-Beta": "responses_multi_agent=v1"},
) as connection:
run_multi_agent(connection)Lies nach dem Senden eines response.inject-Ereignisses weiter aus der WebSocket-Verbindung und verarbeite die Bestätigung:
response.inject.created: Die Funktionsausgabe wurde zur aktiven Antwort hinzugefügt. Lies weiterhin Ereignisse für diese Antwort.response.inject.failedmitresponse_already_completed: Die Antwort wurde abgeschlossen, bevor die Funktionsausgabe hinzugefügt werden konnte. Übernimm den im Fehlerereignis zurückgegebenen Wert voninputund sende ihn in einer neuenresponse.create-Anfrage, die an die abgeschlossene Antwort anknüpft.response.inject.failedmitresponse_not_found: Der Server konnte die durchresponse_ididentifizierte Antwort nicht finden. Prüfe, ob du die ID verwendest, die du mitresponse.createderhalten hast.
Ein einzelner Durchlauf mit mehreren Agenten kann sich über mehrere Anfragen an die Responses API erstrecken. Wenn ein Agent über HTTP eine selbst definierte Funktion aufruft, führt deine Anwendung diese aus und übermittelt ihre Ausgabe in einem neuen response.create-Aufruf. Über WebSocket fügt deine Anwendung die Funktionsausgabe stattdessen in die aktive Antwort ein.
Neue Ausgabeelemente für mehrere Agenten
Antworten mit mehreren Agenten können drei zusätzliche Typen von Ausgabeelementen enthalten:
multi_agent_call: protokolliert eine gehostete Aktion für mehrere Agenten, etwaspawn_agent.multi_agent_call_output: enthält das Ergebnis der Ausführung einer gehosteten Aktion.agent_message: übermittelt eine verschlüsselte Nachricht von einem Agenten an einen anderen.
Das Feld call_id verknüpft jedes multi_agent_call-Element mit dem zugehörigen multi_agent_call_output-Element.
Jedes Element enthält außerdem ein agent-Attribut. Bei einem agent_message-Element identifiziert agent.agent_name den empfangenden Agenten. Mit author und recipient kannst du die Richtung der Nachricht nachvollziehen.
Wenn deine Anwendung ein multi_agent_call-Element empfängt, führe es nicht als Funktionsaufruf aus und sende kein Ergebnis zurück. Die Responses API führt die gehostete Aktion aus und gibt das zugehörige multi_agent_call_output-Element zurück. Bewahre beide Elemente auf, wenn deine Anwendung sie für die erneute Wiedergabe oder das Tracing benötigt.
[
{
"type": "multi_agent_call",
"id": "mac_123",
"call_id": "call_spawn_a",
"action": "spawn_agent",
"arguments": "{\"task_name\":\"agent_a\",\"fork_turns\":\"all\",\"message\":\"enc_...\"}",
"agent": { "agent_name": "/root" }
},
{
"type": "multi_agent_call_output",
"id": "maco_123",
"call_id": "call_spawn_a",
"action": "spawn_agent",
"output": [
{
"type": "output_text",
"text": "{\"task_name\":\"/root/agent_a\"}",
"annotations": [],
"logprobs": []
}
],
"agent": { "agent_name": "/root" }
},
{
"type": "agent_message",
"id": "amsg_123",
"author": "/root/agent_a",
"recipient": "/root",
"content": [
{
"type": "encrypted_content",
"encrypted_content": "enc_..."
}
],
"agent": { "agent_name": "/root" }
}
]
SSE-Ereignisse, die einem Agenten zugeordnet sind, enthalten auf oberster Ebene ein agent-Attribut. Bei einem agent_message-Ereignis identifiziert agent.agent_name den empfangenden Agenten. Ereignisse im Lebenszyklus einer Antwort wie response.created und response.completed beschreiben die gesamte Antwort und keinen einzelnen Agenten. Deshalb enthalten sie kein agent-Attribut.
{
"type": "response.output_item.done",
"agent": { "agent_name": "/root" },
"item": {
"type": "agent_message",
"id": "amsg_123",
"author": "/root/agent_a",
"recipient": "/root",
"content": [
{
"type": "encrypted_content",
"encrypted_content": "enc_..."
}
],
"agent": { "agent_name": "/root" }
}
}
Einschränkungen
- Compaction (Kontextverdichtung):
- Der Endpunkt
/responses/compactwird nicht unterstützt, wenn „Mehrere Agenten“ aktiviert ist. - Wenn
multi_agent.enabledauftruegesetzt ist, wird die automatische serverseitige Compaction (Kontextverdichtung) implizit aktiviert, auch wenn die Anfragecontext_managementnicht konfiguriert. Die Compaction (Kontextverdichtung) wird unabhängig auf den Hauptagenten und jeden Subagenten angewendet. Ihre getrennten Kontexte bleiben dabei erhalten. Du kannstcompact_thresholdweiterhin überschreiben, indem ducontext_management.compact_thresholdexplizit in der Anfrage festlegst.
- Der Endpunkt
reasoning.summarywird nicht unterstützt, wenn „Mehrere Agenten“ aktiviert ist.max_tool_callswird nicht unterstützt, wenn „Mehrere Agenten“ aktiviert ist.max_concurrent_subagentshat standardmäßig den Wert3. Das ist die empfohlene Einstellung.
Hinweise zu Prompts
Wenn „Mehrere Agenten“ aktiviert ist, fügen unsere Systeme diese Anweisungen automatisch als neue Entwicklermeldung für den Hauptagenten und die Subagenten hinzu. Du kannst diese Anweisungen weder bearbeiten noch entfernen. Formuliere deine eigenen Entwickleranweisungen als Ergänzung zu diesen automatisch eingefügten Anweisungen.
Hauptagent
You are `/root`, the primary agent in a team of agents collaborating to fulfill the user's goals.
At the start of your turn, you are the active agent.
You can spawn sub-agents to handle subtasks, and those sub-agents can spawn their own sub-agents.
All agents in the team, including the agents that you can assign tasks to, are equally intelligent and capable, and have access to the same set of tools.
You can use `spawn_agent` to create a new agent, `followup_task` to give an existing agent a new task and trigger a turn, and `send_message` to pass a message to a running agent without triggering a turn.
Child agents can also spawn their own sub-agents.
You can decide how much context you want to propagate to your sub-agents with the `fork_turns` parameter.
You will receive messages in the form:
```
Message Type: MESSAGE | FINAL_ANSWER
Task name: <recipient>
Sender: <author>
Payload:
<payload text>
```
They may be addressed as to=/root
There are {max_concurrent_subagents + 1} available concurrency slots, meaning that up to {max_concurrent_subagents + 1} agents can be active at once, including you.
Subagent
You are an agent in a team of agents collaborating to complete a task.
You can spawn sub-agents to handle subtasks, and those sub-agents can spawn their own sub-agents. All agents in the team, including the agents that you can assign tasks to, are equally intelligent and capable, and have access to the same set of tools.
You can use `spawn_agent` to create a new agent, `followup_task` to give an existing agent a new task and trigger a turn, and `send_message` to pass a message to a running agent.
Child agents can also spawn their own sub-agents.
When you provide a response in the final channel, that content is immediately delivered back to your parent agent.
You will receive messages in the form:
```
Message Type: NEW_TASK | MESSAGE | FINAL_ANSWER
Task name: <recipient>
Sender: <author>
Payload:
<payload text>
```
You may also see them addressed as to=/root/..., which indicates your identity is /root/...
There are {max_concurrent_subagents + 1} available concurrency slots, meaning that up to {max_concurrent_subagents + 1} agents can be active at once, including you.