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.

Key rule: Console is project-scoped. Control Center is account-scoped. Control Center screens can still filter their data by project.

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.

Terminology change: Earlier releases used workspace. It now means project. Older screenshots and release notes may still use the earlier term.

Spaces: Console and Control Center

A switcher beside the platform logo moves between Console and Control Center.

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.

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.

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

Console combined the earlier Build and Run spaces. Both activities now happen in one project workspace.

Projects aren't available from Control Center. They live in Console, under Accounts.

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.

Use the Governance Operator for oversight. It stages proposed changes and waits for your approval.

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.

The scope of Integrations Hub and Custom Skills is not confirmed. Do not treat either scope as documented until verified.

Good to remember

• Control Center does not show an app or agent’s originating project.
• Switching accounts does not preserve the selected project.

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.

Roles control what each person can do. Each role grants a set of capabilities, and a person holds roles per account membership. See Roles.

Quick choice

I need to build

Use Console. Select the project where the work belongs. Create and run apps, agents, and knowledge bases there.

I need to govern

Use Control Center. Review account activity, quality, costs, access, and controls. Filter by project when available.

Related resources

ConsoleControl Center

---

Maintained by Abhishek Paul AI-assisted, human-approved