> 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

Every action your agent can take is set to run on its own, ask a person first, or stay off. Here is where that lives, what an approval looks like, and how to decide one from anywhere.

An **action** is something your agent can do in a connected tool: reply to a ticket, add a tag, refund an order, post to a channel, create a Jira issue. Each integration's page lists its actions.

Every action has one of three settings:

| Setting            | What happens                                                                             |
| ------------------ | ---------------------------------------------------------------------------------------- |
| **Auto**           | Runs on its own, unless your instructions say to ask first for that case                 |
| **Needs approval** | The agent prepares the action and a person approves or denies it before anything happens |
| **Disabled**       | The agent can't use it at all                                                            |

Actions are a permission list, not a workflow. Turning **Add tags** on means the 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. This page is about the permission.

## Where to set them

Open your agent, then **Actions** in the left sidebar. Every connected tool's actions are listed with the three settings as buttons; a tool's group can be set in one go, and shows "Custom" when its actions differ. Changes save as you make them.

Or say it in chat: "let it look things up on its own, but ask me before any refund." Your agent changes the settings and tells you what it set. From a terminal, the same sentence works through `npx @eesel/cli chat "..."`.

{% hint style="info" %}
**Start supervised.** New agents are safest with replies and anything irreversible on **Needs approval**. Once the drafts are consistently right, move the routine ones to **Auto** and keep refunds, cancellations and anything that costs money behind an approval. It's how most teams roll out, and nothing reaches a customer until you say so.
{% endhint %}

## What an approval looks like

When an action set to **Needs approval** comes up, the agent stops, saves what it wants to do, and tells whoever can decide. You see the exact action and its arguments (the reply text, the refund amount, the tag) and choose:

* **Approve**: it runs now.
* **Always allow**: it runs now, and that action switches to **Auto** from then on.
* **Deny**: it doesn't run, and the agent carries on without it.

The decision is final either way; the agent resumes on its own.

Where you decide depends on where you are:

| Where                                 | How                                                                                                                                                                                          |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Dashboard**                         | Pending approvals are on your agent's home page, and every approval 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. Only workspace editors can decide; the button won't act for anyone else |
| **Email or a helpdesk note**          | The agent's note or email includes a "Review and decide this action" link to the approval page                                                                                               |
| **Terminal**                          | `npx @eesel/cli approvals` lists what's waiting; `approve <id>` (add `--always` to switch it to Auto), `deny <id>`                                                                           |
| **Claude Code or another MCP client** | Ask in the `chat` tool ("approve the pending refund"), or use the CLI row above                                                                                                              |

Approval links are signed and can be forwarded to a teammate; deciding still requires being signed in as an editor of the workspace.

## Who can approve

Anyone with **edit access** to the workspace (an Owner or Editor; see [Account](/account/account.md)). Viewers see approvals but can't decide them. In Slack, the person clicking is matched to a workspace editor by their Slack profile email; if the emails don't 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 **Needs approval**, every reply waits for a person; that's the intended way to run a new automation for its first week. If the action is **Disabled**, the agent will say it can't, and leave an internal note instead where the tool has one.

To hold a specific run for approval even when the action is on **Auto**, say so in the automation's instructions ("ask before replying to anything about refunds"), and the agent asks for that case.

## FAQ

<details>

<summary>Can I see what was approved and by whom?</summary>

Yes. The agent's activity shows every action it took, and approvals show who decided and when. `npx @eesel/cli activity` prints the same, newest first.

</details>

<details>

<summary>Does "Always allow" apply to every agent?</summary>

No. Actions are per agent. Allowing a refund action on your storefront agent doesn't change your internal-ops agent.

</details>

<details>

<summary>What if nobody approves?</summary>

The action stays pending and the agent has already moved on. The customer gets whatever the instructions say to do meanwhile (usually a note that a person will follow up). Approvals never run automatically after a timeout.

</details>

## Related

* [Instructions and Memory](/instructions-and-memory/instructions-and-memory.md), when the agent should use what it's allowed to do
* [Automations and Schedules](/automations-and-schedules/automations-and-schedules.md), on which events
* [Integrations overview](/integrations/overview.md), each tool's actions


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.eesel.ai/instructions-and-memory/actions-and-approvals.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.