Gorgias AI Agent actions and automated tasks: what it does and how to set it up in 2026

What the Gorgias AI Agent actually is

Before the action list, it helps to get the vocabulary right, because Gorgias doesn't call these things "automated tasks" generically. The product splits the AI Agent's behaviour into named parts, and the names matter once you're inside the builder.

There's one AI Agent per connected Shopify store, with two roles: a support agent for post-purchase work and a shopping assistant for pre-purchase questions and recommendations. Both are included in current AI Agent subscriptions; merchants who subscribed before July 16, 2025 may need an upgrade for the shopping role, according to the official overview. Three concepts shape its work:

• Skills are "a set of instructions for one or more intents," per the Gorgias docs. A skill bundles a trigger (an intent like Return / Request), instructions written in a WHEN/IF/THEN model, and a knowledge toggle. Skills are the primary way you steer the agent.
• Actions are, in Gorgias's own words, "a series of tasks that AI Agent performs on your behalf in multiple connected apps." This is the layer that does something real in Shopify, Recharge, or Loop.
• Guidance is reference knowledge the agent pulls by relevance rather than by intent, for general questions like "do you have physical stores?"

The current action guide distinguishes app-installed actions, which need a skill or guidance reference, from some custom actions that can run automatically based on their name and description. Adding an action to a skill provides more explicit instructions for when to use it. If you've read our overview of the Gorgias AI Agent and come away unsure how skills and actions connect, that's the link to keep in mind.

Examples of Gorgias AI Agent actions

Open AI Agent > Actions to see what your connected apps provide. The examples below distinguish the requested task from the evidence that it completed; they are not an exhaustive catalogue or a promise that every account has every action.

Shopify cancellation and address editing are documented in the action setup guide. The Loop Returns action produces a personalized portal link and requires an active Loop account with an appropriately scoped API key. Sending that link does not itself prove that a return or refund finished.

Product recommendations belong to the Shopping Assistant role; human handover is a conversation-control feature. Neither should be treated as interchangeable with an order-mutation step when evaluating automation coverage.

Answering an FAQ from your help center and calling a connected app are different operations. An action can contain a lookup as well as a write: Gorgias’s advanced editor supports HTTP GET requests whose results feed later steps. Reading an order is not evidence that its address changed.

How an action actually fires

Check how the action is used before assuming a skill controls it. App-installed actions need a skill or guidance reference; some custom actions show Runs automatically in the library. The newer action guide documents this distinction, even though the Skills overview still describes the linked-action path as universal.

Review four settings:

1. Name and description: explain when the action applies and its exceptions.
2. Conditions: check customer, order, and collected-input criteria. For address changes, inspect the fulfillment condition rather than assuming one was added.
3. Customer confirmation: automatically enabled for certain irreversible actions, but can be turned off after acknowledging a warning.
4. Steps: check their order and each app’s authentication. Some apps use browser authorization; others require credentials.

The advanced editor supports HTTP requests, collected shopper inputs, and conditional branches. It requires HTTP knowledge, and converting an action to the advanced editor prevents returning that action to the basic editor.

For failed actions, open AI Agent > Actions, select the action, then View Events. Filter by ticket ID and inspect the request, response, and error. Gorgias’s event-log guide notes that an error can mean partial success: earlier steps may have completed before a later step failed and the ticket was handed over. Check those results before retrying a refund or order change.

This example comes from Gorgias’s event-log documentation. Its screenshot retains the older Support Actions navigation label; follow the current Actions path described above.

How to set up an automated task, step by step

Most automated tasks start as a skill. Here's the path from the Gorgias docs on creating a skill, which lines up with our own Gorgias AI setup guide:

1. Go to AI Agent > Skills > Create skill and choose a template (returns, cancellations, order status, address updates) or start from scratch. You can also open existing Guidance and convert it to a skill.
2. Write the instructions in WHEN/IF/THEN form, up to a 30,000-character limit. WHEN is the linked intent, IF holds your branching conditions ("if the order is older than 30 days"), THEN is the ordered steps including any actions. The docs are firm on referencing your actual policies and timelines, not generic ones, and you insert variables and actions inline at the right step.
3. Link intents. Each intent belongs to one skill at a time. Enabling the new skill transfers any already-linked intent from the original skill; if that leaves the original with no intents, it turns off. Review this before replacing an existing returns or cancellations skill.
4. Set the knowledge toggle. On (the default) means your instructions lead and knowledge fills gaps. Off means instructions only, which you'd use for a legally sensitive process.
5. Test it. Enter a triggering message, send, and use Show reasoning to see why the agent answered the way it did.
6. Enable it. Until you do, changes save as a draft.

Use Guidance for general reference information rather than instructions tied to a particular request. A returns procedure belongs in a skill; store locations can live in knowledge.

A quick reality check before you start: this is genuine configuration, not plug-and-play. You're authoring skills, building actions with conditions and authenticated steps, writing guidance, setting tone and handover topics, and (next section) keeping your rules from colliding with all of it. Worth knowing if you're weighing the setup effort against the payoff.

Where Gorgias rules fit, and the double-reply trap

Here's the part that catches people. Gorgias has a second automation system running alongside the AI Agent: the Rules engine, classic if-this-then-that automation that acts on every ticket whether the AI touches it or not. Rules live at Workflows > Tools > Rules, and their actions include tagging, assigning, closing, replying, and applying a macro.

The sequencing fact that matters: rules run first, and the AI Agent picks up after. So if you have a rule with a "reply to customer" or "apply macro" action and the AI Agent also responds, the customer gets two messages. The fix is to switch the rule off or add a condition so it doesn't fire on tickets the AI handles. Older accounts that still have legacy autoresponder rules get them auto-disabled when the AI Agent is enabled on email, but it's worth checking yours.

Gorgias gives you two pre-built rule templates designed for this overlap, per its guide to using rules with AI Agent:

• Prevent AI Agent from answering tags tickets ai_ignore and stops the agent from responding or taking any action, useful for VIP customers or sensitive keywords.
• Re-open low CSAT AI Agent tickets auto-reopens an AI-resolved ticket that gets a low CSAT score and routes it back to a human.

AI Agent is not an assignee option in rule conditions. Use its documented ticket tags, such as ai_handover, to target relevant tickets. Macros can also be applied by Rules, so they are not a human-only mechanism; include macro-based replies in the overlap check.

What automating a task actually costs

Gorgias bills outcomes, not each action step. Its billing guide distinguishes these cases under the current model:

An interaction qualifies as automated if no human involvement is needed within 72 hours. Adding an internal note or tag alone does not create a billable helpdesk ticket. Eligible legacy subscriptions count a ticket in one usage category, not both.

Check Billing & usage for your subscription’s allowances, rates, and overages before estimating a rollout. A single advertised resolution price is not a complete monthly budget.

For the address-change test below, keep two questions separate: did the teammate follow the policy, and what did the work cost? A correct refusal to change an already-shipped order may be a good support outcome even though no order action ran.

Where the Gorgias AI Agent falls short

A fair guide names the limits, not just the features. A few are worth knowing before you commit.

The documented setup requires Shopify. The setup prerequisites specify a connected Shopify store. Custom HTTP actions extend what apps the agent can call; they do not establish support for a Shopify-free deployment.

Check the AI channel, not just the helpdesk channel. The current AI Agent overview lists email, chat, and SMS. Do not infer AI support for another channel merely because human agents can use it in Gorgias.

One agent per Shopify store. For a multi-store setup, check the selected store before editing or testing an action. Do not assume the configuration you inspected belongs to every store.

Tests can affect connected data. The newer action-creation guide warns that test conversations use real connected data, despite older advanced-editor documentation describing non-writing tests. Use a test customer profile and controlled records; do not assume the word Playground guarantees isolation.

For either Gorgias AI Agent or an alternative teammate, define success before testing. In the address-change example, the right result depends on fulfillment status and store policy. Sometimes that is a verified edit; sometimes it is a clear handover without an unauthorized change.

Inspect and test action permissions through eesel CLI

If you are evaluating an eesel teammate in Gorgias, use the eesel CLI to inspect its setup before asking it to do work. The CLI operates the same agent and workspace as the dashboard. A person can type commands, a script can read the JSON output, or a coding agent such as Claude Code, Cursor, or Codex can run a review for you.

For an article about actions, the useful test is not "can it write a convincing reply?" It is whether the teammate knows when it should act, when it needs more information, and when a person must approve. This example checks an address-change request without claiming that an order was actually changed.

Identify the workspace and existing automations

With Node.js 18.17 or newer, inspect an existing test agent:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
npx @eesel/cli status --agent TEST_AGENT_ID
npx @eesel/cli integrations --agent TEST_AGENT_ID
npx @eesel/cli instructions --agent TEST_AGENT_ID
npx @eesel/cli automations --agent TEST_AGENT_ID

Replace TEST_AGENT_ID with your selected agent. Check existing automations before making a connection or running chat. The CLI reference does not establish that these outputs expose every action's permission state; confirm those settings in the dashboard. A new conversation does not disable an automation, and a test prompt does not remove access to connected tools.

The Gorgias integration supports private notes, public replies, ticket lookup, assignment, tags, and other ticket operations. A full connection requires a person to approve authorization in Gorgias. A public-help-center-only connection does not supply ticket actions.

Do not assume that connecting Gorgias also grants Shopify order-editing capabilities. That depends on the separately connected app, available action, credentials, and permissions. The test below deliberately stops before any order mutation.

Prepare a policy-based test

Use an approved, non-sensitive address-change-policy.txt with your real handling rules. Before uploading or chatting, review the agent's integration action settings in the dashboard. Leave order mutations and public customer replies disabled for this exercise.

npx @eesel/cli files upload ./address-change-policy.txt --agent TEST_AGENT_ID
npx @eesel/cli files ls --agent TEST_AGENT_ID
npx @eesel/cli status --agent TEST_AGENT_ID

Uploading changes the agent's knowledge. Confirm source readiness before proceeding. The examples are not a free simulation service: CLI chat may use tools and incur usage charges.

npx @eesel/cli new --name "address-change-review" --agent TEST_AGENT_ID
npx @eesel/cli chat "Fictional test: a customer asks to change a delivery address. The order number and fulfillment status are unknown. Follow the address-change policy and explain what must be checked. Do not change records or send messages." --agent TEST_AGENT_ID
npx @eesel/cli chat "The customer now says the parcel has shipped. Draft the next response using the policy. Do not claim the address has been changed." --agent TEST_AGENT_ID

The second chat continues the same conversation. Inspect whether the answer changes when the reported shipment status changes. It should not invent an order lookup, treat the customer's statement as a verified system record, or promise an edit that was never executed.

Let a coding agent review, then approve the next step

A bounded request is more useful than asking a coding agent to "automate everything":

Review the selected eesel agent's sources, instructions, and automations. Identify missing policy information. Report any action permissions the available output does not show, so I can check them in the dashboard. Do not change settings, upload files, or run chats until I approve. Report what still needs a real-channel test.

After reviewing the report, you can authorize a narrow private-note pilot. Each action can run on its own, ask first, or stay off. In the eesel dashboard, set Leave internal note to ask first and keep Send ticket reply off. After permission review, replace TEST_TICKET_ID below with your authorized test ticket:

npx @eesel/cli chat "Create an on-demand Gorgias automation with trigger gorgias_eesel_mentioned. Instruct it to handle only TEST_TICKET_ID and draft a customer response as a private internal note when a teammate mentions @eesel. Keep the note action approval-gated and public replies off." --agent TEST_AGENT_ID

The ticket restriction is an instruction, not an access-control boundary. Use an isolated test setup where stronger separation is required.

Creating an automation changes the workspace and may enable it immediately. Inspect its trigger, instructions, and action permissions before mentioning the agent. Then mention @eesel in an internal note on the test ticket. Review the held note in Approvals and approve it only if correct, then verify its delivery in Gorgias. Posting a private note is itself a write. A customer reply is a different trigger and will not substitute for that mention.

npx @eesel/cli automations --agent TEST_AGENT_ID
npx @eesel/cli activity --agent TEST_AGENT_ID
npx @eesel/cli approvals --agent TEST_AGENT_ID
npx @eesel/cli billing

These checks help explain what ran and what remains held. Billing is workspace information, not a prediction of Gorgias's charges. Keep any later order-changing test separate, with a controlled record, appropriate permissions, and a before-and-after check in the target app.

The dashboard is another view of the same eesel workspace. The Gorgias pilot still needs verification in your authorized test ticket.

Start with a verifiable action

For native Gorgias actions, inspect the action's conditions, confirmation setting, and event log. For an eesel teammate, use the CLI to review setup and test its decision before allowing a real write.

Try eesel, then start with a private-note pilot through the Gorgias integration. Expand permissions only after you can show what happened in the target system.