Concepts: workspace, project, provider

The vocabulary you need before the rest of the guide: how a workspace (tenant) holds projects, how projects scope resources, and how providers connect Console to the models you pay for.

Read this page once and the rest of the guide will use words you already know. The objects are listed in the order you usually meet them.

workspace (tenant)
 ├─ members, groups, roles
 ├─ projects
 │   ├─ models   ── use a ──▶ provider (credentials)
 │   ├─ agents   ── call ──▶ models, tools, knowledge
 │   ├─ API tokens
 │   └─ knowledge, tools, prompts, guardrails ...
 └─ portals (Enterprise) ── offer ──▶ published agents

Workspace (tenant)

A workspace is your organization's private space in Console. The API and the code call it a tenant. Everything you create lives inside exactly one workspace, and its data is stored separately from every other workspace: each tenant has its own database (a separate SQLite file or MongoDB database).

The workspace holds the people (members, their roles, and groups), the projects, the licence and the settings that apply to everyone. The person who creates it is its owner. Owners and administrators can see across all projects; other members see the projects they were given.

See Multi-tenancy and Authorization (IAM).

Project

A project is a folder for one team, product or environment inside a workspace. Most resources belong to a project: models, agents, tools, knowledge, prompts, guardrails, and the logs and costs they produce. The project pill in the header sets the active project, and switching it changes what every page lists.

Projects are also the unit of access. A member, or a group, can be given a level per service in one project, and project permissions only ever narrow what the workspace level allows. An API token is bound to a project and runs under that project's limits.

A resource refers to others by key, and keys are unique per project. A reference is resolved in the resource's own project first, so two projects can each have a model called fast without colliding.

Provider

A provider is a connection to a service that does the work: OpenAI, Anthropic, Amazon Bedrock, Azure, Vertex AI, Ollama, a vector database, a web search engine and others. It holds the credentials (encrypted at rest) and settings, and it covers one domain: chat models, embeddings, vector stores, speech, OCR, web search and so on.

A provider is how Console reaches the models you pay for. It is scoped to the workspace or to specific projects, and a project can only use the providers assigned to it. See Providers.

Model and model key

A model is an entry in the Model Hub: a provider plus the model name at that provider, with pricing and capabilities. The entry's key is the one name you use everywhere else. Callers put it in the model field, and agents refer to it as their model, so you can re-point a key at a different provider model without touching a single caller.

Some entries have no provider behind them. A Dynamic LLM is a key that resolves to one of your real models per request, by rule or by a decider. See Model Hub and Create your first model.

API token

An API token (it starts with cpeer_) authenticates a program against the client API at /api/client/v1. Every token is owned by a user, is bound to a project and can be limited to chosen services, so a token can only narrow what its owner may do. For services and automation, create a Programmatic User (a user that cannot sign in) and mint its tokens, rather than sharing a teammate's personal token.

Tokens are managed under Configure → API Tokens. The secret is shown once, at creation. See Authentication.

Agent

An agent is a configured assistant that Console runs for you: a main model (and optionally additional models callers can choose), instructions, tools, knowledge, memory, guardrails and runtime limits. You build it in Build → Agents, try it as a draft, and publish a version. The API and portals run the published version.

A conversation with an agent is a session. An agent can wait for a person (approvals and questions), run in the background, and call your systems through tools. See Agents.

Portal

A portal (Enterprise) is a ready-made chat page for people in your organization, at /p/{address}. You choose which published agents it offers, who may open it, and how it looks and behaves. It can also be embedded in another page. A portal adds a front door, not a second copy of the agent: people talk to the same published agents, under the portal's access list. See Portals.

How they fit together

A typical path: a provider connects Console to a vendor, a model in a project uses it, an agent in that project uses the model and some tools, you publish it, and then you reach it with an API token from your code or put it behind a portal for your colleagues. The guides walk through it with real screens.