AI Services.
Assistants grounded in your own documents, document workflows that run themselves, and an honest answer about what AI will not fix.
Most AI projects fail for boring reasons: nobody owned the use case, the documents were a mess, and no one agreed what a correct answer looked like. We start from the other end. Pick one workflow that costs real hours, build it against your actual data, measure whether it is right often enough to trust, and only then wire it into the systems your people already use.
What we build
Grounded Assistants
Retrieval-augmented assistants that answer from your handbooks, contracts and tickets, with citations back to the source paragraph and a clear refusal when the answer is not in the corpus.
Document Automation
Extraction, classification and routing for invoices, orders, contracts and forms. Structured output into the system that consumes it, with confidence thresholds and human review where it matters.
Workflow Agents
Multi-step automations that call your systems, with approval gates on anything that writes. Deliberately narrow, because a narrow agent can be tested and a general one cannot.
Model Selection
Choosing between hosted frontier models and open weights you run yourself, then routing per task. Includes fallbacks, timeouts and a cost ceiling that will not surprise you.
Data Foundation
The unglamorous half: permissions that mirror your existing access rules, deduplication, chunking strategy, metadata and the vector store. This is where most projects quietly fail.
Evaluation & Guardrails
A test set of real questions with known answers, regression runs on every change, PII handling, prompt-injection defences, tracing and escalation paths to a human.
How a grounded assistant actually works
No magic, five mechanical steps. Worth understanding before you buy one, because every failure mode lives in one of them.
Ingest
Documents come in from SharePoint, file shares, your ticket system or a database. We keep the source, the version and, critically, who is allowed to see each one.
Chunk and embed
Each document is split into passages and converted into vectors, a numeric fingerprint of meaning. Chunk boundaries matter more than people expect: split a table in half and the answer disappears with it.
Retrieve
A question becomes a vector too, and the store returns the passages closest to it, filtered by what the person asking is permitted to read. Usually blended with keyword search, because pure vector search misses exact terms like part numbers.
Ground the answer
Only the retrieved passages go to the model, along with the question and instructions to answer from them alone and to say so when it cannot. Citations come back pointing at the source, so an answer can be checked in seconds.
Evaluate and operate
Real questions with known answers run as a test set on every change. Wrong answers, refusals and thumbs-down feed back into chunking, prompts and the corpus itself. This part never finishes.
Where we will tell you no
Three requests we get regularly and push back on. Being wrong about this is expensive, so we would rather have the argument early.
"A chatbot that answers everything."
Unbounded scope has no test set, no owner and no way to fail visibly. We scope it to one audience and one body of knowledge, then widen it once it earns trust.
"Let us fine-tune a model on our data."
Rarely the first move. Fine-tuning teaches style and format, not facts, and it goes stale the day your documents change. Retrieval and prompt work solve most of what people expect fine-tuning to solve, at a fraction of the effort.
"Put AI on this."
If a database query, a rule or a regular expression does the job, it is cheaper, testable, instant and incapable of inventing an answer. We use a model where language is genuinely the hard part.
Models and tooling
The model is the easiest piece to swap and the least interesting decision. We pick per task, and we keep the option to change our minds.
Azure OpenAI
GPT-class models inside your own Azure subscription and an EU region, with your existing network and identity controls around them.
Anthropic Claude
Strong on long documents, careful reasoning and tool use. Available directly or through Amazon Bedrock when the rest of the estate lives in AWS.
Open-weight models
Llama, Mistral and Qwen on your own GPUs or a managed endpoint, for when data genuinely cannot leave the building or the volume makes hosted pricing hurt.
Vector stores
pgvector when you already run Postgres, Azure AI Search when you want hybrid search without operating it, Qdrant when scale or filtering demands it.
Orchestration
LangGraph, n8n or plain code. We default to the smallest thing that solves it, because every framework is one more dependency to upgrade at three in the morning.
Observability
Tracing on every call, an evaluation harness in the build pipeline, and a cost dashboard broken down by feature rather than one alarming monthly total.
How an AI engagement works
Frame
One workflow, a named owner and a definition of success you can measure. If we cannot agree what a correct answer looks like, we are not ready to build.
Prototype
Two to four weeks against real data, with an evaluation set built from questions your team actually asks. You get a working thing and an honest accuracy number, including the case where the number says stop.
Integrate
Identity, permissions, logging, rate limits and cost controls. It lands inside the tools people already use, Teams, your intranet or the line-of-business system, rather than as another tab nobody opens.
Operate
Evaluations on a schedule, drift and cost monitoring, model upgrades tested before they ship, and a quarterly review of whether the thing is still earning its place.
Common questions
Have a workflow that eats hours every week?
Tell us what it is and what a correct outcome looks like. We will come back with an honest read on whether AI is the right tool, and a pilot proposal if it is.
Schedule a call
Ready to build something that stays up?
Tell us about your stack. We'll come back within one business day with a concrete next step.