> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/core-concepts/operator.md).

# 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.

<figure><img src="https://1326225582-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0qmgQjJ5aArDTj2ACFHG%2Fuploads%2FC5rMXMQKXlYNzAIslnsJ%2Foperator-concept-qore%20II.png?alt=media&amp;token=d637b771-b125-48b2-ab76-b59f1fd0478b" alt=""><figcaption></figcaption></figure>

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.

<details>

<summary><strong>Users don't know which agent to call.</strong></summary>

* 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."*

</details>

<details>

<summary><strong>Context resets between agents.</strong></summary>

* 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.

</details>

<details>

<summary><strong>Governance answers live in many places.</strong></summary>

* 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.

</details>

<details>

<summary><strong>Auto-fixes are either off or risky.</strong></summary>

* 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.

</details>

### 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](/console/console-operator.md), [Governance Operator](/control-center/governance-operator.md), and [Accounts, Projects, Spaces](/start-here/how-qore-is-organized.md).

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.

{% hint style="info" %}
**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.
{% endhint %}

### Related

<table data-view="cards"><thead><tr><th>Title</th><th>Description</th><th data-card-target data-type="content-ref">Target</th></tr></thead><tbody><tr><td><strong>Agents</strong></td><td>How each agent on an Operator's team is defined and configured.</td><td><a href="/start-here/core-concepts.md">Agent Foundations</a></td></tr><tr><td><strong>Apps</strong></td><td>The artifacts the Console Operator builds and runs.</td><td><a href="/console/app-builder/app-workspace.md">App Workspace</a></td></tr><tr><td><strong>Agent Controls</strong></td><td>The guardrails a Governance Operator can check for.</td><td><a href="/control-center/govern/agent-controls.md">Agent Controls</a></td></tr><tr><td><strong>Steering &#x26; Reasoning</strong></td><td>How an agent decides — the concept sitting alongside the Operator.</td><td><a href="/core-concepts/steering-and-reasoning.md">Steering &amp; Reasoning</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.uptiq.ai/core-concepts/operator.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.