Why build a custom support agent instead of using Intercom Fin or Freshdesk Freddy?

Use the vendor's agent if your tickets are answered by your help centre alone and you only need it inside that vendor's console. Build custom when resolving a ticket means acting in other systems (refunds, trials, bug reports, notifications), when you want the agent on your own site or inside your product, when you need to choose or swap the model, or when you want every action traceable and rehearsable before it goes live. The custom route costs more up front and less per ticket, and you own it.

How does the agent avoid making things up?

It is only allowed to state product specifics that appear in an article it retrieved, and it includes the article's URL in the reply. When retrieval finds nothing relevant, the rule is to escalate, not to approximate. That rule lives in the system prompt and is enforced by what the tools will and won't do.

Which helpdesk and chat systems can you connect to?

Any with an API. The production build connects Freshdesk, Freshchat, a first-party widget, FastSpring, monday.com and Slack, but the adapters are thin and the agent loop doesn't know which vendor it's talking to. Zendesk, Intercom, HubSpot, Help Scout, Stripe, Chargebee, Linear, Jira, GitHub and Teams are the same shape of work.

What happens when the agent gets a ticket wrong?

Every run is recorded with its full tool trace. Any ticket can be replayed in dry-run to see exactly what the agent would do. Wrong outcomes go onto a gap list that becomes the queue for new documentation, so the same question is answerable next time.

AI support agents

An AI support agent from Mytrya is a service that works wherever your customers already write to you: inside your helpdesk, in your live chat, and as a chat widget on your own website or inside your product. It answers what your documentation already covers, checks the customer's account and your dev tracker before it speaks, takes actions in connected systems, and hands the rest to a person with a written summary.

It fits your stack rather than the other way round. The helpdesk can be Freshdesk, Zendesk, Intercom, HubSpot, Help Scout or anything with an API. The chat can be the vendor's or a widget I build for you, which no vendor holds and which escalates by opening a ticket where your team already works.

The platform I run in production today works three channels with 20 tools across the helpdesk, live chat, billing, the dev board and Slack. On tickets it drafts and a person sends; on the widget it answers live and is reviewed afterwards. It reads back what the team actually sent, judges it blind against its own draft, and turns the difference into learnings a person approves.

Start a project See it built

A good fit when

You run a B2B product with a helpdesk and a knowledge base that already answers most questions, and a person still has to find and relay the answer.
Resolving a ticket often means touching another system: issuing a refund, extending a trial, opening a bug for the dev team, notifying a channel.
You want to choose the model, keep the data in your own accounts, and see every action the agent takes before it takes it.
You want the agent on your own website or inside your product, not only inside a vendor's console, and you want your team's replies to make it better without anyone filling in a rating.

Not the right call when

You only need answers from a help centre inside one product, with no actions in other systems. Intercom Fin or Freshdesk Freddy will be faster to switch on and cheaper to run. I will say so on the call.
Your documentation doesn't exist yet. An agent grounded in nothing has nothing to say. Writing the first 30 articles is a different project, and sometimes a better first project.

What gets built

12 parts

Channel adapters for your helpdesk, your live chat and, if you want it, a first-party chat widget with streaming, file uploads, signed sessions and an origin allowlist
Webhook intake with idempotency, so a retried event can't produce two replies, and a cheap deterministic filter that drops out-of-office replies, bounces and newsletters before the model runs
Context assembly from the ticket, the conversation, the billing account and any linked tracker items, before the model sees anything
Retrieval over your knowledge base with a reranker and a keyword fallback; a KB store with draft, review, published and archived states, versions, and a daily sync from your docs site
Draft mode: the reply is posted as a private note, a person sends it, and the outcome is read back from what they sent
A tool layer for the systems the agent may act in, with each tool's inputs sourced from context rather than from the model
Escalation to Slack or email with a private note on the ticket
A scheduled follow-up that re-reads the ticket after 24 hours and closes or re-runs
An admin console for replaying any ticket in dry-run and reading the full tool trace
Outcome recording: resolved, escalated, reopened, and a list of questions the agent couldn't answer, which becomes your documentation backlog
A learning loop: a blind judge compares your team's reply to the draft, a distiller proposes learnings, a person approves them before they reach the prompt
A Slack interface for the team, with money-moving commands behind a second admin's confirmation, and a morning brief with emerging issues computed by arithmetic

How it's kept safe

Product specifics come only from a retrieved article, and the reply cites it. No article, no answer; the ticket escalates.
Dry-run is the default state. Writing to external systems is a flag you turn on per integration.
Ticket and account identifiers are read from context, never from model output, so a hallucinated ID has nowhere to go.
Internal links and tracking notes go into private notes. Customer-facing replies never carry them.

Typical stack

Next.js on Vercel or Cloudflare
Vercel AI SDK
Claude, Gemini or OpenAI models, chosen per task and measured
Upstash Redis and Vector, or Postgres with pgvector
Your helpdesk, chat, billing, tracker and messaging APIs, whichever they are

Built and running

2 case studies

Questions about this service

Why build a custom support agent instead of using Intercom Fin or Freshdesk Freddy?: Use the vendor's agent if your tickets are answered by your help centre alone and you only need it inside that vendor's console. Build custom when resolving a ticket means acting in other systems (refunds, trials, bug reports, notifications), when you want the agent on your own site or inside your product, when you need to choose or swap the model, or when you want every action traceable and rehearsable before it goes live. The custom route costs more up front and less per ticket, and you own it.
How does the agent avoid making things up?: It is only allowed to state product specifics that appear in an article it retrieved, and it includes the article's URL in the reply. When retrieval finds nothing relevant, the rule is to escalate, not to approximate. That rule lives in the system prompt and is enforced by what the tools will and won't do.
Which helpdesk and chat systems can you connect to?: Any with an API. The production build connects Freshdesk, Freshchat, a first-party widget, FastSpring, monday.com and Slack, but the adapters are thin and the agent loop doesn't know which vendor it's talking to. Zendesk, Intercom, HubSpot, Help Scout, Stripe, Chargebee, Linear, Jira, GitHub and Teams are the same shape of work.
What happens when the agent gets a ticket wrong?: Every run is recorded with its full tool trace. Any ticket can be replayed in dry-run to see exactly what the agent would do. Wrong outcomes go onto a gap list that becomes the queue for new documentation, so the same question is answerable next time.

Next step

Have a process that runs on someone copying data between two tabs?

Describe it: what it is, who does it, how often, and what goes wrong when it's late. I reply within one working day with a scoping call or a reason it isn't worth automating.

Start a project How a project runs

Free 30-minute call · one working day