Skip to main content
Version: v6.0.0 [Falcon]

Supervisor Blueprint โ€” Agents Catalog

Agents that hold the conversation with the user in front of the other blueprints' agents. A supervisor takes one request, hands each part to the specialist that covers it, and writes one answer from what they return. It owns no domain knowledge of its own: what it can do is what its specialists can do. Every agent is an A2A server built with BAT-ADK: point a UI at it, and give it the specialists it may call.

Both supervisors are modes of one CompositionModel, supervisor: in an AIFabric, reference each one as model: supervisor/<mode>. Give it role: supervisor, and it calls every agent with role: worker; to give it more agents, list them under its dependencies. The blueprint is included in MX-PDK O-RAN, AI-RAN and CAMPUS. The catalog overview explains these terms and how to install a blueprint. The supervisors have no credentials and never call Kubernetes: they only talk to other agents over A2A.

Agentsโ€‹

Supervisor โ€” Orchestration of specialist agentsโ€‹

model: supervisor/base ยท role: supervisor

Answers a request by delegating it to specialist agents, for example the Network Operations Agent of the Automation blueprint or the agents of the Observability blueprint. At startup it reads the A2A card of every agent it is given, and each reachable one becomes a tool described by its card. There are no built-in routes: adding a specialist only means adding it to the fabric as a worker. Cards are read once, at startup: after you add or remove an agent, remove the fabric and install it again.

One model chooses the next agent, reads its result and decides what to do next, with no fixed plan. It calls several different agents at once only when their calls are independent, and puts everything it needs from one agent in a single message. It never answers a task from its own knowledge: until a specialist has reported, it either delegates or says that no available agent covers the request. Greetings, questions about what the supervisor can do and questions about the previous request are answered directly, without calling any agent.

  • Human input: when an agent asks a question, such as a confirmation before a deploy, the supervisor shows it word for word and sends the user's next message, unchanged, to that agent. It never approves an operation on the user's behalf. When several agents ask at once, their questions come one per turn;
  • Conversations: each agent keeps its own context for each supervisor conversation, so a job that takes several turns with one agent stays coherent. Different conversations run at the same time. Conversations are kept in memory and do not survive a restart;
  • Limits: at most eight decisions per turn, never the same call twice in a turn, and no automatic retry of a call that may have written. When it stops on a limit or an error, the answer includes the results already obtained.

Supervisor with actions โ€” Orchestration with UI shortcutsโ€‹

model: supervisor/with-actions ยท role: supervisor

The same supervisor for the Playground, BubbleRAN's online chatbot. For now it is available only there; MX-PDK will support it soon. Under each answer it adds a few shortcuts that open what the answer is about: a network's topology, the logs of one element, or the networks, terminals, services, cluster overview or alerts pages. A model picks the shortcuts; code drops every name that no agent returned in that turn, and builds the routes itself. The shortcuts come as a JSON code block at the end of the text reply. A turn where no agent answered has no shortcuts.

Evaluation Resultsโ€‹

The supervisor has no evaluation of its own. The Observability catalog scores supervisor/base in front of the nine Observability agents.