Where intelligence becomes infrastructure

Enterprise AI is not a product category, it is a delivery problem. The models are available to everyone at the same price, the demos all work, and the gap between organisations is entirely in whether anything reaches production and stays there. That is why our ten service lines are organised around what a system does rather than which model it uses — the model is the least differentiated part of any of them.

In practice, almost every enterprise AI system falls into one of four shapes. Something that answers questions from your content (a grounded chatbot or internal assistant). Something that reads and processes unstructured input (document and process automation). Something that pursues a goal across your systems (an agent). Or something that is itself a product your customers use (an AI web app, mobile app or SaaS). The strategy, integration and orchestration work exists to make those four shapes reliable, governed and affordable at volume.

Choosing the wrong shape is the most expensive mistake available, and it is made early. An agent built where a rules engine would do costs ten times as much per task and is harder to trust. A chatbot built where the work is really action leaves the user doing the work anyway. We spend the first two weeks of every engagement on this question specifically, because it cannot be corrected cheaply later.

Across 120-plus production deployments, the pilots that died did not die of model quality. They died of three organisational gaps, and all three are visible before a line of code is written.

No production owner. A pilot sponsored by an innovation team and built in a sandbox reaches the moment where someone must own an on-call rotation, a security review, a budget line and an integration — and if that person was never named, the pilot becomes an orphan. In our client data, pilots with a named owner from kickoff reach production roughly four times as often. It is the strongest predictor we track and it costs nothing to fix.

No definition of "good enough". A demo is judged by impression; a production system is judged by numbers. Without a written, measurable quality threshold agreed before the build, the pilot enters an endless loop of someone finding a bad output and confidence wobbling. Evaluation-first delivery — a golden dataset of real cases, scored automatically, with a threshold the business agreed to — is the closest thing this industry has to a silver bullet.

No economics. Inference costs look trivial at pilot scale and compound at production scale: more requests, longer contexts, retries, and the human review tail. We have audited pilots whose unit economics were negative — every processed item cost more than the manual process it replaced. Nobody had done the multiplication, and the multiplication takes an afternoon.

Every ChainCraft engagement closes these three gaps in discovery, before scope is committed. It is unglamorous, it is the reason our systems reach production, and it is why we occasionally end a discovery by recommending you do not build the thing you asked us to build.

Start with where the work is, not with the technology. The strongest first candidates share four properties: high volume, repetitive structure, a measurable current cost, and available data. If a workflow has all four, it is a good first project regardless of how unglamorous it sounds — and the unglamorous ones are usually the ones that pay back fastest.

Then match the shape to the work. If your people are answering the same questions repeatedly from documents that already exist, that is a grounded assistant, live in four to six weeks. If they are re-keying data from PDFs and emails, that is document automation, six to ten weeks with a parallel run. If they are assembling context from four systems to make a judgement call and then acting on it, that is an agent, eight to twelve weeks to supervised autonomy. If the work happens on the phone, it is a voice agent, and the safest pilot is the calls that currently reach voicemail.

If your problem is that nobody can agree which of these to do, that is what a discovery is for. Four to six weeks, fixed fee, and the output is a ranked portfolio with cost, feasibility and a named owner per initiative — plus the list of things we recommend against, which clients tell us is frequently the most valuable page.

Engagements begin with a fixed-fee discovery rather than a fixed price quoted before anyone has seen your data. Discovery produces four things: a committed scope, a committed timeline, a committed price, and an ROI model whose assumptions are stated separately so you can challenge each one. Occasionally it produces a fifth — a recommendation not to build, which we have delivered often enough that clients cite it as the reason they trusted the rest.

Delivery runs in weekly cycles, and each cycle ends with a live demo on your real data. Not a percentage-complete figure, not a status deck: working software running against the inputs it will face in production. This is the single practice that most reduces the risk of a late unpleasant surprise, because the gap between "works in the demo" and "works on your data" becomes visible in week two rather than week twelve.

Your team is three to five senior engineers with a named lead who is accountable to you and present in every demo. We do not staff a junior bench behind a senior sales team, and we do not grow teams to increase billing — in AI delivery, coordination cost rises faster than throughput, and depth beats headcount more decisively than in most software work.

Everything is yours from the first commit: code, prompts, evaluation datasets, infrastructure definitions and dashboards. Handover material is written as the system is built rather than assembled at the end, and your engineers sit in on delivery throughout. We consider it a failed engagement if your team cannot change the system after we leave — a permanent dependency on us is a bad outcome for both of us.

Every system we build uses enterprise model endpoints with zero data retention, so your prompts and outputs are neither stored by the provider nor used to train their models. Where sensitive fields must not leave your environment at all, a redaction gateway tokenises them before any external call and restores them on return — and for a large class of tasks, the model never needs the real values.

In-VPC deployment across AWS, Azure and GCP is routine, including fully private hosting of open-weight models for banking, healthcare and government clients where no data may cross an organisational boundary. Credentials are scoped per tool and per environment, held in a secrets manager, and rotated on a schedule.

Governance is designed to be survivable rather than theatrical. We tier it by risk: low-risk internal uses run under a clear usage policy with no approval needed, medium-risk uses get a documented review measured in days, and high-risk uses that affect decisions about people get formal review with documented human oversight and bias assessment. Routing everything through a heavyweight process simply teaches an organisation to route around it.

For clients in scope of the EU AI Act or sector regulation, the architecture does most of the compliance work as a by-product: versioned process definitions, complete run records, documented oversight points and evidence of pre-deployment evaluation are exactly what technical documentation obligations ask for. Organisations that build this in find compliance close to free; those that retrofit it spend quarters.