Service line 04 of 06
AI & Machine Learning
RAG assistants, agents and ML models taken from prototype to production, and measured against an evaluation set you agree before the first release.
Why AI stalls after the demo
These are the problems that keep a working model out of production.
The assistant impressed everyone in the demo, but nobody can say how often it is wrong.
We build an evaluation set from real questions with checked answers, score every release against it, and ship when it meets the target you set.
A user can ask about documents they should never see.
Retrieval filters by the user’s identity and the document’s permissions before any text reaches the model.
Nobody knows what a request costs, and the bill grows with every new user.
Every request is traced with tokens, cost and latency. Where the traces show waste, we cache, trim the context or route to a smaller model.
A model that worked in a notebook never made it into the product.
We register it in MLflow, serve it behind an API with a rollback path, and monitor its inputs and accuracy once it is live.
The business wants an agent that takes actions, and security wants to know what it can touch.
Agents get a short list of tools with scoped credentials. Every action is logged, and anything you mark as risky waits for a person to approve it.
What we commit to, and what we don’t
Quality depends on your data and your questions, so we don’t quote accuracy before we have measured it.
The release gate shown here is an illustrative example, not client data.
Before the build starts, we agree three things with you in writing: the questions the system has to handle, the score on the evaluation set that counts as good enough, and the cost per request you can accept.
If an early version misses those targets, you see it in the weekly demo, with the failing examples. Then we change the approach, narrow the scope, or recommend stopping. A system that can’t meet its target shouldn’t go to your users.
What we do commit to is the method: an evaluation set built from your data, a score for every release, and a trace for every production request. The AI section of our home page shows what one of those traces looks like.
What we ship
Each line is built on governed data and ships with its own tests. Most use cases need two or three of them.
Retrieval and agent pipelines
Document ingestion and chunking, hybrid search with reranking, answers that cite their sources, and agents built with LangGraph or MCP tools.
You receive
- Pipeline code in your repository
- Permission model for retrieval
- Tool list with scoped credentials
Model training and serving
Forecasting, classification and fine-tuned models trained on governed data, tracked in MLflow and served on SageMaker, Vertex AI, Databricks or your Kubernetes cluster.
You receive
- Registered, versioned models
- Serving endpoint and rollback steps
Evaluation sets and LLMOps
Test questions with reference answers, automatic scoring for faithfulness and relevance, and production tracing in Langfuse or your observability stack.
You receive
- Evaluation set you own
- Release report per version
- Trace dashboard for cost, latency and quality
Guardrails and approvals
Input and output checks, limits on what an agent may call, and a human approval step for the actions you mark as risky.
You receive
- Guardrail configuration in code
- Action and approval log
Models, agents and the tools around them
Model providers change quickly, so the provider sits behind an interface. We choose one per use case on quality, cost and where your data may be processed.
Listing a technology does not imply a vendor partnership or certification.
Models & platforms
- OpenAI
- Anthropic Claude
- Amazon Bedrock
- Azure AI Foundry
- Vertex AI
Agents & tools
- LangChain
- LangGraph
- MCP
ML platform
- MLflow
- SageMaker
- Databricks Mosaic AI
Evaluation & tracing
- Langfuse
- Weights & Biases
Governed data
- Unity Catalog
- Microsoft Purview
Questions about AI and machine learning
Not answered here? Ask in the request form.
How accurate will it be?
We can’t say before measuring. After the assessment we agree a target score on your evaluation set, and every release reports how close it gets.
Will our data be used to train someone else’s model?
We only use provider offerings whose current terms exclude customer data from training, and we check those terms during the assessment. Where your rules require it, the models run inside your own cloud account through Bedrock, Azure AI Foundry or Vertex AI.
Which model do you use?
Whichever meets the target at the lowest cost for your use case. Because the provider sits behind an interface, switching later is mostly a configuration change, followed by a new evaluation run.
Can the data stay in our region?
Often, yes. The major clouds host models in several regions. We check what is available for your region and your data rules during the assessment, before anything is built.
Do you build classical machine learning too, or only LLM systems?
Both. Forecasting, classification and scoring models are trained and tracked in MLflow and served behind an API, like any other service in your stack.
Discuss your AI use case
Bring one use case, a handful of real questions or records, and what a wrong answer would cost you.
How it runs: a call (30 minutes with a senior engineer), an assessment and written plan, the build with weekly demos, then handover or run. Our delivery standard