Read AI Studio from the model registry
- 1
AI Studio navigation separates Models, Agents, Knowledge, Script Tools and Configuration by governance responsibility.
- 2
Models is the engine registry; it does not itself decide routing, audience, knowledge or tool access.
- 3
New Model registers endpoint and model metadata; a tenant API key is set later through the saved row's separate action.
- 4
Search, filter and refresh support governance reviews across built-in and tenant-provided engines.
- 5
Provider, type, source, authentication and validation columns distinguish identity from connection health.
The Models page is one governed entry point into AI Studio. Navigation exposes Models, Agents, Knowledge, Script Tools and Configuration; New Model registers endpoint and model metadata; and the register shows provider, type, source, authentication, validation and actions using demo2's visible model rows. A tenant API key is not entered by the New Model dialog: use the saved row's separate Set API Key action, whose value is not shown in the registry.
Treat the model as infrastructure rather than an end-user assistant. After registration, an agent still needs routing, an execution identity and its saved behavior, knowledge and tool settings. Validate the connection after setting any required secret, never place secrets in labels or descriptions, and trace a turn from model through routed agent, effective identity, knowledge, runtime gates and metering.
AI Studio, under Setup → AI Studio, governs models, agents, knowledge, tools, nudge sources and credit allocations. Some settings are direct controls and others feed runtime policies that can be opt-in. In particular, an agent execution account can become the effective data identity, and capability/approval behavior depends on deployment switches. Review AI Studio together with runtime configuration and security profiles.
The screens
| Screen | What it governs |
|---|---|
| Models | The model registry: built-in and tenant models with endpoint, auth mode, capability flags, credit rates and validation status. Tenant API keys are set through a separate write-only action after the row exists |
| Agents | The agents behind chat: instructions, model binding, execution account, behavior limits, and the routing that decides which agent answers which message |
| Knowledge | Documents ingested for retrieval — uploads, entity attachments and auto-ingest rules — organized into named collections that agents can be scoped to |
| Script Tools | Sandboxed custom calculations with a bounded timeout and optional Required capability; approval depends on runtime policy |
| Capabilities | Named tool bundles used for planning and, when its switches are enabled, built-in/MCP tool filtering — see extending Sense |
| MCP Servers | External Model Context Protocol servers with stored credentials; exposure and approval are controlled by separate runtime settings |
| Nudges | The inventory of every nudge source and its tuning — covered in Nudge administration |
| AI Credits | Period allowances and current usage for AI consumption |
Each screen is gated by its own administrator capability, so model governance, agent authoring and credit administration can be held by different people.
How the pieces fit
A model is a registered engine with declared abilities and credit rates. An agent combines a model with an execution account, instructions, limits and routing. Knowledge supplies indexed collections. Capabilities tell the planner which tools fit the agent and can become hard allowlists when the matching enforcement settings are enabled. Sensitive script tools should also carry a Required capability, and MCP must be tested against its own gate.
When a user sends a chat message, routing evaluates eligible active agents and can select a specialist or fallback. The orchestrator then resolves that routed agent's execution account, so the effective identity can change with the route. Users do not select this identity from chat; administrators must test routing and data access together.
Credits meter consumption
Every user starts with a free daily tier: 1,000,000 tokens per user per UTC day for Sense AI chat and for the Setup Copilot, never charged to any allocation. Beyond that tier, AI usage is metered in credits against allowances you set on the AI Credits screen, per calendar month. Each completed model turn is charged at the invoked model's rates — per-token rates for language models, per-request rates for other model kinds — so what a turn costs is defined on the model row, and what the organization may spend is defined on the allocation. You can keep one tenant pool that everyone shares once their free tier is used, or assign credits to individual users from that pool (Set allocation → Scope: One user); assignments may not add up to more than the pool. Behaviours worth knowing precisely:
- No allocation configured means free tier only — each user stops at their daily free tokens until an administrator assigns credits or creates a tenant pool. (ML model credits have no free tier and remain unmetered without an allocation.)
- An allocation of zero is not "unlimited" — it is an immediately-exhausted pool that refuses every turn beyond the free tier.
- Exhaustion normally blocks at pre-flight: the free tier first, then the tenant pool, then the user's own assignment. The quota check deliberately fails open if its read throws, so an unhealthy credit store is not a guaranteed hard stop.
- A zero model rate is not always free. Unknown or zero-rate models can fall back to deployment-configured default token rates; only when both the model calculation and defaults produce zero is no ledger charge recorded.
The usage view shows credits and turns for the current period plus each user's tokens today against the free tier, so a surprising bill — or a user who was cut off this afternoon — has an inspectable trail.
What AI Studio does not change
Do not infer runtime safety from an inventory row alone. The routed agent's execution account can become the effective identity. Built-in capability enforcement, MCP capability enforcement and human approval are separate deployment settings, and an empty capability allowlist can fail open. AI Studio still does not grant the end-user chat surface by itself; licensing and module switches are covered in How Sense AI is governed. Verify identity, routing, tools, accept/reject approval paths and audit evidence in the target deployment.
Common questions
We created an agent — why don't users see the assistant?
Because agents don't grant access. The chat surface appears for every user whose security profile holds the Sense AI product (granted to every profile by default) while the Sense module master switch is on; agents only determine what answers once the surface exists. Check the Feature Hub switch, and for a profile created recently check that it holds Sense AI under licensing, before checking the agent.
What happens when credits run out?
When the quota read succeeds and finds an exhausted active allocation, pre-flight refuses the affected tenant or user until the period rolls or the allocation changes. A quota-read exception fails open, so investigate both allocation state and service health if turns continue. If usage is unexpectedly low, check model rates and the deployment's default fallback rates; a zero model row can still be charged through those defaults.
Can we bring our own models and tools?
Yes: register a custom model row, then set its API key through the separate saved-row action when required; add sandboxed script tools; or register MCP servers. Bundle tool references in a tenant capability, enable the intended runtime gates and prove that an ungranted agent cannot list or execute the sensitive tool. The full verification pattern is in Extending Sense.