> ## Documentation Index > Fetch the complete documentation index at: https://sdk.ekanos.dev/llms.txt > Use this file to discover all available pages before exploring further. # Sources, team accounts and integrations > How an Ekanos deployment is organized, who can change what, and how integrations and agents reach the teams that use them. Ekanos is a white-label platform. Each customer runs it as their own product, under their own brand and domain. This page explains the pieces you work with as a developer or Source admin, and where integrations and agents fit. ## Sources and team accounts A **Source** is one customer's whole deployment: its brand, its domain, its users and the products it offers. Inside a Source are many **team accounts**. A team is where work happens: it has its own members, data, connections and agents. Teams in the same Source don't see each other's data. Team members have one of three team roles: **owner**, **admin** or **member**. These roles apply to that team only. Being a team owner gives no authority over the Source. > [!NOTE] > > Team members never see the word "Source". To them, something you set up for > everyone is "provided for your team". Keep Source language out of anything a > team member reads. ## Seats: who can use the CLI The CLI acts on a Source through a **seat**. `ekanos sources` lists yours. | Seat | Can | | - | - | | `developer` | Submit integrations, read the Source's catalog, and save agent drafts | | `source_admin` | Everything a developer can, plus publish agents to every team, set up the Source's provider apps, and manage the Source's people | Only Ekanos grants seats. ## Products: integrations and experiences Everything a Source can offer is a **product**, of one of two kinds: * **Integrations** connect a third party, such as Linear, Zendesk or Slack. They bring tools an agent can call, and can declare **agent events** that start agents, such as a new ticket or an @mention. * **Experiences** are Ekanos's own capabilities, such as Agents or Workflows. They are switched on for a Source and never "connected". `ekanos catalog --source ` lists every product the Source has, with its tools, its agent events, and the setup steps still to do. ## From "available" to "in use" Four separate facts, in order. A product can be at any of them. 1. **Given to the Source.** Ekanos makes a product available to a Source. The catalog shows `enabled`, `turned-off` (given, but switched off for now) or `available` (offered, not yet given). 2. **Connected by a team.** Each team signs in to the third party itself. Connections belong to teams by default, so two teams using Linear each connect their own. Some integrations connect per person instead of per team. The one exception is a **Source connection** (below). 3. **Set up by the team.** Some integrations have each team bring its own app, entering a client ID, secret or webhook signing secret in Ekanos. Secrets are always entered in the app, never in a file or a chat. 4. **Used by an agent.** An agent can call a product's tools once its tool access includes them. Some integrations, such as Linear, sign every team in through one app for the whole Source. Until the Source has that app's client ID and secret, no team can connect. A Source admin sets it up: `ekanos apps show linear` gives the callback URL to register with the provider, and `ekanos apps set linear` asks for the client ID and secret, at your own terminal or, without one, from the environment, a private file, stdin or a form in your browser ([Secrets without a terminal](https://sdk.ekanos.dev/cli/commands.md#secrets-without-a-terminal)). Integrations where each team brings its own app, such as Zendesk, have no Source app. Some customers run **one** vendor account for many teams: one Zendesk where each bank is an organization. For an integration that supports it, a Source admin connects it **once for the whole Source** (`ekanos apps connect`) and maps a value inside each event to a team (`ekanos routes set zendesk `). That connection is used only by provided agents whose template marks the product `"owner": "source"`, and each team's agent works only inside the values mapped to that team. An event no team is mapped to starts nothing. Team members never see the Source connection: their widgets, assistant and own agents keep using the team's own. See [`routes`](https://sdk.ekanos.dev/cli/commands#routes). "Enabled" doesn't mean "connected". When you plan a rollout, say which of the four you mean. ## Integrations A developer builds an integration with the SDK, checks it with `ekanos validate`, and submits it with `ekanos publish`. Ekanos reviews the submission and makes it a product. A team then connects it. See [Integration lifecycle](https://sdk.ekanos.dev/concepts/lifecycle.md). ## Managed agents A managed agent is data held by Ekanos, not code. It has instructions, a model, the tools it may use, which calls wait for a person's approval, and its skills. You change it with the CLI or in the app, and nothing is deployed. There are two ways an agent reaches a team: * **Provided for every team.** A Source admin defines it once with `ekanos agents`. Every team sees it under **Agents › Provided for your team** and decides whether to turn it on. Each team's copy runs on that team's own connections, and its triggers are the team's own. Publishing a new version updates every team that follows the latest version. A team can instead pin a version. * **A team's own.** A team builds it in the app. Only that team has it. [Managed agents](https://sdk.ekanos.dev/concepts/managed-agents.md) covers templates, skills, triggers, approvals and reviewers. [Build agents with Claude](https://sdk.ekanos.dev/guides/managed-agents.md) walks through creating one. ## Who does what | Who | Does | | - | - | | Ekanos | Gives a Source its products, and grants seats | | Developer | Builds and submits integrations, and drafts agents | | Source admin | Publishes agents to every team, sets up the Source's provider apps, and manages the Source's people | | Team | Connects integrations, turns on provided agents, and sets their triggers | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.