
Connecting an AI agent to Freshdesk is not the same as allowing it to reply to customers. The connection gives it access; its knowledge, triggers, and action permissions determine what it does with that access.
I would separate those decisions before choosing a product. This guide covers Freshworks' native email route and a private-note pilot using eesel CLI. The CLI examples are a proposed workflow, not results from an executed customer test.
Method 1: Configure Freshworks' native Email AI Agent
For a Freshdesk ticket-inbox workflow, follow the current Email AI Agent guide, not a chat-widget tutorial. Its eligibility table includes Growth, Pro, and Enterprise; verify your account's AI entitlement and billing separately.
As an administrator, open AI Agent Studio, choose Create new, then Email AI Agent. Add knowledge under Build, configure instructions and handover behavior, and test before deployment. Sources include solution articles, files, URLs, and Q&A. Use portal filtering when mailbox-specific brand knowledge must stay separate.

Preview accepts an email subject and body; evaluation supports batches of up to 50 queries. Inspect citations and follow-up handling, not just whether a response was generated.
On Deploy, select ticket sources and a restricted deployment strategy. Confirmation activates the agent immediately for new tickets, not earlier ones. Each source can have only one active AI Agent, so check existing assignments first.
This is different from deploying a chat agent to a widget or messaging channel. For that workflow, use Freshworks' chat agent instructions.
Before a live rollout, decide who will review failed answers and how your team will pause the agent. Treat the test set as evidence to inspect, not as a guarantee that every future ticket will be handled correctly.
Method 2: Connect and test your Freshdesk teammate through eesel CLI
The eesel CLI lets you operate the same eesel teammate and workspace you use in the dashboard. A person can work from a terminal, a script can collect configuration checks, and a coding agent such as Claude Code, Cursor, or Codex can help run the setup. Commands return JSON so the coding agent can inspect results instead of guessing whether a connection succeeded.
For Freshdesk, connecting and replying are separate steps. Start by checking access and knowledge. Then test the proposed answer. Finally, allow a private-note draft on a controlled ticket before considering customer-facing replies.
1. Inspect the selected teammate
With Node.js 18.17 or newer, sign in and inspect the workspace:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
npx @eesel/cli integrations --agent TEST_AGENT_ID
npx @eesel/cli status --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 the teammate you intend to configure. Selecting an agent is not a sandbox. Check existing automations and action permissions before connecting an account, especially if that teammate already handles another support channel.
2. Choose the connection you actually need
The Freshdesk integration guide distinguishes two options:
| Connection | What it provides | What it does not provide |
|---|---|---|
| Quick start | Public help-center content from your Freshdesk subdomain | Tickets, canned responses, triggers, or actions |
| Full connection | Help center, canned responses, resolved or closed ticket history, and ticket triggers/actions | Automatic permission to send replies without the corresponding configuration |
For a full connection, review which account's API key you will use and what content it exposes. Check your workspace's PII-redaction setting before importing ticket history; the documented default varies by workspace. Redaction is a setting to verify, not a reason to skip a source review.
If Freshdesk is not already connected:
npx @eesel/cli integrations connect freshdesk --agent TEST_AGENT_ID
Follow the returned setup instructions for the subdomain and API key. Use the secure form for the key. Do not paste it into an ordinary chat message, a coding-agent prompt, or an example command stored in your repository. This is an API-key connection, not a one-click Marketplace installation.
3. Confirm source readiness
Full connection starts reading Freshdesk content. Check source counts and sync status rather than treating “connected” as “ready to answer”:
npx @eesel/cli integrations download list --agent TEST_AGENT_ID
npx @eesel/cli status --agent TEST_AGENT_ID
In the dashboard, Integrations > Freshdesk lists Help Center, Canned Responses, and Tickets with their individual toggles and counts. If an approved source still needs a download or re-sync, inspect the CLI's current download help and use the source identifiers it returns. Do not start a broad import solely to make an empty count disappear.

Review whether old resolved tickets conflict with the current policy. Historical replies can explain how your team handled a case, but they should not overrule today's published procedure.
4. Test a proposed answer with writes disabled
Before these chats, disable customer replies and ticket-changing actions in the dashboard. That includes internal notes during the initial content test. The commands below do not turn those permissions off for you.
npx @eesel/cli new --name "freshdesk-duplicate-charge-pilot" --agent TEST_AGENT_ID
npx @eesel/cli chat "Fictional test: a customer sees two card charges for one order. Use the approved billing policy and canned responses to propose a reply for human review. Cite the source, distinguish a pending authorization from a settled charge, and identify missing evidence. Do not read a real customer's records, post a note, send a reply, or change a ticket." --agent TEST_AGENT_ID
npx @eesel/cli chat "The customer says both charges are settled. Revise the proposed response using the policy. Do not claim a refund was issued or request full card details. Explain what a human needs to verify next." --agent TEST_AGENT_ID
The second message continues the same CLI conversation. Check the source, wording, and next step. If the policy does not explain settled duplicate charges, the useful result is a clear handoff, not an invented refund promise.
These chats are billed work. They test the answer, not Freshdesk webhook delivery or whether the message lands as a private note.
5. Pilot a private-note workflow in Freshdesk
Once the content test passes, keep Send ticket reply disabled. Set Leave internal note to ask for approval, and keep unrelated ticket changes off. In particular, leave Merge tickets off: Freshdesk merges cannot be undone.
Configure one Freshdesk automation for a controlled test ticket. Call @eesel in an internal note is useful for on-demand testing; a new-ticket trigger is a different event. Choose the event deliberately, describe the permitted pilot tickets in its AI filter, and review the instructions before enabling it. The documented chat-created automation is switched on when created, so do not request one until its scope and permissions are ready.
For the on-demand trigger, have an authorized teammate mention @eesel in an internal note on a fictional test ticket. Review the proposed private note and destination, approve that one action, then check the ticket in Freshdesk.
| Check | What should be true |
|---|---|
| Event | The expected mention or ticket event reached the selected automation |
| Scope | The intended pilot ticket was handled; an out-of-scope test was skipped |
| Content | The note uses the approved policy and does not promise an unperformed refund |
| Visibility | The result is a private internal note, not a customer reply |
| Control | Customer sending and unrelated ticket changes remain disabled |
A private-note draft is still a write to a real helpdesk. It is not an unsaved reply-box draft, and approving it does not send it to the customer. Your human teammate reviews the note and decides what to send.

6. Inspect activity before expanding
npx @eesel/cli activity --agent TEST_AGENT_ID
npx @eesel/cli approvals --agent TEST_AGENT_ID
If nothing happens, check the trigger, filter, enabled actions, and Freshdesk plan support for the needed webhooks. The integration documentation specifically warns that legacy Sprout/free-plan triggers do not work. Do not assume every plan supports the same event delivery.
A held action has not executed. Inspect both eesel Activity and the actual Freshdesk ticket to distinguish a skipped event, a pending approval, and a posted private note. A new-ticket automation does not automatically cover ticket updates; those require their own trigger setup and test.
A coding agent can help collect these checks from JSON output. Give it a bounded brief: inspect first, propose changes, and wait for approval before connecting, importing, running billed chats, creating automations, or changing permissions.
Choose the workflow, then expand it
Use the native Freshworks option when it fits the channel and controls you need. Evaluate an eesel teammate when you want it working inside your existing Freshdesk queue, with configuration and inspection available through the CLI as well as the dashboard.
Try eesel with one documented billing question and a private-note pilot. Expand to customer replies only after you have checked the answer, event scope, and actual ticket result.
Frequently Asked Questions
Does connecting eesel to Freshdesk start replying automatically?
What is the difference between Quick start and Full connection?
Can I set up the same teammate from a coding agent?
Does a private-note draft send an email to the customer?
Can every Freshdesk plan run eesel ticket triggers?

Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.







