> For the complete documentation index, see [llms.txt](https://docs.interactive.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.interactive.ai/platform-fundamentals.md). # 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, and macros hold the blocks of text it reuses. Each of those is written once in the project and attached to whichever agents need it, so changing a rule in one place changes it everywhere it is used. 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.interactive.ai/platform-fundamentals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.