Skip to main content
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.
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. 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 <slug> 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). 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 <organization> <team>). 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. “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.

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 covers templates, skills, triggers, approvals and reviewers. Build agents with Claude walks through creating one.

Who does what