We implement it, you own it

Databricks, and the data foundation AI actually needs

Most AI programmes stall on data, not models. The moment a team moves past assistants and wants AI working against the company's own information, the question stops being which tool to buy and becomes whether the data can be reached, trusted and governed. Usually it cannot. It sits across systems that were never meant to talk to each other, two reports disagree and nobody can say which is right, and access control was left for later.

We design and build lakehouse platforms on Databricks with the foundations in the right order. Bronze, silver and gold layers around your domains, pipelines your own team can maintain, and Unity Catalog set up before the platform fills with users, because access control and lineage are cheap to do first and expensive to retrofit. Migration off the legacy warehouse runs one domain at a time, each delivering something usable, rather than a single cutover that has to go perfectly on a weekend.

An engagement starts with a scoping conversation and a single-domain proof of value. If the honest answer is that you do not need a platform yet, we say so.

• Lakehouse architecture on Delta Lake
• Unity Catalog governance from day one
• Migration one domain at a time
• Your team trained on the platform as it grows

Claude, wired into the work rather than sitting beside it

Most organisations get real value out of the chat window and then stop, because the next step needs their own systems and their own information. Twelve people paste the same brand guide into a fresh conversation every morning. The question is about a live matter or this month's numbers and the model cannot see either. And nobody can say whether the output is good, which is the dangerous part, because it reads well.

This is that next step. Shared Projects with the firm's own knowledge loaded, structured by team and by job, with the admin settings and retention your security team will pass. The Anthropic API inside the tools people already have open: the practice management system, the CRM, the intranet. MCP connectors that let Claude read your document store or your data platform under the permissions you already run. And agents scoped narrowly, with a test set and a score, so you can see when one degrades.

You do not need all of it. We will say which parts your organisation is ready for, and when the answer is training rather than a build.

• Projects at scale, with the settings written down
• The API in your own systems
• MCP connectors under your existing permissions
• Agents with an evaluation set behind them

Mistral: a private model, stood up and handed over

Some work is not allowed to go to a hosted service. Classification, jurisdiction or a client contract says the information stays inside your walls, and no amount of contractual comfort changes that. Mistral publishes models you can run in your own cloud account or on your own hardware, which makes it the practical answer where a hosted API is simply not permitted. The first thing we check is whether the constraint is real. If a hosted model in the right region would satisfy the obligation you carry, self-hosting is a large cost for nothing, and we will tell you.

Where it is real, the build goes wrong in three predictable ways: sized for the demo rather than the load, never connected to the material people need, and handed over with nobody able to operate it on Monday. So the deliverables land in order. A sizing with a monthly cost, agreed before anything is provisioned. The deployment in your environment, with the failure modes documented rather than discovered. Retrieval over your own documents, each answer traceable to its source. And a runbook your platform team has already used before we finish.

• A sizing with a monthly number
• Deployment in your own tenancy or on your own hardware
• Retrieval over your own material
• A runbook, and a team that has used it

Sierra: customer-facing agents scoped from your transcripts, not a demo

Automated support has a poor reputation for good reason, and the failures are design decisions rather than technology limits. The scope came from a workshop instead of the contact data. The integrations were left until last, so the agent can describe a refund but cannot issue one. It went to all traffic at once with no measure agreed beforehand. Customers can tell when an agent is stalling, and they resent it.

We implement Sierra agents the other way round. The intent map is read out of your own transcripts and tickets: what customers actually wanted, how often, and which of it an agent can finish end to end. Everything else routes to a person by design, with the history and what was attempted attached, because the handover is the moment the whole deployment gets judged on. The integrations that close a ticket are scoped in the same week as the intents. Release is narrow, on a share of traffic, widened on the evidence, and measured on resolution rather than deflection.

If your contact volume is low or your systems expose no API, the honest answer is not yet, and we give it on the first call.

• An intent map from your own contact data
• The integrations that close a ticket
• A handover that carries the context
• Guardrails and a resolution measure

OpenAI: past the point where a good prompt is enough

A team that has learned to prompt well will build a dozen custom GPTs and then meet the same three limits. Forty GPTs and no owner, several doing nearly the same job, none documented, and the person who made the good one has left. The knowledge that matters sits in a document management system the chat window cannot see, so somebody exports files by hand every week. And the work happens in a separate tab, copied out of the system and back in, with exactly the transcription errors the process was meant to remove.

None of that means the rollout failed. It means it worked, and the next step is engineering rather than a better prompt. Custom GPTs rebuilt to be maintained, with an owner each and knowledge kept current; the consolidation is usually the biggest single win. The OpenAI API inside the systems your team already works in, so the drafting or the classification happens in place. Retrieval over your own material with the source shown. Assistants with a scored test set, so quality is a number rather than an impression that decays quietly.

We implement on the OpenAI platform and claim no partner designation with them. Where we hold one, it is stated on the partnerships page and nowhere else.

• Custom GPTs built to be maintained
• The API in your own systems
• Retrieval over your own material
• Assistants with a test set

Custom applications and agentic workflows

Some work is specific to how your organisation runs and no vendor sells it. That is the case for building, and it is also the case for being careful about what gets built. We turn down more of this work than we take. Three signs the answer really is a build: the process is genuinely yours, and every product that nearly fits would need it bent to suit; it is high volume and low variation, with rules a person could explain; and the workaround already has a headcount, so the business case is an existing number rather than a projected one.

Agentic sounds like autonomy. In practice the good ones are narrow and observable, with an off switch: multi-step work that reads something, decides, acts, checks the result, and either finishes or escalates, with the boundaries written down at scoping time. The model is chosen for the task and the constraints, whether that is Claude, an OpenAI model or a Mistral deployment in your own account, and built so the choice can change without a rewrite. Anything that commits money, reaches a customer or touches an obligation you carry gets a person in the loop by design.

If an existing product does the job, we name it on the call and you can stop there.

• Agentic workflows that stay in scope
• Model choice on the merits
• Evaluation and observability
• A human checkpoint where it belongs