> For the complete documentation index, see [llms.txt](https://docs.eesel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eesel.ai/instructions-and-memory/actions-and-approvals.md). # Actions and Approvals Human in the loop AI for every action: set each one to run on its own, ask you first, or stay off, and approve held actions in the dashboard, Slack or terminal. An **action** is something your AI teammate can do in a connected app. Each integration's page lists its actions. Every action runs on its own, asks you first, or stays off. You choose per agent, and you can change it any time. This is how you keep a human in the loop. An action that asks first waits for a person to approve it, so you can start with your agent supervised and hand over more as you see it get things right. ## The three settings | Setting | What happens | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **On** | eesel does it on its own, unless your instructions say to ask first in a given situation or eesel's safety check holds a risky call | | **Ask first** | A teammate approves it first, every time. Your agent prepares the action and waits | | **Off** | eesel never does it | On an integration page, each action has a menu with these three settings.
The Actions section of an integration page with the Write group open and the Close ticket menu showing three settings: On, eesel does it on its own; Ask first, a teammate approves it first, every time; Off, eesel never does it

The three settings, in an action's menu.

Actions cover things like replying to a ticket, adding a tag, refunding an order, posting to a channel or creating a Jira issue. They are a permission list, not a workflow. Turning **Add tags** on means your agent *can* tag. Your [instructions](/instructions-and-memory/instructions-and-memory.md) say when, and [automations](/automations-and-schedules/automations-and-schedules.md) say on which events. Workspaces on the older dashboard show actions differently. Most agents there see a list of enabled actions with an **Edit** button. Agents moved to the newer list see the same three settings as **Auto**, **Needs approval** and **Disabled** (**Off** on some), shown as a tick, a hand and a cross. ## Where to set them {% hint style="info" %} **Using Claude Code, Codex or Cursor?** Ask it to change an action’s permissions with [eesel CLI](https://docs.eesel.ai/apis-and-developer-resources/cli). Point it to the [setup guide](https://docs.eesel.ai/getting-started/set-up-from-a-coding-agent). **Using Claude.ai or ChatGPT?** Use the eesel connector (MCP). See [Claude and other assistants](/apis-and-developer-resources/use-eesel-from-claude-and-other-assistants.md) or [ChatGPT](/apis-and-developer-resources/use-eesel-from-chatgpt.md). If the eesel connector is already linked to the correct workspace, keep using it. For steps it cannot complete, use the dashboard. **CLI details for your coding tool:** Find the action key with `eesel integrations actions`. Then run `eesel integrations actions set --access `, choosing `on`, `ask-first` or `off`. Change only the action you want to update, then read the result to confirm its permissions. The change itself may need approval; terminal approval commands are listed below. You can also use the dashboard controls. {% endhint %} With the agent selected at the top left, open **Integrations** in the left sidebar and pick the app. The page lists **Sources**, what your agent can read, and **Actions**, what it can do. ### Sources Each source the app syncs, such as help center articles, macros or past tickets, has its own row with a document count and a switch. Turn a source off and this agent stops reading from it. The documents stay, and your other agents keep their own setting.
The Sources section of a Gorgias integration page: Help Center with 24 docs, Macros with 0 docs and Tickets with 336 docs, each switched on

Sources on a connected helpdesk.

### Actions Actions are grouped as **Read**, for looking things up, and **Write**, for changing something. Each group has one setting, and picking a setting there sets the actions in it the same way for everyone. A group shows **Custom** when its actions are not all on the same setting. Changes save as you make them. Take care with a whole group. A few read actions only work for your team out of the box without carrying a **Team only** tag, such as searching your team's Gmail or Teams messages. Turning the whole **Read** group On opens them to conversations with people outside your team too. On most workspaces, a group change leaves **Write scripts** actions and actions already set to Off as they are. Click a group to see each action in it, with its own setting.
The Write group expanded and set to Custom: Add tags, Assign to teammate, Close ticket, Create ticket, internal note actions, Send ticket reply and Update ticket fields are On, and Write scripts for Gorgias actions has a Team only tag and is Off

The Write group set to Custom: one action is off.

A few actions can't be set like the rest: * **Live chat actions**, such as replying in Zendesk Messenger or Freshchat and handing a chat to a person, are always **On**. Nobody can stop a live chat to approve a reply, so they can't be set to **Ask first** or **Off**. * Actions with a **Team only** tag only ever run for your team. See [Team only](#team-only). Or say it in chat: "look things up on your own, but ask me before any refund." Your agent changes the settings and tells you what it set. **Start supervised.** On most workspaces actions start **On**, with the safety check holding risky calls. On a HIPAA workspace there is no safety check, and most write actions start on **Ask first**. To supervise a new agent, set replies and anything irreversible to **Ask first**. Once the drafts are consistently right, turn the routine ones **On**. Keep refunds, cancellations and anything that costs money behind an approval. ## Team only **Team only** means eesel uses something only when someone on your team asks: in the dashboard, in Slack, or wherever a teammate talks to it. It never uses it when the person asking is outside your team, such as a customer in your chat bubble or on a helpdesk ticket. A teammate's internal mention on a customer's ticket counts as your team for Team only actions and files, though admin-only tools and scripts never run on a ticket, since it holds the customer's own words. Your team is the people on your **Team** page, plus the people your connected apps show are part of your company: full members of your connected Slack, users in your Microsoft Teams or Google Workspace, and anyone who writes an internal note in your connected helpdesk. * **On an action, it's a tag.** eesel adds it to actions that should only ever run for your team, such as writing scripts against an app's API, admin-only tools, and actions that change your agent's own instructions or automations. On newer workspaces, actions that change your agent's files carry the tag too, and all three run only for editors. You can still set the action On, Ask first or Off, but it never runs for anyone outside your team.
The Write scripts for Gorgias actions action with a Team only tag, and its tooltip: eesel uses it only when someone on your team asks, never for people outside your team

An action with the Team only tag, and what it means.

* **On a file, it's a setting.** On the current dashboard, each file and folder in **Files** has three buttons: a tick for **On**, people for **Team only**, and a slash for **Off**. On means eesel uses it to answer anyone, though it never sends the file itself, or a link to it, to people outside your team. Team only means only your team's questions. Off means eesel never uses it. Your agent may set a file to Team only when it saves something meant only for your team, such as internal notes, and you can change it any time.
Three files in the Files list, each with On, Team only and Off buttons. Gorgias connected brief is set to Team only, with the tooltip: Team only, eesel uses it only when someone on your team asks

A file set to Team only, and what it means.

## What an approval looks like When an action set to **Ask first** comes up, your agent stops, saves what it wants to do, and waits for a person to approve it. You see the exact action and its details, the reply text, the refund amount, the tag, and choose: * **Approve**: it runs now. * **Deny**: it does not run, and your agent carries on without it. If an action is on **Ask first**, set it to **On** on the integration page to stop being asked. An action on **On** can still be held when eesel's safety check judges a call risky. On older workspaces, the card usually also has **Always allow**, which runs it now and switches that action to **Auto** from then on. On some older workspaces, it reads **Switch to Auto** instead, and only when the action's setting caused the hold. Write scripts, locked and browser actions never offer it. **Set the agent's communication channel before you put actions behind an approval.** An agent starts on **In-app only**: a held action waits on the dashboard and nothing is sent to anyone. The exception is a run that started from Slack, Microsoft Teams, Discord, Google Chat, WhatsApp, iMessage or an email thread, where the hold goes back to that thread. Open the agent's **Settings**, find **Communication channel**, pick **Email** or **Slack**, then choose which members or channels get them. Only someone with edit access sees that setting, so a Viewer who opens **Settings** has to ask an Editor to set it. A hold does not appear in the helpdesk ticket it came from, so a team watching the ticket sees nothing, unless your agent still has one of the old draft reply actions. On the older dashboard there is no channel to pick, and the dashboard is where approvals wait. Where you decide depends on where you are: | Where | How | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Dashboard** | Pending approvals are on your agent's home page and in the run on your Activity page. Every approval also has its own page you can open from a link | | **Slack** | If the run started from Slack, an approval card lands in that thread with Approve, Deny and Review in eesel buttons | | **Email** | When the agent's **Communication channel** is **Email**, each held action is emailed to the members you picked, with a link to the run. A run that started from an email thread gets the approval emailed into that thread whatever the channel is, with a link to the approval page, when the person who emailed is an editor of your workspace. On a HIPAA workspace nothing is emailed, and the hold waits on the dashboard | | **Terminal** | `eesel approvals` lists what is waiting. `eesel approvals approve ` runs it, `eesel approvals deny ` refuses it. On older workspaces, `--always` switches the action to Auto where the card would offer it | | **Claude Code or another MCP client** | Ask in the client's chat ("approve the pending refund"), or use the terminal row above |
A Slack thread with two approval cards from the eesel app, each listing the integration, the action, the ticket and the content, with Approve, Deny and Review in eesel buttons

An approval card in the Slack thread the run started from.

Approval links can be forwarded to a teammate. Deciding still requires being signed in as an editor of the workspace. CLI and MCP requests keep the workspace role and action approval rules. Ask `eesel chat` to change instructions; use `eesel automations update` for supported settings. A held receipt means the action has not run. `eesel approvals` lists pending action decisions. A coding agent must leave decisions to the authorized person unless the user has explicitly authorized it to make that decision. A connect that comes back held may not be listed there; confirm that one with `eesel status`, and if a person needs the link to approve it in the tool, ask for it with `eesel chat "give me the connect link for "`. ## Who can approve Anyone with **edit access** to the workspace, an Owner or an Editor. See [Account](/account/account.md). Viewers see approvals but cannot decide them. In Slack, the person clicking is matched to a workspace editor by their Slack profile email. If the emails do not match, the click does nothing and the **Review in eesel** link is the way through. ## Actions and automations together An automation can only use actions that are on. If the automation's instructions say "reply to the customer" but the reply action is on **Ask first**, every reply waits for a person. If the action is **Off**, your agent says it cannot, and leaves an internal note instead if the app supports notes. To hold a specific case for approval even when the action is **On**, say so in the automation's instructions ("ask before replying to anything about refunds"), and your agent asks for that case. ## FAQ
How do I keep a human in the loop on my AI agent? Set the actions you want checked to **Ask first**. Your agent then prepares each one and waits for a person to approve or deny it before anything happens. You can also have it draft replies as internal notes, so your team sends them.
How do I make my agent ask before it does something? Open **Integrations**, pick the app, and set the action to **Ask first**. Or say it in chat, for example "look things up on your own, but ask me before any refund", and your agent changes the setting and tells you what it set.
Can I approve AI actions from Slack? Yes, when the run started from Slack. An approval card lands in that thread with Approve, Deny and Review in eesel buttons. The person clicking is matched to a workspace editor by their Slack profile email.
Who can approve my agent's actions? Anyone with edit access to the workspace, an Owner or an Editor. Viewers see approvals but cannot decide them.
Can I hold only some cases for approval? Yes. Leave the action **On** and say in the automation's instructions which cases to ask about, for example "ask before replying to anything about refunds". Your agent asks for those cases.
Can I see what was approved and by whom? Yes. Your agent's Activity page shows every action it took, and each approval shows who decided and when. From a terminal, `eesel activity` prints the same, newest first.
Do action settings apply to every agent? No. Actions are per agent. Turning a refund action On for your storefront agent does not change your internal operations agent.
What does Team only mean? eesel uses it only when someone on your team asks, never on a conversation with someone outside your team. On an action it's a fixed tag; on a file it's a setting you choose. See [Team only](#team-only).
What if nobody approves? The action stays pending for 72 hours and your agent has already moved on. Meanwhile your agent follows its instructions, usually leaving a note that a person will follow up. After 72 hours the approval expires and can no longer be decided; your agent can ask again if the action is still needed. Approvals never run on their own after a timeout.
## Related pages * [Instructions and Memory](/instructions-and-memory/instructions-and-memory.md) for when your agent should use what it is allowed to do * [Automations and Schedules](/automations-and-schedules/automations-and-schedules.md) for which events it runs on * [Integrations overview](/integrations/overview.md) for each app's actions * [The eesel CLI](/apis-and-developer-resources/cli.md) for `eesel approvals` * [Use eesel from Claude and other AI assistants](/apis-and-developer-resources/use-eesel-from-claude-and-other-assistants.md) and [Use eesel from ChatGPT](/apis-and-developer-resources/use-eesel-from-chatgpt.md) to work with your agent from a chat assistant --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.eesel.ai/instructions-and-memory/actions-and-approvals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.