AI and LLM integration

What this is

Putting a language model to work inside your business: answering from your documents, drafting from your templates, extracting structure from messy input, routing and triaging, or acting through your systems with tools. The hard part is never the model. It is the retrieval, the permissions, the evaluation and the failure handling around it. That is what we build.

What you get

• A clear statement of what the model is allowed to see, say and do, agreed before any code.
• Retrieval over your own data (documents, tickets, database rows) with permissions enforced at retrieval time, so a user never sees what they could not open themselves.
• Tool use where it earns its keep: the model reads and writes through your APIs with typed, logged, reversible actions.
• An evaluation set built from real cases, run on every change, with numbers you can read. We do not ship on vibes.
• Guardrails: input and output checks, prompt injection defences, rate limits, cost caps, and a kill switch.
• Provider independence. We build against an interface so switching between model providers is a configuration change, and so you can run a smaller open model privately where data cannot leave.

Typical scope

• An assistant inside your support tool that drafts replies from your knowledge base, with citations, for a human to send.
• Structured extraction from incoming documents (orders, invoices, applications) into your systems, with confidence scores and a review queue.
• An internal question-answering system over policies, contracts or engineering docs, respecting existing access rights.
• An agent that performs a defined back-office workflow end to end, with every step logged and approvable.

How we build it

const answer = await assistant.run({
  user,
  question,
  retrieve: { sources: ["handbook", "tickets"], asUser: user.id, topK: 8 },
  tools: [lookupOrder, createTicket],          // typed, scoped, logged
  policy: { maxCostCents: 20, citations: "required", pii: "redact" },
});
await evals.record(answer);                     // every answer feeds the eval set

• Retrieval before generation. Good chunking, hybrid search, reranking, and permission filters. Most "the AI is wrong" problems are retrieval problems.
• Evaluation as a deliverable. You get the eval set, the harness and the scores, and they keep running after handover.
• Security by design. Data residency agreed up front, secrets in your vault, no training on your data, full audit trail of prompts and outputs where regulation needs it.

Timeline

Three to ten weeks. The first two weeks are usually spent getting the data and permissions right; a first useful assistant exists by the end of week three in most projects.

Good fit if

• There is a repetitive, text-heavy task with a human currently in the loop.
• You can give us access to real examples, including the awkward ones.
• Someone will own the eval set after we leave.

Not a fit if

• The goal is "add AI" with no task behind it. We will help you find the task first; that is a short, cheap engagement.
• Decisions with legal weight need to be fully automated with no human review. We will build the review step in and explain why.

Related

• AI integration patterns for the architectures we reach for.
• Evaluating LLM systems for how we measure.
• Automation for workflows that do not need a model at all.