Freddy AI Agent knowledge sources: setup and testing

Which knowledge sources does Freddy support?

Freshworks' knowledge configuration guide, updated August 2026, covers AI Agent Studio for Freshdesk Omni and Freshchat. Confirm your account type before applying these limits to a different Freshworks product.

The URL limit is not the same as the number of pages the crawler may read. Plan around both rather than assuming that ten configured URLs means only ten individual pages.

The Knowledge interface from Freshworks' documentation, showing source types and learning status.

An administrator opens the selected agent's Build > Knowledge area to manage sources. The documentation also describes source-level filtered search rules and visibility into learning status, sync time and extracted content.

For anything behind a login, do not assume the public crawler can retrieve it. More importantly, do not publish private material just to make an AI integration work. Decide what the agent should know and who should be allowed to receive that information.

Prepare knowledge for the questions people actually ask

I would start with a small group of common questions rather than uploading the largest possible collection. For each question, identify the current approved document and the information needed to apply it.

Suppose your support team answers subscription questions for two products. Both documents may be accurate, but the wrong product's policy still produces the wrong answer. Clear product names and scope matter as much as grammatical clarity.

Use this preparation checklist:

This is not a requirement to rewrite every article before starting. It is a way to find the documents most likely to cause an incorrect answer. Fix the material that your first test cases actually depend on.

Avoid unsupported absolutes such as “AI cannot understand nuance.” The useful question is whether the source communicates the rule well enough for your particular agent to apply it consistently.

Also separate historical examples from current policy. An old support ticket may describe a one-time exception or a procedure that has since changed. Treating every past resolution as the rule can reproduce a decision your team would no longer make.

Test Freddy knowledge before deployment

The AI Agent setup guide includes testing, preview and deployment as distinct steps. It also supports sharing a preview for stakeholder feedback. Preview does not perform agent transfers for unanswered queries or requests for human help, so it is not a complete handoff test.

That is a more useful distinction than “reactive versus proactive.” You need tests before rollout and reviews afterward, regardless of the vendor.

A simple knowledge test set should include:

• A question the selected source answers directly.
• A question that needs a product or region clarified.
• A question outside the source's scope.
• A question whose answer changed in a recent approved update.

Write the expected behavior before running the test. For an unanswered question, the passing behavior might be to acknowledge missing information or ask a useful follow-up, not to produce an answer at any cost.

Keep answer correctness separate from a successful workflow. An agent can explain how to request a cancellation without actually cancelling anything. If the test involves a real action, use authorized test records and verify the result in the connected system.

Where eesel CLI fits for Freshdesk teams

An eesel Freshdesk teammate is a separate agent you can evaluate alongside Freddy. Its knowledge and instructions belong to the eesel workspace; they are not a remote editor for AI Agent Studio.

The Freshdesk integration offers a public-help-center quick start and a full connection. The full connection uses a Freshdesk subdomain and API key, and supports tickets and canned responses as knowledge in addition to the help center.

Use the secure form supplied during setup for the API key. Do not paste it into a chat message, terminal command example, shared prompt or repository. Confirm the sources and document counts after connection rather than assuming authorization means everything has finished syncing.

Other supported sources can contribute to the same eesel teammate, such as selected wiki content or uploaded files. That does not mean unlimited content, instant synchronization or permission to expose every source to every customer. Each connector has its own requirements.

The eesel CLI makes this setup inspectable from a terminal. It returns JSON for single results and one JSON object per line for lists, so scripts and coding agents can work with the output directly.

Inspect Freshdesk knowledge through eesel CLI

Use Node.js 18.17 or newer. Log into the intended existing workspace and list its agents:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

Create or select a separate test agent in the dashboard. Replace TEST_AGENT_ID with its actual ID. Set up its approved Freshdesk knowledge using the documented connection flow, then inspect it:

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

These checks help distinguish missing content from a behavior problem. If you expected canned responses but chose quick start, another prompt will not make that source available. If the correct material is present, inspect the rules guiding the answer.

Before a test, restrict actions and inspect any existing automations. A separate test conversation does not remove the agent's access to tools or stop other enabled workflows.

Add one approved document and test its scope

If you need a small supplemental source, prepare product-scope.txt on your computer. Put only approved facts in it, such as which product supports a feature and any relevant plan requirements.

npx @eesel/cli files upload ./product-scope.txt --agent TEST_AGENT_ID
npx @eesel/cli files ls --agent TEST_AGENT_ID

The upload supplies knowledge. It does not change the teammate's instructions or permissions. Review standing rules separately if you need it to ask for a product name before answering.

Now adapt this fictional test to a feature actually described in your file:

npx @eesel/cli new --name "Product knowledge scope test" --agent TEST_AGENT_ID
npx @eesel/cli chat "Fictional support test: Does my subscription include this feature? Use product-scope.txt. Ask for any missing product or plan details instead of assuming them. Do not look up a real customer or change anything." --agent TEST_AGENT_ID
npx @eesel/cli activity --agent TEST_AGENT_ID
npx @eesel/cli billing --agent TEST_AGENT_ID

These are example commands, not reported results. Name the feature when adapting the prompt. The expected behavior is to resolve missing context before applying a product-specific rule.

The new command starts a conversation, not a new agent. It avoids carrying the previous test's answers into the next case. It does not isolate permissions.

Chat can invoke tools and incur usage charges. A request not to change anything is not an access control; keep unnecessary actions off and inspect activity. Billing shows current usage, not what a future batch of questions will cost.

Let a coding agent help with inspection

You can give a coding agent a task such as:

Use eesel CLI to inspect the selected test agent's sources and instructions. Check whether the setup contains the product and plan information needed for my test. Report missing setup and propose changes; do not modify settings or send test messages until I approve them.

That is a concrete use of agent-friendly access. The coding agent helps operate an existing support teammate rather than becoming the support agent itself.

After approving a change, use --dry-run where appropriate to preview the server call a write would make. That is not an answer-quality simulation or a forecast of resolution rate.

Diagnose the failure before adding more content

More documents can help when the answer is missing. They can also add conflicting evidence when the problem is source selection.

These are diagnostic starting points, not guaranteed causes. Inspect the evidence before changing the setup.

For an eesel rollout, private-note drafts provide a way for your team to review output inside Freshdesk. Confirm the customer-reply action is off if the test is meant to stay private. Source access alone does not prove that the live workflow has the right permissions.

Choose the knowledge workflow you can maintain

Freddy offers native knowledge management and pre-deployment testing. If those capabilities fit your sources and channel requirements, test that setup fairly.

If you want an eesel teammate using Freshdesk and other approved knowledge, try eesel and use the CLI to inspect source readiness and evaluate a few well-defined questions.

The same eesel teammate can be managed in the dashboard or operated through the CLI.

Keep pricing separate from the knowledge comparison. Review your Freshworks product's current quote and eesel's usage pricing; do not infer total cost from a file limit or a successful test.

The goal is a maintained set of sources that produces appropriate answers, not the largest document count. Check the source, test the response, and verify the actual channel before expanding the rollout.