Why an AI studio now

The strategy is written. It has a use-case inventory, a governance model, and a business case, and it is often a good one. The platforms are bought and the licenses are active. AI is in daily use somewhere in the company, usually in the general-purpose tools employees reach for themselves. What is scarce is the agreed priorities in production. In a survey of 3,235 executives across 24 countries published in January, every participating organization already used AI daily, yet only a quarter had moved 40% or more of their AI experiments into production. Close to three-quarters planned to deploy agentic AI within two years, and 85% expected to customize agents for their own business. The strategy exists and the platform exists; the application that connects the two is the part most companies have not built.

That build has become the responsibility that decides whether a strategy produces anything, and two things have changed this year that make it worth doing now.

What changed

The first change is what the models can do when the work around them is built properly. In one week in October, one frontier lab described teams of agents finding previously unknown vulnerabilities in its own infrastructure, and another reported machine-checked proofs that pieces of widely used software cannot crash. Both results depended on the process: purpose-built environments, source code and documentation supplied, security teams reproducing findings and checking fixes, proofs resting on precise specifications and an independent checker within stated assumptions. The model's contribution became useful through what was built around it. The same holds further down the capability scale: across our deployments, open-weight models tuned on a company's own domain carry the majority of recurrent production tasks, with frontier models reserved for the questions that justify them. When any competent team can get the same model, the application around it is where the difference is made.

That changes which shelved projects deserve another look. A project may have failed because the model could not interpret the evidence, because the evidence was not available to it, or because checking the output took longer than doing the work. A better model changes the first problem. Better integration changes the second. The third is answered only by testing the whole workflow, and a company should be able to run that test without reorganizing its technology function around every model release.

The second change is in what buyers now require. In the same survey, only 21% of the companies planning agents reported a mature governance model for them; an agent that touches a customer, a payment, or a record needs its identity, its permitted reach, its approval thresholds, and its log engineered before it runs, which is application work rather than a policy document. And 83% of leaders called sovereign AI important to their planning, 77% weighed a vendor's country of origin, and nearly three in five were building their stacks mainly with local vendors. A deployment on the company's own infrastructure, with weights it holds and records it keeps, meets most of those requirements regardless of where the engineering team is based.

Three parties and the application build

Three parties are usually in the room when a company tries to put AI into routine use, and each owns something the deployment needs.

The strategy houses produce the overview: the priorities, the use-case inventory, the governance model, the business case. It is often good work, and it is where our own engagements usually start. The domain experts, scientists in a research function, engineers on a service floor, officers in a compliance function, own the decision: what question is worth asking, what evidence standard an answer must meet, who may accept it. The enterprise technology team owns the environment: the platforms, access, security, integration, and operating standards everything must run inside.

The application build sits between them: data integration against the records the decision actually uses, model adaptation, analytical tooling the experts trust, workflow software with review built in, evaluation against the domain's own standard, and deployment on the company's infrastructure. It is a defined responsibility, and the question is who has the capacity to carry it for a particular application. Consultancies employ engineers; internal teams build applications. Where an existing team can take a project through to dependable operation, it may be the right team to do it. Where a product already meets the requirement, buying it may be sensible. A studio earns its place when a worthwhile application needs a focused team to deliver it, alongside the people who understand the work and run the environment. Their knowledge is essential to the build: a specialist needs time to explain an ambiguous record, supply examples, and reject an answer that looks plausible but would be useless on the job, and that participation belongs in the engagement's scope and cost.

"We do not compete with the strategy houses; their report is often where our work starts. We take it apart into pieces that can be built, establish how each will be accepted, and build them alongside the client's teams. That is a different job from writing the report and a different job from running the platform, and it needs a different kind of firm." paterhn

What the build looks like

It starts with a concrete question: what would you like the business to be able to do? A manufacturer might want to investigate recurring equipment faults across years of service records. A software team might want to test unfamiliar parts of a large code base more thoroughly. A defense engineering team might need to assemble technical evidence against requirements under strict access controls. A bank might want a better-supported case in front of its reviewers. The value of each comes from the work someone can complete with the result, so the first engineering decision is what somebody should receive: for a technician, the procedure for the exact equipment in front of them with the source available to inspect; for a software maintainer, a reproducible defect and a fix that survives the project's tests; for a reviewer, a comparison that separates established facts, conflicting evidence, and open questions.

That output determines everything behind it, and it turns a strategy line into pieces that can be built. Each piece needs four things, and the fourth is the one most inventories lack.

Before any model is chosen, evaluation sets are built from the company's own historical cases and reviewed by its domain experts, so every candidate configuration is scored against the domain's standard on the company's data rather than against a public benchmark. Models are then routed by task, on demonstrated performance against those sets, permitted data access, and operating cost. Approval follows consequence: below a threshold the domain experts set, in the currency they understand, an output with its evidence attached is accepted by the person running the workflow; above it, the output stops at a named person, whichever model produced it. For work in defense or regulated finance, the permitted operating environment shapes this design before model selection begins: where data may be processed, where the deployment may run, what must be retained, and who may authorize an action are constraints the client specifies and the build is tested against.

The result is measured on the work after review, never on the demonstration: the whole workflow, including human verification, correction, and rework, compared with the method it replaced, on measures agreed with the domain experts before the build began. A fast model response is not a finished task; an accepted one is. When an answer is wrong, the team has to know where: retrieval missed a source, an outdated revision was used, a calculation compared incompatible units, or the model turned a tentative observation into a firm conclusion. Each needs a different correction, so source selection, tool results, and the final output stay inspectable, and every failure becomes a repeatable test.

The engagement ends with a transfer that is tested rather than asserted. Before handover the client's team reruns the evaluation, updates a source, and handles a known failure using the delivered documentation, without the studio. What transfers is the project code, configurations, and tuned model artefacts, deployed on the client's infrastructure; the evaluation sets, failure cases, and reproducible builds; and the documentation and practice to rerun evaluations and manage change. The studio retains no hosted components and no claim on the delivered work; third-party software and base models keep their own license terms. That foundation is also how the client judges every model that arrives afterwards: run it against the work, inspect the failures, compare the complete cost, and decide.

Where it has run

Three documented engagements, anonymized under our agreements with the clients, show the same division of responsibility in different domains; a fourth area shows the pattern running as a product.

In a research-driven pharmaceutical company, a six-month engagement on the company's own infrastructure took the first production workflow, the assembly and review of development evidence, from proof of value into routine use, then built candidate screening on the same architecture. Initial use was read-only and supervised; the scientists set the acceptance criteria and kept scientific approval. The client's team measured a 30% reduction in time from request to reviewed evidence package, including verification, corrections, and rework, a figure about evidence-review lead time rather than the duration of a research programme. Before handover the team reran the evaluation, updated a source, and handled a known failure without us, and afterwards it extended the architecture to trial documentation and regulatory intelligence and changed a model when it chose to.

For a global industrial technology group, the application had to fit a physical task. Technicians travelled to equipment, diagnosed faults, carried out repairs, and documented the work later from memory, while the relevant knowledge lived in manuals and service history. We paired smart glasses with a phone, tuned a small language model on the client's documentation, and let a technician request a schematic, a procedure, or previous resolutions of the same fault, with an image of a component narrowing the answer and the work documented by voice as it happened. Fourteen weeks from kick-off to a working prototype in the hands of working technicians, and we stopped there; scaling was the client's.

At a fintech software company, first-pass code review, test generation, and documentation updates run on an open model fine-tuned on the client's code base and review history, on weights the client owns, with security-critical diffs and architectural changes routed to a frontier model. Review turnaround on routine diffs fell from hours to minutes, and roughly seven in ten agent tasks run on the open model.

In regulated finance, the same division of responsibility runs daily inside a compliance workforce we engineered and operate as a product rather than as a client engagement: agents resolve who a counterparty is, map who owns and controls it, check it against the relevant lists, and assemble a source-linked case; an accountable officer decides and signs, and every action lands in an append-only record. It is the same pattern, in production, under a regulator's scrutiny.

How to tell a studio from everything else

The buyer's test is short. Ask where the application will run; the answer should be your infrastructure, from the first day. Ask what the evaluation sets are built from; the answer should be your historical cases, reviewed by your experts, before a model is chosen. Ask who accepts a consequential output; the answer should be a named person in your organization, whichever model produced it. Ask what happens at handover; the answer should include your team rerunning the evaluation and handling a failure without the studio. And ask what the studio retains; the answer should be no hosted components and no claim on the delivered work.

The 2027 budgets being written this quarter have line items for strategies and platforms, because both are well established. The build does not yet have one in most companies, and it is the line that decides whether the other two produce anything. The first conversation should start with a piece of work you can show: an input, an example of the result somebody needs, and the person who can judge it. Then a first build small enough to evaluate and substantial enough that its success would matter; the result may justify deployment, a different approach, or stopping, and each leaves the business with evidence for the next decision. Start with the project you put aside because doing it properly cost too much. Find out what has changed. Talk to an Engineer.