> ## 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. # Build agents with Claude > Describe the agent you want in a sentence. Claude checks what your Source has, interviews you, then drafts, saves and publishes it with the ekanos CLI. 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](https://sdk.ekanos.dev/concepts/sources-and-teams.md) first if those words are new to you. ## 1. Set up a folder ```bash theme={null} mkdir support-agents && cd support-agents npx @ekanos/cli login --host https://your-ekanos-host npx @ekanos/cli agents init claude ``` `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:///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//agent.json` and `AGENT.md` and walks you through them. Then: ```bash theme={null} npx @ekanos/cli agents apply agents/support-triage --source acme # saves a draft; no team sees it npx @ekanos/cli agents show support-triage --source acme # review what was stored npx @ekanos/cli agents test support-triage --team pilot --prompt "…" --follow --source acme # try the draft on one team npx @ekanos/cli agents publish support-triage --source acme --yes # only after you say yes ``` `apply` also pushes any `skills//` 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](https://sdk.ekanos.dev/guides/test-agents.md). 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](https://sdk.ekanos.dev/guides/linear-agent.md). 4. Confirm access: the person the agent runs as confirms it may use their connections, as themselves — `ekanos teams agents confirm `. 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 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 ` (or `ekanos teams agents enable --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](https://sdk.ekanos.dev/cli/commands.md#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 --to --yes` returns every following team to an earlier version. Already have agents in another framework? [Migrate an existing agent framework](https://sdk.ekanos.dev/guides/migrate-an-agent-framework.md) maps them onto `agent.json`. [Managed agents](https://sdk.ekanos.dev/concepts/managed-agents.md) explains templates, skills, triggers, approvals and reviewers. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.