Use case

Support that answers from your own docs.

An assistant grounded in your documentation answers customers and agents with citations, files the ticket, and escalates with context, without a single conversation leaving your infrastructure.

Answers cite sources Tools under policy Escalates with context Runs fully local

The most attempted AI project, and the wall it hits.

Every support team evaluates AI. Most evaluations end on the same four findings, and none of them are about model quality.

  • Tickets are made of customer data. Names, account numbers, contracts, error logs with credentials: routing conversations through a hosted API turns the helpdesk into an export pipeline.
  • Ungrounded bots invent policy. An assistant that answers from its weights instead of your documentation, with citations, will quote refund windows you never offered.
  • Per-token pricing scales with your success. Busy months are precisely when metered inference bills spike, so the tool gets rationed when customers need it most.
  • Actions need governance. An assistant that files tickets or issues credits must operate under explicit permission policies, not a system prompt's good intentions.
  • Escalation loses the thread. When the bot gives up, the human should inherit the conversation, the retrieved sources, and the attempted steps, not a blank ticket.

Ground, answer, act, escalate.

The pipeline that turns a documentation folder into a support channel people can actually trust.

01

Ground

Product docs, KB articles, and past resolutions become a retrieval corpus.

02

Answer

Hybrid retrieval plus reranking; every answer cites the article it came from.

03

Act

Tools file, tag, and update tickets under permission policies.

04

Escalate

Unresolved cases hand off to a person with the full context attached.

One engine, two ways to deploy it.

The scenario decides the form: a backend the helpdesk points at, or support intelligence inside the product you ship.

Serve it

LM-Kit One: the helpdesk's backend

Server-side agents bundle prompt, knowledge, tools, and memory; the helpdesk, the chat widget, and internal tools adopt them by name over the APIs they already speak, with identities, audit, and policies handled once.

Deploy LM-Kit One

Embed it

LM-Kit.NET: support inside your product

ISVs ship in-app assistants that answer from the product's own documentation, run offline at customer sites, and never add a cloud dependency to the deal.

Embed LM-Kit.NET

What makes it trustworthy.

The properties that separate a support assistant from a liability generator.

Grounded

Answers with receipts

Every answer cites the document and passage it came from, so agents verify in one click and customers get policy, not improvisation.

Governed

Actions under policy

Tools carry risk metadata and run under allow, deny, and approval rules; the assistant files tickets because policy permits it, not because nothing stopped it.

Unmetered

Busy months cost the same

No per-token fees means no rationing during incidents, launches, and renewals, when volume peaks.

Both forms, working code.

The server agent is the high-level path: defined once, adopted by name. The OpenAI-compatible endpoint keeps existing integrations working, and the embedded form runs the same stack in process.

The high-level API: the agent bundles prompt, knowledge, tools, and memory on the server, and every channel adopts it with one field.

terminal
curl http://your-server:5189/lmkit/v1/chat \
  -H "Authorization: Bearer your-server-token" \
  -H "Content-Type: application/json" \
  -d '{"agent":"support-assistant",
       "messages":[{"role":"user","content":"Where do I renew my enterprise license?"}]}'

# The agent supplies system prompt, skill, tools, and memory;
# change the agent on the server and every channel follows.

Frequently asked questions.

How do we stop the assistant from inventing answers?

Ground it. Retrieval-augmented chat answers from your documentation and cites the document and passage behind every claim, and retrieval thresholds keep it from answering at all when nothing relevant exists, which is the honest failure mode.

Can it plug into our existing helpdesk?

Yes. LM-Kit One speaks OpenAI, Anthropic, and Ollama dialects plus MCP, so integrations built for those APIs point at your server by changing the base URL. Server-side agents bundle the prompt, knowledge, and tools so every channel gets the same behavior.

What stops it from taking actions it should not?

Permission policies. Every tool carries risk metadata and runs under allow, deny, and approval rules; sensitive actions can require human sign-off, and the audit trail records what was called and why.

What happens when it cannot resolve a case?

It escalates with context: the conversation, the retrieved sources, and the attempted steps travel with the handoff, so the human agent starts informed instead of starting over.

Private AI for support

Answer from your docs, not from thin air.