Skip to main content
You can create an agent for every team in your Source by describing it to Claude Code. The ekanos CLI gives Claude what it needs: what your Source can already use, how teams and Sources work, and the commands to save and publish an agent. You need a seat on the Source: developer to save drafts, or source_admin to also publish. Read Sources, team accounts and integrations first if those words are new to you.

​
1. Set up a folder

ekanos agents init adds:
  • The build-agent skill, which runs the interview and builds the agent.
  • The ekanos-platform skill, which explains Sources, teams, seats and connections.
  • The Ekanos docs MCP server in .mcp.json, so Claude looks things up here instead of guessing.
  • A short CLAUDE.md.
It doesn’t scaffold an integration, because an agent is data in Ekanos, not code in this folder.

​
2. Say what you want

I’m looking to create a customer support agent that uses Linear, Zendesk, and our Mintlify docs as the source of truth. It should triage support issues, respond when Linear issues are created or labeled, and respond to Zendesk tickets.
Claude starts by checking your Source with ekanos sources, ekanos catalog and ekanos agents list. It then tells you which parts of the request are:
  • ready, because the product is enabled and has the tools and events needed,
  • not set up yet, because someone has a step left, such as Ekanos giving your Source the product, or
  • missing, because no product does it yet.
A docs site often doesn’t need an integration. A Mintlify site serves an MCP server at https://<your-docs-host>/mcp, which the agent can use directly.

​
3. The interview

Claude asks one thing at a time and recommends an answer each time:
  1. The job. What the agent does, for whom, and what it must never do.
  2. Who gets it. Every team, as an agent provided to all of them, or one team’s own. If every team gets it, Claude explains what teams see, how updates reach them, how pinning and rollback work, and how to pilot with one team first.
  3. What it can touch. Which products and tools, and reads versus changes.
  4. What waits for a person. Which calls need approval. A public reply to a customer usually does.
  5. Whose connections. For each product, whether each team must connect its own (required) or may (optional).
  6. What teams may add. Their own MCP servers, skills or integrations, or stricter limits. All of these are off unless you want them.
  7. What starts it. The triggers each team will set up, such as an @mention, a label, a new ticket or a schedule, and what each needs connected first.

​
4. Draft, save, publish

Claude writes agents/<key>/agent.json and AGENT.md and walks you through them. Then:
apply also pushes any skills/<slug>/ folders beside agent.json as Source skills. agents test runs the draft on one pilot team, with every write waiting for approval; see Test an agent before you publish. Claude never publishes without your yes, never asks you for a secret, and never overwrites someone else’s change.

​
5. Each team turns it on

Claude ends with a checklist for teams:
  1. Open Agents › Provided for your team and Turn on the agent.
  2. Connect every required product.
  3. Do each integration’s own setup, for example the Linear agent.
  4. Confirm access: the person the agent runs as confirms it may use their connections, as themselves — ekanos teams agents confirm <team> <key>.
  5. Add triggers on the agent’s Triggers tab.
A Source admin can do this for a team from the CLI: ekanos teams agents enable, ekanos teams triggers add and ekanos teams connect (which opens the sign-in for the admin, or for the member --as names). Slack and the Ekanos Agents app for Linear install with ekanos teams connect <team> slack|linear-app, and their triggers are added with ekanos teams triggers add … slack|linear. Confirming access is done by whoever sets the agent up, as themselves: you with ekanos teams agents confirm <team> <key> (or ekanos teams agents enable <team> <key> --confirm-access to turn it on and confirm at once), or one of the team’s agent managers with Confirm access in the app. A plain team member never confirms. See Team agents.

​
Changing it later

Ask Claude for the change. It pulls the latest version, edits it, applies a new draft, tests it on a pilot team, and publishes on your yes. A change to skills, instructions, model or triggers keeps every team’s confirmation, and every following team moves to it. One that reaches further (a new product or tool, or more running without approval) moves them too: your publish is the confirmation, so a team that had confirmed stays confirmed, in your name. No team is held on an earlier version. publish lists each team pinned to another version and what the new one would add to it. --confirm-access also confirms every team on the version that was never confirmed. ekanos agents rollback <key> --to <n> --yes returns every following team to an earlier version. Already have agents in another framework? Migrate an existing agent framework maps them onto agent.json. Managed agents explains templates, skills, triggers, approvals and reviewers.