How do I set up an AI agent in Freshservice? A step-by-step guide

Step 1: Identify the agent and confirm access

Freshservice now documents both Studio and Classic. The Studio FAQ describes the promotional access above and says Studio is unavailable in MSP mode. Check your account's entitlement rather than following an older Enterprise-only tutorial.

Studio access can be granted through the Manage AI Agent Studio role permission. There is an important visibility consequence: the Studio introduction says users with Studio access can view all AI conversation logs across the workspace. Conversation logs do not currently have role-based restrictions. Give this permission only to people who need that visibility.

For this guide, I use a support-portal pilot as the concrete deployment example. Decide who owns the pilot, which requests it covers, and who reviews a failed answer before changing the channel configuration.

Steps 2–4 cover Studio. If you are configuring Classic, use its channel controls in Step 5 and follow the channel-specific documentation.

Step 2: Prepare knowledge and permitted workflows

Studio provides ready-made IT and HR agents as well as a no-code builder. Its documented knowledge options include files, URLs, the knowledge base, service catalog, and external connectors. Actions run through configured workflows.

For a concrete starting point, follow the pre-built agent guide: open AI Agent Studio > AI agents, find the IT Agent under Explore pre-built AI agents, inspect its workflows and apps, then select Use Agent. Under Build, add your knowledge sources and review instructions and workflows. App credentials are not supplied by the template. Disable workflows outside the pilot, especially device or identity changes, before connecting production accounts or testing.

Start with one approved procedure, such as shared-folder access. Check the actual source, its current version, and who is allowed to read it. Then decide whether the agent should only explain the request process or also perform an action. Those are different permissions.

Check which file types your selected source supports, then verify the relevant text appears in test answers. A connected source count is not proof that the relevant paragraph was read correctly.

Step 3: Test before choosing a live audience

Freshservice recommends preview and batch testing before portal deployment. Prepare a normal request, an exception, and a question outside the documented policy.

This is a proposed acceptance checklist, not a report of measured results. If the pilot includes workflows, inspect the resulting record or external action separately. A useful answer and a successful system change need different evidence.

Step 4: Deploy Studio to a portal test group

The portal deployment guide requires a built and tested agent, Studio admin access, and an active support portal.

Freshservice's portal setup example shows Create test group before deployment. The agent is still labeled Draft.

1. Open the agent in AI Agent Studio.
2. Select Deploy, then Support portal.
3. Choose Deploy to specific users first.
4. Select Create test group, choose existing portal users, and save with Done.
5. Review the audience and select Deploy.

Deploy makes the agent available to that group immediately. It is a live limited rollout, not an offline simulation. Have reviewers ready to check the responses and any permitted workflow results.

When the pilot passes your criteria, use the full-audience deployment option. If it needs to stop, Deactivate AI agent stops portal responses while retaining its configuration. Verify the portal behavior after either change.

Step 5: Check channel conflicts and Classic settings

The coexistence guide explains that Studio and Classic can exist in one account, but cannot both occupy the same channel. An active deployment can gray out the other agent's channel control.

The message in Freshservice's documentation explains why this control is unavailable. Check the active deployment before replacing it.

For Classic, go to Admin > Freddy and inspect the collaboration-app and Support Portal toggles. Read any message under a disabled toggle before treating it as a missing entitlement. For Slack or Teams, follow the corresponding channel setup and check the existing ServiceBot configuration.

Write down which agent owns each channel before changing it. That makes it easier to diagnose a disabled control and avoids unintentionally replacing a working employee-support path.

Step 6: Confirm the billing model and monitor the pilot

The Classic pricing FAQ includes 1,200 annual sessions per Enterprise license, prorated for the billing cycle. A session is a unique user's interaction within a 24-hour window. Classic continues operating beyond its allowance and incurs overage charges.

That is not a universal 1,200-session account cap, and it is not Studio's post-promotion price. Ask your account manager for the relevant commercial terms. Admins can check Classic usage under Plans and Billing > Freddy AI Agent.

Alongside usage, review wrong answers, repeated requests, and handovers. Fix the underlying source or workflow, then rerun the failed case before widening access. For additional budgeting context, see the Freshservice AI cost guide.

Set up an alternative IT teammate through eesel CLI

An eesel helpdesk teammate can answer from the knowledge you give it and work through configured channels and actions. The eesel CLI operates that same teammate and workspace as the dashboard. You can use it yourself in a terminal, script the setup, or ask Claude Code, Cursor, or Codex to help inspect it. Commands return JSON so a coding agent can read the results and identify the next step.

For a Freshservice team, I would separate two setup questions: can the teammate follow your IT procedure, and can it participate in your actual ticket workflow? The first can be tested with an approved file. The second requires verified integration and authorization.

Inspect the teammate before adding knowledge

The eesel dashboard is another way to manage the teammate the CLI operates. This is a Zendesk example, not a Freshservice connection.

With Node.js 18.17 or newer:

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 the teammate you intend to evaluate. Check existing automations and dashboard permissions before running tests. An agent selection is not a sandbox, and existing connections may already allow changes to other systems.

Choose a current, approved IT runbook. For example, use your procedure for requesting access to a shared folder. Check for an existing version first and resolve conflicting instructions. Remove unnecessary personal information and credentials before uploading it:

npx @eesel/cli files upload ./approved-shared-folder-access.pdf --agent TEST_AGENT_ID
npx @eesel/cli files ls --agent TEST_AGENT_ID

This adds knowledge to the workspace; it is not a temporary attachment used only in the next chat.

Test an access request and a contractor exception

In the dashboard, disable outgoing messages and system-changing actions for the selected agent before running these chats. The commands below do not change those permissions.

npx @eesel/cli new --name "shared-folder-access-pilot" --agent TEST_AGENT_ID
npx @eesel/cli chat "Fictional test: an employee needs access to the finance shared folder. Use the approved access runbook to explain the request process, name the required approval if documented, and cite the source. Do not grant access, create a ticket, or contact anyone." --agent TEST_AGENT_ID
npx @eesel/cli chat "The requester now says they are an external contractor and need access urgently. Recheck the procedure. Do not treat urgency as approval or invent an exception. If contractor access is not covered, say what is missing and prepare a summary for human review." --agent TEST_AGENT_ID

The second message continues the same conversation. It checks whether the teammate revises its advice when the requester's eligibility changes. Compare the output to the runbook itself, not just to whether the answer sounds reasonable.

These are proposed test cases, not reported results. CLI chats are billed work. Starting a new conversation does not disable tools, and a prompt asking the agent not to act does not replace permission controls.

Treat Freshservice connectivity as a separate setup

The current eesel documentation index lists Freshdesk, but I did not find a built-in Freshservice connector there. They are different products. Do not substitute a Freshdesk connection command and assume it connects Freshservice.

Eesel's Network Access guide describes a general way to call external APIs using an allowed domain and stored authentication headers. That does not establish a ready-made Freshservice integration, automatic ticket sync, or an event trigger.

If your pilot needs live Freshservice data, have an administrator verify the deployment's API authentication, account permissions, and supported operations first. Start with a narrowly authorized read-only lookup if feasible. Store secrets in the designated settings fields, never in chat or a coding-agent prompt. Allowing a domain does not restrict its API to reads; external permissions and workflow controls still matter.

Before enabling writes, verify the intended record, exact change, approval behavior, and result in Freshservice. Check the real trigger and handover destination separately. A correct answer from an uploaded PDF proves none of those integration steps.

Let a coding agent prepare the plan

A bounded starting brief is:

Inspect the selected eesel teammate's sources, instructions, and automations. Propose a shared-folder access pilot using the approved runbook, including a contractor exception. List any missing integration requirements. Do not upload files, run chats, change permissions, connect accounts, or create automations until I approve.

After approving specific tests, you can ask the coding agent to collect the outputs and flag discrepancies. Review activity and held actions yourself:

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

A pending approval is not a completed action. If you later authorize a write, verify its actual destination result rather than relying on a successful chat response.

Try eesel by testing one approved IT procedure through the CLI. Expand to connected workflows only after the knowledge, permissions, and handover checks pass.