An AI support assistant that never guesses

Every SaaS team gets the same advice right now: put an AI assistant in your product. And every team that's tried the obvious version has met the obvious problem — a language model with a search index will answer anything, confidently, including things that aren't true about your product. Support is exactly the wrong place to improvise. One invented setting, one plausible-but-wrong limit, and the assistant costs more trust than it saves tickets.

MyAISE's embedded assistant makes the opposite bet. It only answers from a knowledge base your team explicitly approved. If there's no approved answer, it says so and falls back to your product's live data — it never wings it from training data. This post is about how that knowledge base fills itself from your support tickets, and how the review step — the part that used to be the bottleneck — can now be done by Claude Code or Codex, validated against your real codebase.

Meet the assistant

The assistant embeds in your product with a script tag plus a short-lived token your backend signs, so it always knows which customer it's talking to. Under the hood it's three things:

• A curated knowledge base. Answers come from solutions — short, reusable Q&As your team has published. Retrieval only ever sees published solutions; nothing unreviewed can reach a customer.
• A live line to your product. Connect it to your own MCP server — MCP is the open protocol AI tools use to talk to services — and it can read real account state to diagnose issues, not just recite documentation. Any action it proposes waits for the user to confirm it.
• A guide, not just a chatbot. When telling isn't enough, it can walk the user through the fix in your actual UI.

Where the knowledge comes from

You don't write those solutions by hand. Connect your helpdesk (Zendesk today) and the mining pipeline goes to work: it clusters closed tickets that rhyme, extracts the underlying question and the answer that actually resolved it, strips away everything customer-specific — names, IDs, one-off details — and runs a sanitization audit so nothing private can ship. The output is a draft solution: a clean, generic answer to a question your customers demonstrably ask.

Drafts are quarantined by design. The assistant never cites one. Publishing is a deliberate act, and that's the feature — it's what makes "never guesses" true. But it creates the honest cost of this architecture: somebody has to review the drafts, and the pipeline writes them faster than a support team reads them. At Retreaver, our sister company, the pile hit 299 before anyone flinched.

Worse, the right reviewer isn't who you'd think. Whether a draft is true — whether the cap really counts calls that never connected, whether that error really means what the ticket thread guessed — is a question about your product's actual behavior. The person who can answer it authoritatively has your codebase open.

So we made the backlog reviewable by the thing that already has your codebase open: your coding agent. The MyAISE MCP server exposes the whole review loop — list, read, fix, annotate, publish — as tools that Claude Code, Codex, or any MCP client can drive. The agent validates each draft against your real source, locally — MyAISE never ingests your repo; only the solution edits the agent saves come back to us.

Connect in one command

The MCP server lives on the same host as the REST API and takes the same keys. Issue a team API key from the dashboard (solutions are team-scoped, so a personal key won't see them), then:

Scopes work the way you'd hope: a read_only key can list and read the backlog (triage is the low-risk place to start), while editing, publishing, and archiving need a full-scope key. The server introduces its own tools to the agent on connect, so you don't have to explain them in every prompt.

The review loop

The tools are built around the loop a careful engineer would run by hand:

• List the drafts (solutions.list returns per-status counts, so the agent sees the size of the hole) and pick a batch.
• Read one and extract its claims — limits, defaults, error messages, sequences of steps.
• Validate locally. This is the part that makes agent review better than tired-human review: the agent greps your actual source and checks every claim against the code that ships. The draft says the cap counts calls that never connected? Find the counter. It names a token or a setting? Prove it exists.
• Fix what's wrong with solutions.update — title, problem statement, body, steps, phrasings.
• Publish what survives; archive duplicates and obsolete drafts.

A prompt that runs the whole loop:

For a first session, start smaller — triage only, with a read-only key:

Hints: teach the assistant how to answer

Publishing a correct solution is half the job. The other half is telling the assistant what a good answer looks like when that solution matches — and that's context only your team has. So every solution now carries up to three hints, and all three can ride together:

• answer_hint — how to answer in chat. Often just: "a plain answer suffices, don't reach for tools."
• walkthrough_hint — when showing beats telling: offer or build a UI walkthrough for this one.
• workflow_hint — a concrete sequence of tools on your own MCP server that resolves the issue end-to-end. The assistant verifies the names against your live tool catalog before using them, and every write still goes through the user-facing confirm gate.

There's also a team-level free-text guide — "how our MCP server works" — injected into every assistant answer for your team. Your agent is the ideal author for it, because it can read your server's tools/list and write from the source:

"The drafts were already good. The hints are what made the assistant's answers feel like ours."

— What we noticed running this on our own sister company

The same loop in Codex

Nothing here is Claude-specific — it's plain MCP over Streamable HTTP. Codex reaches remote HTTP servers through the mcp-remote bridge:

The prompts above work verbatim. So does any other MCP client — the server speaks protocol versions 2025-06-18 and 2025-03-26 and negotiates per the spec.

We ran it on Retreaver first

Back to that 299-draft pile. Retreaver is a call-routing platform with a Rails codebase and its own MCP server, and it was the first production test: we pointed Claude Code at the MyAISE MCP server on one side and the Retreaver repo on the other, and had it review drafts the way an engineer would:

The second draft is the story. It read plausibly — it had survived mining, genericizing, and sanitizing — but the token it was built around doesn't exist in Retreaver's product. It leaked in from a third-party dialer platform mentioned in the original tickets. Easy to miss without the source open; the agent caught it in one grep, rewrote the draft generically, and published a solution that's actually true.

Then the payoff: asked the hard-cap question, the widget followed the answer_hint — a direct, correct answer with zero tool calls in the server log — and closed by offering the workflow hint's follow-up. The hints don't just decorate the solution; the assistant demonstrably answers the way you told it to.

The gate stays closed

Giving an agent publish rights only works if the safety rails hold with no human in the loop, so the sanitization gate is unchanged — and now stricter. solutions.publish refuses any mined draft whose stored sanitization report doesn't pass. Any content edit atomically clears the old report before the audit re-runs, so there's no window where yesterday's clean report vouches for today's text. If a published solution is edited into something that fails a fresh audit, it's demoted back to draft. Archived solutions can't be resurrected by a confused agent. And your secret key is the operator authority here the same way it is on the REST API — hints and edits carry exactly the trust your team's key carries, while everything the assistant does with them stays subordinate to its hard rules and the write-confirm gate.

Getting started looks like this: embed the assistant in your product on the AI SE plan, connect your helpdesk and let the mining pipeline read your ticket history, then issue a team API key at /dashboard/api-keys and point the coding agent you already use at the backlog (the MCP integration docs cover the details). A week of tickets becomes a knowledge base your assistant can actually stand behind — because every entry was checked against the code that ships. The drafts were never the bottleneck. The review was.