Operator

Coordinate specialized agents to complete requests with shared conversational context.

An Operator is not a single agent that does everything. It's the coordinator that runs a team of specialised agents on your behalf.

You give it a request; it decides which of your agents fits, hands the work off, and brings back what they produce.

Multi-agent orchestration, in one loop

Every Operator surface in UPTIQ works the same way. You ask; the Operator reads which agents are available and what the conversation has covered so far; it picks the agent whose description fits; it dispatches; the agent's results come back through it. Each turn is saved so the next one has context.

The pattern is called multi-agent orchestration: a coordinator that routes each request to the specialist best suited to it, so no single agent has to do everything and each agent can be tuned to one thing.

What it solves

Four problems that show up as your agent team grows — and the Operator's answer to each.

Users don't know which agent to call.

• A shipped project's agent team can have a dozen specialists on it.

• Asking a business user to open the list, read every description, and pick the right one is a job they didn't ask for.

• The Operator does the picking from the request itself, so the user's task stays "describe what you want" — not "choose the right specialist."

Context resets between agents.

• Talk to one agent about a customer, then need help from another, and the second one starts with nothing.

• The Operator holds one conversation across every hand-off — you don't repeat yourself, and the agents don't miss what came before.

Governance answers live in many places.

• A plain question like "what's driving cost this month?" usually means opening Analytics, LLM Logs, Cost Management, and Runs & Traces, then reconciling by hand.

• The Governance Operator takes the question as asked and routes to the review agent that has the answer.

Auto-fixes are either off or risky.

• Without an approval step, the only safe posture for a governance surface is look, don't touch — every remediation becomes a manual ticket, which cancels most of the point of orchestration.

• Staged actions let the Governance Operator write down the fix it would make and wait for you to approve it — automation's speed without handing over control.

Key terms

Term	Definition
Operator	An Operator is the coordinator. Every UPTIQ space has one Operator surface.
Agent team	An agent team is the set of agents an Operator can dispatch to. Each agent carries a name and a short description; the Operator uses those descriptions when deciding who fits a request. (The Governance Operator's UI calls this an operating team — same idea, different label.)
Agent	An agent is a purpose-built worker, built and configured in Console, that does one thing well.
Conversation history	Conversation history is the running record of what you asked and how the Operator and its agents answered. The Operator reads it before each turn so context carries forward.

Spaces and Operators

The core loop is the same in both spaces. What changes is the shape of the request and what the Operator does with it.

Space	Operator's job	Default scope	Dispatches to
Console	Build and run. It scaffolds new apps, agents, and flows, and routes tasks to the project's existing agents.	Project	An agent team built in Console — or nothing, when it is building.
Control Center	Inspect the account and stage any action for your approval.	Account	A team of governance-review agents.

Current capabilities

The Operator's capabilities depend on its space and may expand over time.

Space	It can do today
Console	Build apps, agents, and knowledge bases. Search or crawl a URL. Turn crawled content into a knowledge base or use it to create a design system for an app.
Control Center	Answer account-wide questions about published apps, recently created agents, and credit use. Narrow a question to one project. Stage changes for approval.

For details, see Console Operator, Governance Operator, and Accounts, Projects, Spaces.

One difference worth naming.

The Governance Operator stages actions for your approval. The Console Operator dispatches a task the moment you ask. In Control Center, anything the Operator would change is written down and waits for you to approve it before it runs.

What both share

Under the starter cards on every Operator surface sits the same line: Operator plans the work and hands each part to the right agent. That's the concept in one sentence.

Two other invariants worth naming.

• Read before dispatch. Every Operator reads the conversation history and the current agent team's descriptions before it picks. That's how routing stays sensible turn to turn.

• Post as it goes. The Operator keeps you informed while an agent runs, so you can catch a mis-routed request early. When more than one agent is needed, work is handed out in sequence.

This surface is evolving. The pattern above is settled. What each Operator can do, how its agent team is composed and curated, and which named Operators exist in Control Center will change as the feature matures. Use this page for the shape; check the space-specific pages for what a given Operator can do today.

Related

Title

Agents

Description

How each agent on an Operator's team is defined and configured.

Target

Agent Foundations

Title

Apps

Description

The artifacts the Console Operator builds and runs.

Target

App Workspace

Title

Agent Controls

Description

The guardrails a Governance Operator can check for.

Target

Agent Controls

Title

Steering & Reasoning

Description

How an agent decides — the concept sitting alongside the Operator.

Target

Steering & Reasoning