Oracle’s new Select AI supervisor is a router—not a parallel multi-agent runtime

Oracle has added supervisor-led agent teams to Select AI on Autonomous AI Database Dedicated Exadata Infrastructure. The useful part is not simply that one agent can call others. It is that Oracle now distinguishes two orchestration contracts: a fixed sequential workflow and a supervisor that chooses the next worker at runtime.

What the supervisor actually does

A supervised team has exactly one supervisor agent and one or more worker agent-task pairs. The supervisor receives the user request, decides whether it needs a worker, creates a self-contained subtask, waits for the result and then chooses what to do next. It can call another worker, ask for more information, handle a worker failure or produce the final response.

That makes the feature appropriate for requests whose route depends on intent or intermediate results—for example, selecting a data-source specialist and then combining its output with another worker’s result. Oracle’s documentation says the worker list defines the available delegation targets, not a predetermined execution plan.

The hard boundary: one worker at a time

The term “agent team” can imply parallel execution. This release does not provide it. Worker subtasks run sequentially, and the supervisor waits for each result before delegating the next one. A supervisor also cannot delegate to another supervisor-led team, so nested orchestration is not supported in this version.

That limitation matters for architecture and latency planning. Independent lookups cannot fan out concurrently inside this pattern. Teams that need parallel retrieval still require orchestration outside this Select AI supervisor contract or a different execution design.

Context does not flow automatically

Each worker runs in a separate conversation thread and does not inherit the supervisor’s full context. The supervisor must package every delegated request with enough information for that worker to finish its bounded task. The worker returns only its final result, which the supervisor adds to its own context.

This is a useful isolation boundary, but it moves correctness into task design. Oracle’s troubleshooting guidance says vague or overlapping task descriptions can cause the supervisor to select the wrong worker. It recommends mutually exclusive responsibilities, explicit input parameters and a defined result format.

Human input pauses the whole team

A worker can request user input. When that happens, the entire team pauses in the same conversation. After the user responds, the worker resumes, returns its result and the supervisor continues its routing loop. Worker failures travel through the same return path; the supervisor decides whether to retry, switch workers, ask a question or stop.

For operators, the practical checklist is straightforward: treat worker descriptions as routing rules, make every delegated prompt self-contained, budget latency as a serial chain and inspect the existing team, task and tool history views. Oracle exposes the delegation path and returned worker results there, but introduces no new monitoring views for this release.