Eighteen months ago a consultancy spent eleven weeks in your offices and left a deck. It had a maturity model in it, and a roadmap with three horizons. Nothing runs.
Meanwhile someone in finance is pasting supplier contracts into a public chatbot to summarise them, because it genuinely helps and nobody gave them anything better. Your legal team does not know it is happening. Neither does the customer whose pricing is in those contracts.
Both of those things are the same failure: AI arrived as a strategy conversation instead of as engineering. A strategy cannot be audited, cannot be switched off, and cannot answer the one question your customers are starting to ask — where does our data actually go?
We start at the other end. We draw the boundary, we build the system inside it, and we show you the evidence it works. If the evidence does not come, we tell you and we stop — which is a thing an engineering firm can afford to say and an advisory usually cannot.
A slide cannot be audited. Ask for the architecture, and ask who can see the data.
This division sells engineering time, not licences. Nothing here is part of VarahiOne or VarahiField — you can engage us for any one of these on your own stack, with your own models, and never touch a Varahi product. Several of our engagements end that way.
The deployment drawing: where data sits, where the model runs, every boundary it crosses and who approves each crossing. Delivered as a document you can hand to an auditor or a customer's security team.
A named set of agents, each with a written scope, a budget and an audit trail — built on whichever runtime and models you already use. Propose-only by default, with autonomy raised one step at a time.
We build the test set with your domain experts from the cases they argue about, then measure whatever you are being sold against it. Often bought on its own, to check a vendor's claims before you sign.
Drawings, SOPs, service records, tickets and tribal knowledge made retrievable with provenance on every answer. The advantage was never the model — anyone can rent that. It is your own knowledge, and almost nobody has made theirs usable.
The shortest engagement we offer, and often the most valuable: naming the two or three problems worth attacking, sizing them, and telling you which ones AI is the wrong tool for.
Getting your team to the point where they do not need us: runbooks, failure modes, on-call paths, and the written record of every decision and why it was made.
For groups that need the capability in-house rather than on retainer: we help you charter a small senior team, ratify the standards it works to, and get its first use cases into production alongside your people. Lean and senior beats large and general — a handful of deep specialists who set the pattern will outrun a department that absorbs every request.
Each service is a real installation inside the boundary. As you read, the camera moves to it.
Everyone says their AI is secure. The question that separates claims is simpler: can you draw every boundary your data crosses, and name who controls the far side of each one?
In the model beside this, the perimeter is a closed ring of blades with exactly one gap — the gate. Inside it sit the runtime, the agents, and the record of everything they have done. Nothing else crosses. That is not a metaphor; it is the deployment diagram, and you get it as a document you can hand to an auditor.
The common first attempt is a single assistant that can supposedly do everything, which in practice does a few things unreliably and cannot be held responsible for any of them. We design the opposite: a named set of agents, each with a written scope, a spending limit, and a log of everything it has touched.
We know it works because we run our own engineering that way. Our agents propose changes; they do not merge them. A person approves every one. That is not caution for its own sake — it is the only arrangement in which you can let software act and still answer for what it did.
What this agent may read, what it may do, and where it must stop and ask. Reviewed like any other spec.
Tokens, calls, spend. An agent that cannot exceed a budget cannot surprise you at the end of the month.
Every retrieval and action, append-only. This is what you show a regulator or a customer's security team.
Propose-only by default. Autonomy is raised one step at a time, and only against evidence.
The agents run through adapters, so the model and the tooling underneath can be swapped with a configuration change. We would rather be replaceable than have you stuck with us — and it means you can adopt a better model next year without a project.
Every company that has tried to govern AI centrally has learned the same thing: if the approved route is slower than the unapproved one, people take the unapproved one. Governance that gets routed around is worse than none, because it also tells you everything is fine.
So we design the controls to be the quickest way to ship, not a queue in front of it. Practically that means deciding how much oversight a use case earns before anyone builds it, rather than applying the same review to a drafting assistant and a system that decides whether a part passes.
Each use case is classified by what happens when it is wrong. Documentation, human oversight and testing scale with that tier — heavy where it matters, light where it does not.
Not "human in the loop" as a slogan. We name, per use case, which decisions a person must sign, and design the system so it cannot proceed without them.
The EU AI Act and GDPR shape the architecture from the first drawing, not a compliance review at the end. If you sell into Europe, this is now a commercial requirement.
Which models are in use, where, on what data, approved by whom, and when they were last evaluated. Most organisations genuinely cannot answer this.
An explicit list of which tools may see which classes of data — the thing that was missing when someone started pasting contracts into a public chatbot.
Retrievals, actions and approvals, append-only. Written for the day a regulator or a customer's security team asks, not for the day you deploy.
Scope and duration are agreed with you once we have seen your data and your constraint — we do not quote a fixed programme before knowing either. What does not change is the sequence, and the fact that each phase ends with evidence in front of you.
We sit with the people who do the work and build a test set from real cases — the ones they argue about, not the easy ones. This becomes the definition of good for the whole engagement. Nothing later is allowed to override it, including us.
Where the data sits, where the model runs, what crosses, who approves each crossing. You get the drawing before anything is built, because if it is wrong, this is the cheap moment to find out.
Inside your network from the first day, not in our cloud with a migration promised later. You watch the number from step 01 move every week. When it stops moving, we say so.
Not a demo — the actual users, on the actual system, while we can still change it. This is where most of what is wrong gets found, and it is why we do not leave before it.
Runbooks, failure modes, on-call paths, and the written record of every decision and why it was made. We treat how little you need us as a measure of whether the engagement worked — not as a risk to the account. We would rather you called us for the next thing than for this one.
Most consulting leaves documents. This leaves a working system, and a record of how the company thinks — which is the part that compounds.
Deployed, documented, and yours — with the evidence that it meets the definition of good you wrote in week one.
The most durable asset from the engagement. Any future vendor, model or team can be measured against it — including us.
Decisions, traces, rejected options and the reasoning behind each call. The reason your next project does not restart from zero.
We read what large industrial groups have published about their own AI programmes — the ones running vision inspection at scale, agentic automation in shared services, AI in engineering. The successful ones look nothing like the failed ones, and the differences are consistent enough to design around.
The groups that succeed do not start from "we need AI". They name two or three business problems leadership already wanted solved, and go at those. Everything else waits.
Investment approved by the executive team, then each business unit asked where it actually hurts. Neither half works alone: top-down alone builds shelfware, bottom-up alone never gets funded.
In a decentralised group, the winning move is repeatedly the plainer one — basic profiles, fewer fields, less validation ceremony — because it is the version people actually adopt.
The published post-mortems say it plainly: AI has to be managed like any other change programme. The model is the easy part; the working habits around it are the project.
One group's recommendation engine under-delivered because their catalogue was long-tail: too many part numbers, too little repeat volume to infer anything. The textbook method met the actual data shape and lost. This is why we build the test set from your data before we design anything.
Every serious industrial programme lands on the same sentence: the AI is not replacing the engineer, it is making them faster. The ones that forget it get quietly switched off.
Drawn from publicly published accounts by large industrial groups of their own AI and digital programmes. We are happy to walk you through the sources and what we took from each.
Tell us what is costing you and what "better" would be measured in. If we think you do not need us, we will say that too.