A support inbox that answers first, and opens itself to any AI.

01 — The problem

The platform competes with the big helpdesk suites. Its customers are small and mid-sized SaaS teams whose support load arrives faster than their headcount. Two pressures were building at the same time.

First, customers expected an instant, accurate first reply in the chat widget and over email, and the only acceptable failure mode was a clean hand-off to a human. A bot that guesses is worse than no bot. Second, support reps increasingly live inside an AI assistant such as Claude Desktop or Cursor, and did not want yet another chat box bolted onto the dashboard. They wanted the helpdesk to come to them.

02 — What we built: the AI Support Agent

The agent is the first responder on every new conversation. It reads the message, retrieves what the company actually knows, answers, and decides for itself whether the case is closed or needs a person.

• Grounded answers only. Every reply is built from retrieval over the company's own knowledge: imported help-centre articles, crawled docs, uploaded files and previously resolved conversations. The system prompt forbids outside knowledge and forbids guessing when the context is silent or ambiguous.
• Two tools, deliberately. The agent can hand off to a human and it can mark a conversation resolved. That is the entire action surface. A small surface is what makes its behaviour predictable and auditable.
• Per-company instructions with hard rails. Each company layers its own tone, workflows and rules on top of the base prompt, and can branch on customer metadata such as plan or login state. The rails underneath cannot be overridden: the agent refuses to reveal its instructions, ignores extraction attempts and never fabricates a URL.
• Same message path as humans. Replies stream into the widget through the exact path a human reply takes, so email threading, Slack mirroring and push notifications behave identically for bot and person.
• Knowledge that improves itself. When a human resolves a chat the bot could not, the system drafts a new knowledge-base article from that conversation for the team to approve, and embeds the resolved chat into the company's vector namespace so the next answer can cite it.

03 — What we built: the MCP server

Rather than build another chat box, we exposed the helpdesk as a standard Model Context Protocol server. Any MCP-capable client, from Claude Desktop and the claude.ai connector to Cursor and custom agents, gets permissioned access to the inbox, and the company's own drafting rules travel with the data.

• The tool that carries the product's opinion. One call, get_reply_context, returns everything a model needs to write a reply in the company's voice: the full thread and customer history, the most similar resolved chats retrieved by vector search and labelled as examples, candidate saved replies and knowledge-base hits, the company's voice guide, the rep's signature, and an explicit list of drafting rules. Because those rules live in the data rather than in any client's system prompt, reply quality holds across Claude, GPT and Gemini. We ran a cross-model regression eval to confirm it.
• Two autonomy modes, default-deny. Every token is created in suggest-only or full agent mode. In suggest-only, a reply comes back marked as not sent and a human re-issues it; in full agent it goes to the customer with normal channel mirroring. Enforcement lives in the dispatcher, so a newly added tool cannot accidentally become autonomous.
• Bug routing to engineering. When a conversation is really a defect, the same session can flag it and create or link a ticket in Linear, Jira Cloud or GitHub Issues, chosen per company, with the ticket URL and status stamped back onto the chat.
• Spec-compliant transport. Streamable HTTP and JSON-RPC 2.0 on a single endpoint with its own TLS, verified live against Claude Desktop and the claude.ai remote connector.

04 — How we made it safe

• Identity and audit. One bearer token per company and acting user, so every MCP action is attributed to a named person and the audit trail matches the dashboard's. Tokens are shown once, listed by prefix only and revocable at any time from an admin screen.
• Isolation tested per tool. Every tool has a happy-path test plus an authorisation and organisation-isolation test. A token can never read or write another company's data.
• Rate limits and clean failures. Per-token limiting with proper retry headers, a separate limiter on token creation, and a guard that returns a clean 4xx on malformed requests rather than a 500 on a public endpoint.
• No PII in the model layer's logs. The LLM request carries customer data and the response carries the reply. We treat any logging there as a GDPR exposure and gate debug output behind a non-default flag that must be removed before merge.
• A production lesson, written down. Shortly after launch, spec-compliant clients failed the handshake because the dispatcher answered a JSON-RPC notification that must never get a response. The fix was small; the lesson was recorded in the team's library so it is not relearned.

05 — The outcome

Before: every conversation waited in a queue for a person, even the ones the help centre already answered, and reps juggled the inbox, the bug tracker and their AI tools. After: every customer gets an instant first reply grounded in the company's own documents, and people only see what the bot could not answer, with the context already attached.

Both features are live in production for paying customers. The support agent hands anything it cannot answer to a person with full context rather than a cold transfer. Reps using the MCP server draft replies inside Claude Desktop in the company's voice, with knowledge-base citations, and file engineering tickets without switching tabs.

The MCP surface ships with a full test suite, end-to-end browser tests for the token dashboard, and a written spec and production plan. Next on the roadmap: OAuth 2.1 issuance so the server can be added from the claude.ai connector dialog with no manual token, and per-company analytics on AI-drafted versus human-drafted reply quality.

06 — What this means for you

If you run a product with an inbox, a queue or a ticket list, the question is no longer whether to add AI. It is whether the AI you add can be trusted to act, and whether your customers can use it from the assistant they already have open. An agent with a tiny action surface and a grounded knowledge base answers the first; an MCP server with permission tiers and suggest-only mode answers the second. We build both, and we ship the tests that prove the isolation holds. Start with an AI Pilot or an audit of the AI you already have.