> 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/start-here/how-qore-is-organized.md).
# Accounts, Projects, Spaces
Accounts, projects, the two spaces, and what each Operator can reach.
Qore uses accounts, projects, and two spaces to separate daily creation from account-wide governance. Use this overview to choose the correct boundary and surface before you begin.
### At a glance
| Concept | Use it for |
| ------------------ | ------------------------------------------------------------------------------------------ |
| **Tenant** | The top-level boundary for accounts, org-wide roles, brands, and model policy. |
| **Account** | Cost Control, access to Console and Control Center, governance, and account-wide controls. |
| **Project** | Apps, agents, knowledge bases, design systems, and shared context. |
| **Console** | Building and running work in the selected project. |
| **Control Center** | Monitoring and governing the full account. |
{% hint style="info" %}
**Key rule:** Console is project-scoped. Control Center is account-scoped. Control Center screens can still filter their data by project.
{% endhint %}
### How Qore is organized
A **tenant** is Qore's top-level boundary — one deployment for a customer. A tenant can have more than one **account**, and each account can have many projects. It holds org-wide roles, brands, the plan and model catalog. Org Settings manages the tenant's accounts and brands. Most customers see a single account and rarely need to think above that level.
An **account** is a business unit inside the tenant. **Cost Control** and credits, users (by membership), roles, teams, API keys, and governance controls belong to the account.
An account provides access to the **Console** and **Control Center** spaces.
Find **Account** in the left sidebar. Users with one account see that account. Users with multiple accounts can switch accounts from the account panel.
A **project** groups your apps, agents, knowledge bases, and design systems. Projects also define **context**. Every conversation in a project can use its artifacts.
Create a project for unrelated work. This keeps its context separate from other work.
Assets stay available within their project. For example, you can attach one knowledge base to multiple agents. You can also reuse a design system in a new app.
| Boundary | Owns | Why it matters |
| -------- | ------------------------------------------------- | ------------------------------------------ |
| Account | Cost Control, access, and governance | These controls apply across every project. |
| Project | Apps, agents, knowledge bases, and design systems | Artifacts and context remain isolated. |
A new user receives a starter project named after them. It gives them an immediate place to build.
{% hint style="info" %}
**Terminology change:** Earlier releases used **workspace**. It now means **project**. Older screenshots and release notes may still use the earlier term.
{% endhint %}
### Spaces: Console and Control Center
A switcher beside the platform logo moves between **Console** and **Control Center**.
{% columns %}
{% column %}
#### Console
**Console** is your daily project workspace. Build apps and agents, create knowledge bases, and run what you built.
Console uses the project selected in its header. It also shows the active account.
{% endcolumn %}
{% column %}
#### Control Center
**Control Center** provides account-wide administration and monitoring. Use it for observability, quality, guardrails, audit, cost control, and access management.
It opens at the account level. Use each screen’s project filter to narrow its data.
{% endcolumn %}
{% endcolumns %}
| If you need to… | Use | Scope |
| --------------------------------------------- | -------------- | ---------------------------------------- |
| Build or run an app, agent, or knowledge base | Console | Selected project |
| Check project artifacts | Console | Selected project |
| Review activity, quality, cost, or access | Control Center | Account, with optional project filtering |
| Manage users and roles | Control Center | Account |
{% hint style="info" %}
Console combined the earlier **Build** and **Run** spaces. Both activities now happen in one project workspace.
{% endhint %}
{% hint style="warning" %}
Projects aren't available from **Control Center**. They live in **Console**, under **Accounts**.
{% endhint %}
Control Center does not have a global project selection. Analytics, Audit Trails, logs, Reports, and Credit Usage support project filters within the screen.
### Operators and artifact scope
Each space has an **Operator**. An Operator coordinates specialized agents with shared conversational context.
| | Console Operator | Governance Operator |
| ------------------- | --------------------------------- | -------------------------------------- |
| **Space** | Console | Control Center |
| **Reach** | Selected project | Whole account |
| **Focus** | Apps, agents, and knowledge bases | Activity, cost, access, and guardrails |
| **Change handling** | Dispatches work immediately | Stages changes for approval |
The Console Operator can create a knowledge base, app, or agent. It creates the artifact in the current project. You can test it in the same chat.
The Console Operator can also search or crawl a URL. It can turn the result into a knowledge base or use it to create a design system.
The Governance Operator answers account-wide questions. Ask about published apps, recently created agents, or credit use. It can narrow a question to one project without changing Control Center’s account scope.
{% hint style="info" %}
Use the Governance Operator for oversight. It stages proposed changes and waits for your approval.
{% endhint %}
#### Module scope
| Module | Scoped to | Practical effect |
| --------------------------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Design Systems** | Project | Apps in the project inherit the design system. |
| **Flows** | Project | A flow and its versions belong to one project. Add it to an agent in that project as a skill. |
| **Apps, agents, knowledge bases** | Project | They use the project context. |
| **Store** | Account | Published solutions are visible across the account. |
| **Observe** | Account | Screens can filter results by project. |
| **Evaluators** | Account | An evaluator is attached to agents across the account, not created per project. |
| **Cost Control** | Tenant, account, and agent | Credit limits exist at all three levels — a tenant-wide cap, per-account caps and alerts, and a per-agent credit guardrail — and the strictest applicable limit wins. |
| **Admin** | Account | Roles apply across every project. Roles are held per account membership: one person can hold different roles in different accounts. |
| **AI Gateway** | Account | Model policy applies to all account activity. |
| **Govern** | Account | Controls apply across the account. |
| **Governed Graph** | Account | An uploaded graph is created for the whole account, so every project can read it. |
| **Console Operator** | Project | It works and builds in the selected project. |
| **Governance Operator** | Account | It supports account-wide questions and project filtering. |
{% hint style="warning" %}
The scope of **Integrations Hub** and **Custom Skills** is not confirmed. Do not treat either scope as documented until verified.
{% endhint %}
{% hint style="info" icon="readme" %}
**Good to remember**
* Control Center does not show an app or agent’s originating project.
* Switching accounts does not preserve the selected project.
{% endhint %}
### Publishing and access
Who can publish depends on their role. **Developer**, **Account Admin**, and **Organisation Admin** can publish apps, agents, knowledge, and flows, and **Governance Manager** can publish knowledge. **Approver** and the two admin roles approve publishing when it needs review. See [Roles](/ai-workbench-qore/control-center/admin/roles.md).
Roles control what each person can do. Each role grants a set of capabilities, and a person holds roles per account membership. See [Roles](/ai-workbench-qore/control-center/admin/roles.md).
### Quick choice
{% tabs %}
{% tab title="I need to build" %}
Use **Console**. Select the project where the work belongs. Create and run apps, agents, and knowledge bases there.
{% endtab %}
{% tab title="I need to govern" %}
Use **Control Center**. Review account activity, quality, costs, access, and controls. Filter by project when available.
{% endtab %}
{% endtabs %}
### Related resources
{% content-ref url="/pages/6712483fe92d4497b985e3f00b6d0737aa398200" %}
[Console](/ai-workbench-qore/start-here/console.md)
{% endcontent-ref %}
{% content-ref url="/pages/807cab861e090edd0ce825909db3db1b28f73799" %}
[Control Center](/ai-workbench-qore/start-here/control-center.md)
{% endcontent-ref %}
***
{% columns %}
{% column width="83.33333333333334%" %}
Maintained by Abhishek Paul
AI-assisted, human-approved
{% endcolumn %}
{% column width="16.666666666666664%" %}
{% 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/start-here/how-qore-is-organized.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.
