Platform Fundamentals

Everything in InteractiveAI sits at one of three levels. An organization is the billing and membership boundary, usually a company or a business unit. A project is a workspace inside it, holding its own agents, context, secrets, and traces. An agent lives in a project and draws only on what that project contains.

The middle level exists for isolation. An agent built in one project cannot see the context, secrets, or traces of another, so someone given access to a single project cannot reach anything outside it.

How a project fits together

The agent is what the platform exists to run. Everything else in a project is either something an agent uses, something that runs it, or something that watches it.

Its behaviour comes from Context. A system prompt says what it is, policies constrain what it may do, routines drive specific conversations from start to finish, glossaries teach it your vocabulary, macros hold the blocks of text it reuses, and variables carry the contextual attributes that policies and routines reference

What it can reach comes from Connectors and Infrastructure. Models arrive through the Router, tools through MCP servers registered on Integrations, state and retrieval through databases, credentials through secrets, and anything you wrote yourself runs as a service.

What it did comes from Governance. Every request is recorded as a trace you can open step by step, its containers are measured, and its output is logged.

Whether it is any good comes from Improvement. Evaluators and people both produce scores, run against datasets of fixed test cases, so a change can be compared against what came before rather than argued about.

Inside an organization

Signing in lands you on your organizations, each showing its plan, how many agents it holds, and how many people are on it.

Projects lists every project with the agents inside it, and is where you create either. Opening one takes you into everything else these docs cover.

Team is everyone in the organization, with their role and who invited them.

Usage shows what the current billing cycle has consumed, split across Copilot, LLMs, Deployment, and Storage, each with a chart, a detailed breakdown, and its cost.

Billing carries the plan, the payment method, and the invoice history.

Settings holds the organization's name and type.

Roles

Five roles, each carrying everything the one below it has.

• None grants nothing at organization level. It exists so someone can be given access to specific projects and nothing else.

• View Only reads everything and changes nothing.

• Member does the day-to-day work: prompts, datasets, scores, evaluators, dashboards, annotation queues, and agents. Secrets, services, databases, and keys stay read-only.

• Admin adds infrastructure and credentials, agent and trace deletion, protected labels, audit logs, project creation, and billing.

• Owner adds deleting the organization, its projects, and its members.

Any of these can be overridden for a single project from that project's Members page, which is how you give someone more access on one project or less on another without changing what they can do everywhere.

Structuring projects

Because isolation is the whole point of a project, the question worth asking early is what must not be visible across the boundary. Teams usually divide by product, by team, or by environment, and the right answer is normally whichever one matches who should not see whose data.