Concepts
The building blocks of the portal — the organisation, its people, departments, groups, roles and shared resources — and the vocabulary used everywhere else in these docs.
The portal is one organisationOrganisationTổ chứcYour company's space in the portal. Each deployment runs one organisation, inside your own AWS account.Open in glossary holding users, departments, groups, roles and organisation-level resources. There is exactly one organisation per deployment. Every message a user sends to it starts an agentic loop, not a single model call. The rules binding these pieces together are on Governance model.
Key rules
- A department is a budget. Every person has exactly one departmentDepartmentPhòng banThe bucket that pays: it owns a budget, limits and which models its people may use. Everyone belongs to exactly one.Open in glossary, and every request is costed there.
- A group adds roles and gathers people for sharing. A person can be in many groups; a group never holds money.
- Roles are the only source of capability. Nothing else — not a department, not a group’s membership itself — grants a permission.
- Resources belong to the organisation. Each one carries its own visibility rules and inherits no access from an owner.
- A turn is a loop. The agent may call the model several times and use tools before it answers.
Find your way around
Why AI Portal The problem, the principles and who it is for. Governance model Who pays, who can, who sees — in one picture. 
Roles and capabilities Where every permission comes from. Resource visibility Allow, deny, and why deny always wins. 
Groups Bundles of roles that sharing rules can name. 
Departments The one cost and policy bucket per person. 
Budgets and policy Which budget, limit and model list applies. Access approvals Requests for a higher budget or a transcript read. Guardrails What is masked, flagged or blocked. 
Audit and cost tracking An audit row and a cost for every model call. Organisation concepts
| Concept | What it is |
|---|---|
| User | One person’s identity inside the organisation. Holds one built-in organisation role and may carry several custom roles, directly or through groups |
| Department | The cost and policy bucket: budget, quota, blocked models, rate limits and defaults. Exactly one per user |
| Group | A reusable bundle of custom roles, also named by visibility rules. Many per user |
| Role | A bundle of permissions. Users and groups may each hold several custom roles |
Read more: Departments · Groups · Roles and capabilities.
Governed resources
Six resource types live at organisation level. Each carries its own visibility rules and inherits no access from an owner — see Resource visibility.
| Resource | What it is |
|---|---|
| Agent | A configuration: instructions, model, tool allowlist, skill and knowledge references, memory setting and visibility. It inherits the model and quota policy of the person using it |
| Skill | Instructions an agent can load. Loading one grants no extra tool or data access. Built-in skills ship with the agent; custom skills are written in the portal |
| Prompt | A template you pick in the composer. Its variables are filled in before sending, and it bundles no tools |
| Application | An MCP server the organisation permits, reached through LiteLLM. End users see these as Connected apps. Shared through visibility, like an agent |
| Artifact | A versioned agent output: a document, code file, chart, diagram or web preview |
| Knowledge base | What memory statements and document excerpts are filed under. Every entry inherits the knowledge base’s visibility |
An application authenticates in one of four ways:
- None — no authentication.
- One organisation key — a single key held by the organisation.
- Each person’s own OAuth consent — the consent is a connection only that person can read or withdraw.
- The caller’s token, exchanged at Keycloak.
Tools are not resources
A tool is something the organisation runs under its own credential, configured once by an administrator. It carries no visibility rules, because it reaches nobody until an agent binds it. SharePoint is such a tool: it fills knowledge bases from the sites a Microsoft 365 admin granted. See Agent tools.
Knowledge base vocabulary
A memory statement and a document excerpt are rows in one store, and each names the knowledge base it is filed under (internally, a collection). The row itself carries no rule; it takes its answer from the knowledge base.
- Shared knowledge base — open to the whole organisation or not, plus allow and deny by department, group or person. Deny wins.
- Your own memories — filed under a knowledge base you own. It carries no rules and appears in no listing. Writing there needs no capability.
- Curating a shared knowledge base — needs ownership of it or the
knowledge.managecapability. - Personal file attachments — separate from knowledge. They never silently become shared knowledge.
How documents get in and are searched: Knowledge pipeline.
Workspace vocabulary
| Term | What it means |
|---|---|
| ClarificationClarificationCâu hỏi làm rõA question the agent asks you in the middle of a turn, with suggested answers and a box to type your own. Answering continues the same turn.Open in glossary request | A pause the agent starts, carrying one or more questions. Each offers suggested answers — which may say where they lead and may recommend one — plus a typed answer. Answers stay in the conversation and resume the same task |
| Execution mode | Whether permitted connected-app calls run straight away or wait for you. See below |
| Memory | Agent-scoped context you can inspect, edit and delete, filed in a knowledge base you own. It shares a store with the organisation’s knowledge and reads back as a knowledge base, a kind and a date — never as a cited excerpt |
| Conversation | Ordered turns, folders, file metadata, tool activity, citations, artifacts and cost metadata |
Execution modes
- Ask before each action (
ASK_EACH_OPERATION) pauses before every connected-app call so you can approve or deny it. - Run without asking (
YOLO) runs permitted calls with no per-operation prompt.
Neither mode bypasses authorisation, OAuth scope or audit. The mode is set at three levels: an organisation default, an optional override on one agent, and a per-tool floor that forces a prompt whatever the other two say. An application carries no mode of its own, because the question is what an agent is trusted to do. Details: Agent execution.
The shape of a turn
A user turn is an agentic loop. The agent may call the model several times, run tools and pause for a clarification before it reaches a final answer.
- A message is an ordered list of typed blocks — thinking summaries, text, tool calls and tool results — not a single string.
- One turn can make N model calls. Each is a separate billable event.
- Cost is logged per model call and grouped by turn for display and audit.
- Only the terminal answer renders as the answer. Thinking summaries, tool activity and clarifications appear in a working timeline above it.
Follow one turn step by step in The agentic loop and Turn lifecycle.