# The Elaichi Agent, in the App and in Slack > The Elaichi Agent works your connected apps from the console or Slack, on your own AI provider key, as the person asking, with an approval card before writes. **TL;DR** The Elaichi Agent comes with the Black plan and runs inside Elaichi, beside Claude, ChatGPT, Cursor or any MCP client. Open it from the console sidebar or tag @Elaichi in Slack. It runs on your organization's own AI provider key, acts as the person asking under their roles and restrictions, and shows an approval card before a write unless the person chose Always allow. It can also draft, validate and test-run a workflow on real data, with writes held back, before a person publishes it and turns it on. The Elaichi Agent works your connected apps for you, from the console or from Slack, as the person asking. It comes with the Black plan. A sales rep who lives in Slack can get a renewal summary before a call, with no client to set up. ## What is the Elaichi Agent, and where does it run? The Elaichi Agent is an AI assistant that works inside Elaichi, in the console's Agent window or by a tag in Slack. It comes with the Black plan. The Agent sits beside Claude, ChatGPT, Cursor or any MCP client, not among them. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps ([Model Context Protocol](https://en.wikipedia.org/wiki/Model_Context_Protocol)). Those clients sign in to one address, https://api.elaichi.ai/mcp. The Elaichi Agent does not. It runs inside Elaichi, yet passes the same restrictions and writes the same kind of audit entry. ## How do you open the Agent in the console? Choose the "Agent" row at the top of the console sidebar, or press Command-Shift-A. The row shows when the organization has the Agent and the person holds tool:execute, the permission to run connected tools. Before a write, the Agent shows an approval card with "Deny" and "Allow once". When the action can be remembered, it also shows "Always allow", and that choice skips the card next time. After an edit to the arguments, the button reads "Save & allow once". The model picker lists every chat model the organization added, on any provider. A chat with no model picked runs on the organization's default model. ## How does the Elaichi Agent work in Slack? Tag @Elaichi in a channel, in a direct message, or in Slack's agent panel. Each of these reaches the same Elaichi Agent as the console window. Slack documents the [app mention event](https://docs.slack.dev/reference/events/app_mention) and the [split view where people message an AI app](https://docs.slack.dev/ai/developing-ai-apps) on its developer site. Someone who holds assistant:manage connects the workspace in Settings > Organization > Slack. It is admin-only because Elaichi matches each Slack user to a member by the email Slack reports. A mention that cannot be matched is refused, not guessed. Elaichi refuses: - a Slack user with no email - an external user - a person who is not a member - a member without tool:execute Write approvals in Slack carry two buttons, Approve and Deny. Always allow is not accepted there. Only the person whose conversation raised the card can answer it. ## Which AI provider keys does the Agent run on? The Elaichi Agent runs only on your organization's own AI provider keys. This is bring your own key (BYOK): the Agent uses your key, and Elaichi supplies no model key. A turn with no usable key fails with a message that points to Settings > AI models. Chat models come from five providers: Anthropic, OpenAI, Fireworks AI, OpenRouter, and an OpenAI-compatible gateway. Each provider holds one key. Setting them needs assistant:manage. Elaichi checks a key with the provider before it saves it, and turns away a key the provider refuses. OpenRouter, for one, takes the key as a bearer token (a key sent with each request) in the [Authorization header](https://openrouter.ai/docs/api-reference/authentication). The [Get an AI provider key guide](https://elaichi.ai/docs/guides/settings/ai-provider-keys) shows where to create a key at each provider. A turn whose model's provider has no key, or rejected it, is refused with the reason. It does not switch to another provider. ## Whose access does the Elaichi Agent use? The Elaichi Agent acts as the person asking. It uses their roles and restrictions, through connections that person can use, and nothing beyond them. Every connected-tool call passes one restriction check, run for the member the call acts as. That check is the same one a call from an MCP client passes. A tool restricted for Emily is restricted for her in the Agent, in Slack and in Claude alike. Permissions are checked again when a person approves a card, not when the model asked. A permission removed while the card was open stops the action. A role or restriction change reaches every surface in about two minutes. Only the person who started a conversation can approve what it proposes. ## What stops the Agent before it writes? An approval card stops each write. Reads need no card. A write asks unless the person chose Always allow for it, and a delete called directly asks every time. - A connected tool that writes shows a card. The person can choose Always allow for that toolbox, tool and connected account. Later calls of it then run without a card. A toolbox is a named list of tools. - A tool that deletes, called directly, asks for approval every time. - A pending card stays answerable for one hour. After that, the action does not run. The Agent also scans every tool result for prompt-injection patterns. Prompt injection is text in a result that tries to steer the AI, such as an order to ignore earlier instructions. After a flag, each of Elaichi's own writes must pass a second model check against the last message the person typed. The check fails closed: when the answer is unclear, the write is blocked. The block writes an assistant.write_blocked audit entry. This detection is heuristic, meaning it works by pattern, so it is not a guarantee. It exists only in the Agent. ## How does a renewal summary from Slack work, step by step? The Agent reads without asking and stops at a card before it writes. Emily Carter runs renewals. At 9:15 AM, she types this in #renewals: > "@Elaichi draft a renewal summary for Northwind Logistics from the open Salesforce opportunity and the last month of Zendesk tickets. Then save it as a note on the account." 1. Elaichi matches Emily by her Slack email to her Elaichi membership. She holds tool:execute, so the turn runs on the organization's default model. 2. The Agent reads the opportunity from the [Salesforce connector](/connectors/salesforce/) and the tickets from the [Zendesk connector](/connectors/zendesk/). Both are reads, so no card appears. 3. It answers in Slack with the draft summary. 4. Saving the note calls create_a_salesforce_note, a write. Slack shows an approval card with Approve and Deny. 5. Emily reads the card and presses Approve. Jake Morgan sees it too, but his press is refused privately, because the conversation is Emily's. 6. The note is written through a connection Emily can use, and each call is recorded in the audit log. If Emily's role were restricted from that tool, step 4 would be refused, just as in her own Claude. ## Can the Agent write and test a workflow before it goes live? Yes. Your own AI writes the workflow and proves it on real data before anyone turns it on. That AI can be the Elaichi Agent, or Claude, ChatGPT, Cursor or any MCP client through the `elaichi__automation__` operations. The Agent gets the workflow, collection and dashboard operations from the catalog MCP clients use. A collection is a shared table. The loop has five steps: 1. **Draft.** The Agent writes the workflow as a draft. A draft saves even with validation issues. Creating or changing a draft puts an approval card in front of the person. 2. **Validate.** Validating checks the definition without saving it, and needs no approval. 3. **Test run.** A test run, "Test run (changes nothing)" in the console's Run now dialog, runs the latest draft against real data. It needs no approval. Tools that read run for real, as the person chatting, not the workflow's owner. Tool calls that write, collection writes, state writes and knowledge writes are recorded as what would have been sent. A notify step sends nothing. A test run costs no run time. 4. **Replay.** A draft's webhook trigger already has its address, where other apps send events. Deliveries to it are kept as samples, and a test run can replay one. 5. **Publish and turn on.** Publishing makes the draft a numbered version, and Turn on is a separate step. In the Agent, both ask every time and can never be remembered. So do discarding a draft and deleting a workflow. An older version can be restored from Details > Versions. The Agent cannot answer a workflow approval. It cannot reveal, rotate or set a webhook secret either. Dashboards follow the same pattern. A dashboard's header has "Ask the Agent", edits land in a draft, and publishing asks every time. The [workflows post](/blog/elaichi-workflows/) covers the full loop. ## Everything in one place, with the AI your team already uses Black puts 650+ connectors, workflows, collections, dashboards and the Agent in one place, under one set of rules. Your team brings the AI it already uses: Claude, ChatGPT, Cursor or any MCP client at https://api.elaichi.ai/mcp. The Elaichi Agent works beside them, in the app and in Slack. The pieces connect. A workflow calls connected tools and writes rows to a collection. A dashboard reads that collection, or live data from a toolbox tool. Any of those AIs builds, tests and reads all of it through the same operations. One key per provider serves both the Agent and workflow agent steps. One restriction check runs on every connected-tool call, and a workflow runs under its owner's restrictions. One audit log records each call, and people answer the approvals. One bill covers seats plus pooled usage. The [collections and dashboards post](/blog/elaichi-collections-and-dashboards/) shows the data side. ## What does the audit log show about the Agent? An audit log is the record of who did what. In Elaichi, every entry names the surface it came from. An Agent call is recorded with the surface app, beside console, api and mcp. The Agent's connected-tool calls are recorded under the person who asked, with the surface app. Those rows are not marked as AI-made; the surface is what shows the Agent made them. Each row names the tool, the connection, and whether approval was needed and how it was given. Always allow and Deny choices are audited too. Rows for Elaichi's own operations run from the Agent also carry the conversation id, the tool-call id and the model. On Black, the entries can also leave Elaichi: export to your own Datadog comes with the Black plan. ## What can't the Elaichi Agent do? The Elaichi Agent has firm limits, and each one keeps a person's decision with a person. - It has no web search or web fetch tool. Elaichi does not browse the web for it. - It cannot approve a workflow step. Only a person approves, in Elaichi or in Slack. - It cannot approve or deny an access request. - Spend controls are read-only for it. - It cannot mark a knowledge document as trusted. A document the Agent or a workflow writes waits as unreviewed until a person in the console reviews it. - It cannot invite people, change a member's roles or delete a role. The refusal names the console screen to use. ## What does the Elaichi Agent cost? The Agent comes with Black seats: you pay per user, never for the AI apps working for them. Black lists at $24 per user per month in US dollars, or $18 per user per month billed yearly ($216 a year). See [pricing](/pricing/) for your own price, in your currency where Elaichi bills in it. Black adds usage beyond a free monthly allowance of 1,000 run minutes and 1 GB-month of storage, pooled across the organization. Past it, a run minute is $0.02 and a GB-month is $5. Waiting for a person is free. Agent chat uses none of those meters: no run minutes and nothing against the usage budget. Its model calls run on your own provider key, never an Elaichi key. A workflow's agent step is different: its working time counts as run time. The 14-day free trial is the Black plan itself, with no card to start. Every Black feature is on during it: workflows, collections, dashboards, knowledge bases and the Elaichi Agent. Its one limit is the free monthly usage, 1,000 run minutes and 1 GB of storage, a hard stop until you buy Black. A trial that ends moves the workspace to the free Personal plan and deletes nothing. [Start the Black trial](https://app.elaichi.ai/signup) and ask the Agent your first question. ## When you may not need the Agent Some teams do not need the Elaichi Agent. Your people may already work in Claude, ChatGPT or Cursor and only need governed access to connected apps. Gold covers that, at $15 per user per month in USD, or $10 per user per month billed annually. Gold has restrictions, SSO (single sign-on) and SCIM (automatic user setup from your identity provider), and no Agent. The Agent fits when people want answers in Slack without setting up a client. If your team already runs its automations in another workflow tool, read [how Elaichi compares with other workflow tools](/blog/elaichi-vs-n8n/) first. The [Black plan overview](/blog/elaichi-black-plan/) sets the Agent beside workflows and spend controls. To see which apps the Agent can reach, browse the [connector catalog](/connectors/). ## FAQ ### Which plan includes the Elaichi Agent? The Elaichi Agent comes with the Black plan, including the 14-day Black trial. Every new workspace starts on that trial, with no card. Personal and Gold workspaces do not get the Agent. Their people reach their connected tools from Claude, ChatGPT, Cursor or any MCP client instead. ### Does Elaichi supply the AI model for the Elaichi Agent? No. The Elaichi Agent runs only on AI provider keys the organization adds in Settings > AI models. Keys can come from Anthropic, OpenAI, Fireworks AI, OpenRouter or an OpenAI-compatible gateway. Elaichi supplies no model key. A turn with no usable key fails with a message that points to Settings > AI models. ### Can the Elaichi Agent change data without asking? Reads run without a card. A write stops at an approval card unless the person already chose Always allow for that action. A delete called directly asks every time. In Slack, the card has only Approve and Deny, and only the person who asked can press them. The Agent never approves a workflow step, an access request or a payment. ### How do you set up the Elaichi Agent in Slack? An admin who holds assistant:manage connects the Slack workspace in Settings > Organization > Slack. After that, people tag @Elaichi in a channel, a direct message or Slack's agent panel. Elaichi matches each Slack user to an Elaichi member by email. That member needs the tool:execute permission. ### Can the Elaichi Agent search the web? No. The Elaichi Agent has no built-in web search or web fetch tool, and Elaichi does not browse the web for it. It works with the apps your organization connected, and with Elaichi's own workflows, collections, dashboards and knowledge bases. ## Read next - [Human approval for AI agent actions: the layers](/blog/human-approval-for-ai-agent-actions/) — Human approval for AI agent actions comes in layers: a prompt for the person asking, then the role rules, frozen values and requests an admin decides. - [What an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) — An AI agent audit log must capture who acted, which client called, which account was reached, what was tried and how it ended. Argument contents stay out. - [Connect Elaichi to Claude](/blog/connect-elaichi-to-claude/) — To connect Elaichi to Claude, add one URL as a custom connector and sign in with OAuth. On Team and Enterprise, an Owner adds it once for everyone.