Tenant Console
The tenant console is the web app you sign in to at /app. It is where you point AI clients at your own isolated slice of the UGENT Context Engine: your content, your keys, your team, your memory. Nothing you do here can see or touch another tenant's data.
This guide covers everything a tenant can do. Operator and platform-admin tasks (provisioning tenants, editing the server config, activating a tenant) are out of scope — those live with whoever runs the deployment.
Sign in
You sign in with a tenant API key that your operator issued you. It may or may not carry the owner role — signing in needs neither, only config:read. Paste it into the login form at /app/login. The key is sealed into a session cookie; it is never exposed to the browser's JavaScript and never leaves the server side of the console.
If the dashboard says Tenant not ready, your tenant exists but its data plane is not serving yet. That clears when the operator activates it — there is nothing for you to fix.
The order things happen in
The console's left navigation is grouped in the order the pages actually depend on each other, and the dashboard shows the same sequence as a checklist that ticks itself off from real state.
| Group | Pages | What it is for |
|---|---|---|
| — | Dashboard | Status, usage, and your first-run checklist. |
| Set up | Models, API Keys, Connect MCP | Decide providers, issue a key, point a client at it. |
| Content | Workspaces, Connections, Memory | What you hold and how it gets in. |
| Access control | Directory, Access, Actor activity | Who your users are and what each may see. |
| Tuning | Settings, Semantic Templates, Vocabularies | Rarely, and never on day one. |
Three steps get you to a working tenant:
- Choose your models — before anything is indexed.
- Create an API key — nothing reaches the engine without one.
- Get content in — connect a database or push documents.
Then connect a client, and if more than one person will use it, add your team and write access rules.
Step 1: Choose your models
Models is first for one reason: changing the embedding model after content is indexed forces every document to be re-embedded. Deciding up front costs nothing; deciding later costs a full re-index.
You have two options, and inheriting is a legitimate end state:
- Inherit the platform defaults. Your operator has already configured embedding, semantic, and reranker models. Do nothing and you use them.
- Bring your own (BYOK). Override any of the three with your own provider and API key. Your key is stored as an encrypted tenant secret, referenced by id, and never returned to the browser in a config read.
To override, toggle the switch on the model you want to change, fill in the provider and model, and select a secret for the API key. If you have not uploaded one yet, the secret picker on the same page will create it.
Saving stores the change. It does not apply it — see Saving versus applying.
Saving versus applying
Almost every configuration page in the console works the same way, and it catches people out once:
- Save writes your change to your tenant's stored config. Nothing running changes.
- Apply changes (the panel at the bottom of the page) makes it live. Run Dry run first — it reports the impact and warns when a change requires re-embedding or a migration, and some changes require you to tick an acknowledgement before Apply reload will proceed.
Until you apply, the running engine keeps using the previous configuration. Pages that depend on this say so: a database source added on Connections shows Needs a reload and cannot be tested or synced until the reload lands.
If you see "The config changed elsewhere since you loaded it", someone (or another tab) saved in between. Reload the page to pick up the current version and re-apply your edits — your unsaved changes were not written.
Usage and quotas
The dashboard shows a usage meter when your operator has metering enabled. It counts tokens spent on your behalf across embedding, semantic extraction, reranking, and memory, with a cost estimate per model at list prices.
If your tenant has a quota and enforcement is on, requests that would exceed it are rejected with a quota error rather than silently costing more. Keys you issue with bring your own key providers are metered but not billed against the platform quota.
Two things that are not charged, because they come up as soon as a second person joins:
- Re-sending unchanged files. If a teammate pulls the same code and their client pushes it, the engine matches the content hash and skips the file before any embedding or LLM call happens. See re-sending files does not cost you twice for the cases that do re-index.
- Cached embeddings. Repeated identical text within a run is served from cache and metered once, at the provider call, not per request.
Where to go next
Set up and use
- API keys and connecting clients.
- Getting content in — workspaces, pushes, and re-index cost.
- Connecting a database — schema-only or indexed rows, and row-level access.
- Connecting HubSpot — CRM records, and why they are private until you share them.
- Memory — what your applications remember.
Share it with a team
- Adding team members — actors, groups, and roles.
- Controlling what each person sees — folder access rules.
Tune it
- Overriding the defaults — runtime, search quality, and the extraction cost levers.
- Semantic templates and vocabularies — teach extraction about your own content.