Your AI problem is not a technology problem
Most enterprise AI never reaches the P&L. The pilots work, the demos impress, and the value evaporates somewhere between the proof of concept and the operating model. Salesforce finds 83 per cent of organisations reporting that most or all of their teams have adopted AI agents. Deloitte finds 84 per cent have not redesigned jobs or the nature of work around them. Two studies asking different questions: one counts what has been bought, the other what has been changed. The models are not the reason.
BCG recommends splitting the effort of an AI transformation 10 per cent on algorithms, 20 per cent on technology and data, and 70 per cent on people and process. That is a recommendation rather than a measurement, and the useful part is how few programmes match it: the budget, the attention and the board reporting nearly all chase the technological slice. McKinsey supplies the measurement. The firms reporting real financial impact, about six per cent of respondents, are close to three times more likely to have fundamentally redesigned how they work, and workflow redesign is the single factor most correlated with bottom-line impact. Only 39 per cent report any enterprise-level EBIT impact at all. Most reach for the technology first, and most see nothing.
We do the seventy per cent.
Three clocks are running. Boards are asking why AI spend has not reached EBIT, and the answer keeps arriving as a question about how the work is organised rather than about which model was bought. Regulation has started to bite: the EU AI Act's transparency duties have applied since 2 August 2026 and land on the firm deploying the system, not only on the vendor supplying it, and the Cyber Resilience Act's reporting obligations follow on 11 September 2026. The high-risk regime moved out to December 2027, and the deferral made the problem worse rather than better, because the deadline moved by sixteen months while the estate kept arriving on the old schedule; the distance between what is running and what is controlled got wider. Meanwhile token spend is becoming the fastest-growing line in the technology budget, with no owner in the operating model. Firms that do the organisational work first take the surplus. The economics of every earlier general-purpose technology predict exactly that.
The technology is the forcing function; the organisational redesign is the answer. AI will not set you apart, because your rivals buy the same models; the speed at which your organisation changes around them will. If the numbers are not moving, the model is not where to look.
We sell software and the consulting that makes it land
The software is the Dromologue skills, which your teams install, run and extend; the consulting is how an organisation that was not built for it comes to run them. We change how your teams work, one team and one real use case at a time, until they can run the next one without us. Your rivals can buy the same models; they cannot buy the speed at which your organisation changes around them. A use case delivers value and then it is finished. A team stays, and a team that has worked the new way once does not go back to the old way. So the unit we change is the team: a small team formed for the work, carrying one real use case through the build loop, with a business SME dedicated to it rather than lending it a few hours a week. Scope bounds the work and says what would count as failure. Scaffold is what the team builds on, which after the first pass is the estate the last iteration left standing, thickened by whatever the platform has gained since. Specify turns intent into checks that pass or fail. Ship puts the result in front of users and reads what happens, and what it reads is what the next Scope is written from. Each pass round the loop is one iteration, and every iteration ends in a release. Something working is demonstrated every week, thin slices go through the full production checks rather than waiting for wider function to be ready, and the use case is finished when it has been released to real customers, adopted by the people whose job it is, and is producing value you can measure. Then we move to the next team. The one we have just left carries on without us, which is why the tenth team is faster than the first.
Organise
How the firm is arranged, staffed and funded.
Build
How systems are designed and built, and on what material.
Assure
How the firm stays safe and provable while it moves fast.
We read how your firm works as nine disciplines in three domains. Organise is how the firm is arranged, staffed and funded: structure, talent and finance. Build is how systems are designed and made, and on what material: architecture, engineering and data. Assure is how you stay safe and provable while moving fast: risk, security and ethics. A team advances all nine while it runs a single use case, so nothing has to be adopted wholesale.
The programme that runs this pod after pod is the Crucible. What it builds is your AI-native operating model. In most firms an operating model is a target drawn on a slide and left to drift from what the firm actually does. Ours is instrumented rather than described: each discipline runs as a skill with its own specifications, policies, tests, guardrails and cost, so the way you work can fail a build on the day you stop working that way. AI changes activities right across the firm, reflected in the nine disciplines we cover, which is why all nine move together rather than an AI capability being bolted onto the way you worked before. Each discipline arrives as two things: a curriculum your people are taught against your own estate, and software installed into your own tooling that holds the discipline while they build. Neither works alone. Training without the software fades by the second Increment, and the software without the training is a control estate nobody in the firm can argue for.
We are precise about what is ours to fix and what is not. A gap in a practice is a thing one of the nine disciplines says should be true of your team and is not: no named owner on a data source, a standard that cannot fail a build, an obligation with no control against it. That is the programme. A gap in an assumption is ordinary engineering, data or security work the method takes for granted and does not teach, continuous delivery, data management, security operations, three lines of defence. We name those, give each one an owner, and price them separately, and they are often better met by training than by a programme. A firm told the difference stops expecting us to fix its release pipeline, which is the conversation that otherwise arrives in month four.
How an engagement runs
A call, then three stages, each one bought with the evidence of the one before it. You commit to one stage at a time.
Thirty minutes to understand the challenges and opportunities as you see them. If a diagnostic day would tell you something you do not already know, we book one. If it would not, we say so.
One day on site, at no charge. One room, no deck, and your people come to us in half-hour sessions. Every question asks whether a named artefact exists and when it last changed; we rate the artefact from nought to five, and we never rate people. You leave with a plan for what to do first, and the evidence behind it: a map of the nine disciplines against your own executive's ranking of them, a register of every artefact we asked about, and a shortlist pairing your candidate teams with your live use cases, with a named first iteration. The shortlist is where the selection starts rather than where it ends: your leadership confirms the first three on day one of the workshop, day three reopens it with two days of building behind it and widens the map to the rest of your estate, and from then on your own people re-rank it as results land. All of it is made in the room and shown back before anyone goes. Bring the use-case list as it actually stands, including the ones you dropped. Nothing needs tidying first, because what gets removed in tidying is usually the evidence we came to see.
One to three days, charged from day one. Day one gives the whole leadership, not just the programme team, one shared account of what the technology changes and what it does not; programmes fail when two directors spend a year using the same words to mean different things. It ends in named teams, each with a business SME released to it full time, a named accountable executive and dates, confirming or amending the three pairings the diagnostic shortlisted rather than starting the argument from nothing. Day two is hands-on with the teams the coaching will run in: it stands up a sandboxed instance, and each team takes its own use case through Scope and Scaffold in the room, so they leave with something running rather than notes. Day three builds what outlasts the workshop: how the practice is tracked, how the pipeline of teams and use cases keeps filling, and the route by which the first slice actually goes live, gates, signatory, rollback and elapsed time. It reopens the selection with two days of building behind it, widens the map past the first three, and closes on the plan for the first quarter.
Three teams, three months. The quarter is the unit you buy, and one pass of the build loop inside it is an iteration. In week one the sandboxed instance is wired into your environment under your change control, so nothing is rebuilt. After that the cadence is fixed: ship working software at least weekly, and in the review your teams already hold, walk the disciplines that week's work touched and write the answers back. All nine are re-rated when a use case finishes an iteration, when a team joins, or when a use case is added, and the re-rating is what writes the plan for the quarter after it, naming the use cases, the teams and the training in priority order. The rating rules do not become more generous once you are paying.
You extend by buying the next quarter rather than by signing a long programme at the start. It does not have to start large: applied to a single team and a single use case, the Crucible is still the whole method, run small.
We do not bring a delivery army. The method and the coaching are what we sell, and hands-on engineering stays with your teams or with an engineering partner working alongside them, so the change in how you operate and the build advance together.
Not slides, and two things rather than one. Working solutions to real business problems, running in production and adopted by the business, with the measured effect on the numbers you named: that is what pays for the Increment. And the operating model that produced them, instrumented rather than described, held in the nine discipline skills and the eight shared registers your pods have extended, each carrying its evaluations, guardrails, cost profile and observability, so the way you now work can fail a build on the day you stop working that way. Pods that have changed how they work and can run the next iteration without us. An AI platform grown in the order your use cases required. A dated re-reading of the nine disciplines laid over the baseline from the free day, a record of what was claimed against what was evidenced, and the prioritised plan for the next Increment that the re-reading produces, naming the use cases, the teams and the training. The application is the value; the skills are what make the next application cheaper and the way you built it repeatable.
The templates and the method are ours; everything your teams write into them is yours, and it stays when we leave.
Real incidents, told by practitioners and stripped of anything that would identify anyone
Start with thirty minutes, and the day that follows costs nothing
A call on what you have running and what has stalled. If a day on site would tell you something you do not already know, we book one: one room, one day, and you leave with the map, the register and the shortlist, made in front of you. Nothing arrives by email a week later.
dromologue.ai
TERMS · HOW WE USE AI · COOKIES