> 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, 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. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.