> 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/ai-workbench-qore/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 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.
* Asking a business user to open the list of agents, 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 reconciling data across several Control Center screens by hand.
* The Governance Operator takes the question as asked and routes to the governance-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.
### Key terms
| Term | Definition |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Operator** | An **Operator** is the coordinator. Each space, Console and Control Center, has one Operator. |
| **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 builds apps, agents, knowledge bases, and agentic applications, and routes tasks to agents. | Project | **System** agents, such as **App Builder Agent**, **Agent Builder Agent**, **Knowledge Builder Agent**, and **Document AI Agent**, and the project's own agents you turn on. |
| **Control Center** | Inspect the account and stage any action for your approval. | Account | A team of governance-review agents, such as **Agent Performance Analyst** and **Billing & Credit Manager**. |
#### Current capabilities
The Operator's capabilities depend on its space and may expand over time.
| Space | It can do today |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Console** | Build apps, agents, knowledge bases, and agentic applications. Search the web or crawl a website, and turn the content into a knowledge base or a design system. Create, change, or delete the project's design systems. Extract, classify, summarize, and generate documents, and save document templates. Act in third-party systems through the connections you turn on. Tell you who is in the account and which teams it has, and manage the account's projects. Run on a schedule. |
| **Control Center** | Answer account-wide questions about usage, cost, access, guardrails, and change history, such as published apps, recently created agents, and credit use. Narrow a question to one project. Stage changes for approval. Run on a schedule. |
For details, see [Console Operator](/ai-workbench-qore/console/console-operator.md), [Governance Operator](/ai-workbench-qore/control-center/governance-operator.md), and [Accounts, Projects, Spaces](/ai-workbench-qore/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.
### Running without you, and waiting for you
* **Schedules.** **Schedules** in the top bar runs an Operator at a set time, with instructions you write once and the agents each run may use. Schedules made in Console run the Console Operator; schedules made in Control Center run the Governance Operator. Times are set in UTC. See [Schedules](/ai-workbench-qore/console/console-operator/schedules.md).
* **Gates.** When an agent needs a decision, it asks in the conversation, and you answer, attach a file, or skip. A conversation that ends on a question is listed on **Gates** in the top bar until you answer. Each space has its own Gates page. See [Gates](/ai-workbench-qore/console/console-operator/gates.md).
* **Long-running work.** Building an app or ingesting knowledge can take several minutes. The Console Operator tracks these builds as background tasks, so it reports the real outcome when the build finishes, even if the conversation was interrupted.
### What you control
In Console, you choose which agents and connections the Operator may use. **System** agents start on; your own project agents start off, and the Operator doesn't consider an agent that is off. Integration Hub connections also start off. With a connection on, the Operator can act in that system; when a request needs a system it has no connection for, it tells you which connection to turn on or which integration you could connect. See [Agents & connections](/ai-workbench-qore/console/console-operator/agents-and-connections.md). In Control Center, the Governance Operator's agents are always available.
In the Console composer, you choose the Operator's **model** and **effort** (**Minimal**, **Low**, **Medium**, or **High**). The choice applies to each message you send. Agents the Operator hands work to run on their own configured model and effort.
To stop the Operator and everything it started, use **Control Center → Govern → Agent Controls**. Stopping a system agent also stops every run and helper agent it started. See [Agent Controls](/ai-workbench-qore/control-center/govern/agent-controls.md).
### 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.
* **Show the work.** The Operator shows its work in the conversation as it goes: each step it takes, each question it asks, and a card for each agent it hands work to, with that agent's status.
{% hint style="info" %}
**This surface is evolving.** The pattern above is settled. What each Operator can do, and how its agent team is composed, 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
Title
Description
Target
Agents
How each agent on an Operator's team is defined and configured.
{% endcolumn %}
{% endcolumns %}
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.uptiq.ai/ai-workbench-qore/core-concepts/operator.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
