The Big Idea, Our Approach, and Your Outcome.
A demonstration is not an answer, because it stops when the engagement stops. This page describes the engagement in terms of what it produces and who ends up holding it.
You are not paying for better models. You are paying to close the gap between how fast the technology moves and how fast your organisation can change.
Three readings, from three different studies, and the distance between them is the argument.
Salesforce finds 83 per cent of organisations reporting that most or all teams have adopted AI agents, running a dozen on average and expecting twenty within two years. Deloitte finds 84 per cent have not redesigned jobs or the nature of work around AI. Different samples asking different questions, which is the point: one measures what has been bought, the other what has been changed.
Two clocks, running at different speeds. The distance between them is the whole problem.
By the spring the strongest assessed agents sat around twelve hours, and a preview model at about seventeen and a half, which is more than two working days of skilled software work. Take that with the caution METR attaches to it: the confidence interval on the highest reading runs from eight and a half hours to fifty-five, and METR states plainly that measurements above sixteen hours are unreliable with its current task suite, which is saturating.
BCG's guidance for an AI transformation puts seventy per cent of the effort in people and process. It is a recommended allocation rather than a measurement, and it is worth saying so, because the useful part is how few programmes match it.
McKinsey finds 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 that workflow redesign is the single factor most correlated with bottom-line impact. Only 39 per cent report any enterprise-level EBIT impact at all.
The model is not on the list.
One small team formed for the work, one real use case, a release every week, until it is in production and adopted.
Every pod we work with does two things at once. It puts a working solution into production, and it instruments how the firm operates. The next pod starts from both, and runs faster because of it.
What a team delivers is a release, and there are four kinds, from a demonstration that proves a capability to a formal release to your customers. Two things come out of an increment, and neither substitutes for the other.
A policy in a document is a claim about how you work. A skill carrying a specification, an evaluation set, guardrails, a cost profile and observability is that claim made operable, and able to fail a build on the day the firm stops working that way. That is what the investment in the discipline skills buys, and it is why an Increment that ships an application and leaves no instrumentation behind has delivered one of the two things. Every release improves the skills; no release exists in order to improve one.
Working code that does something useful, demonstrated. Not a prototype, and not a slide showing what the prototype would do.
The rule that makes this work is thin slices that clear the production checks, in preference to wider function that cannot, because compliance saved for the end of an Increment is compliance that fails at the end of an Increment.
How we read your operating model, and what every release is measured against. Change only Build and you get demonstrations. Change only Assure and you get delay.
All nine move together, or the return does not arrive.
The measurement is four numbers and not nine, and each answers a question rather than reporting an activity.
Every one is read per team and per release, and the enterprise view is computed from the team readings rather than measured separately, so there is no programme number your teams do not move.
Adoption is reported beside the value reading and is not a fifth metric: for every group whose work a release changed, how many of them used the thing and when it was counted. A release that earned its cost and that two of eleven people ever open is not the same result as the same ratio with all eleven.
Targets are set per release with your sponsor, before the release, with the basis for each number written beside it. Teams are never ranked against each other. What we decided not to measure is written down with the reason, because a refusal recorded nowhere is re-taken every Increment by whoever asks loudest.
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.
Each discipline also names the ordinary practice it assumes and does not teach: continuous delivery, data management, security operations, three lines of defence. That distinction is how you know what you are buying. A gap in a practice is the programme. A gap in an assumption is ordinary work, named with an owner and priced separately, and often better met by training. The frameworks we draw on are inputs rather than implementations, and we claim conformance to none of them: where you are bound by a standard, that standard governs and the method fits to it.
The application this Increment builds is still the thing that pays for the Increment. These two are what make the next one cheaper.
These two are your organisational memory and your organisational context. Together they form a single surface.
Three months is the unit. You extend by buying the next unit, not by signing a long programme at the start.
The free day places you on two axes, taken from your own artefacts rather than from a questionnaire. Each reads low, medium or high.
We also ask you to place yourself on the same two axes before the day, in your own words, and we do not look at your answer until the day's reading is finished.
Two consultants, one room, no deck. We spend the day with your senior leaders and two or three delivery teams, reading how the organisation thinks about AI and what it is actually ready to do. The sponsor closes the day by setting the areas of focus.
Every question asks whether a specific named artefact exists, and when it last changed. Not whether the capability is mature. Not whether the team feels ready.
Nought to five, on the artefact. Below three a control is advice. At three or above a control can stop a build or block an action. We never rate people.
You leave with five things.
No overall score, no benchmark and no industry percentile. A single number encourages you to manage the number instead of the disciplines. We do not write anything up afterwards and send it: a report that arrives a week later is easy to ignore.
We do not bring a delivery army. Hands-on engineering stays with your teams, or with the partner working alongside them. Where a partner owns the build we work with that firm rather than around it, on one of three terms.
We will not tell you how quickly your organisation can be made to change. Nobody can, and any firm that gives you a number is guessing.
WHAT WE WILLAfter one Increment you can see four things, and check every one of them.
Value delivered, meaning use cases live in production and adopted, with the measured effect on the numbers you named. Change in how you operate, meaning the nine disciplines re-rated against the baseline taken on day one, with the artefacts that moved. Maturity you can use, meaning an AI platform and the processes around it, grown in the order your use cases required rather than the order a vendor sells them. And a prioritised plan for the next Increment, naming the use cases, the teams, the training and the sequence.
If any of the four is missing, do not buy the next Increment.
We license a structure. Everything your teams write into it is yours outright, and so is every contract they write to your core systems and every application they build.
This page carries the argument. Three papers carry the detail underneath it, written for the people who will do the work rather than for the person who signs.
The papers sit in the portal, which is closed. Ask for the one you want and we open it, which is a smaller thing to ask for than a meeting.
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: a room for a day, time with your senior leaders and a few delivery teams, and a sponsor to set the priorities at the end of it. You leave that day with a map, a register, a shortlist and the areas of focus that open the workshop.
dromologue.ai
the numbers are other people's; the method is ours
CREATED 1 SEPTEMBER 2026 · LAST UPDATED 1 SEPTEMBER 2026
TERMS · HOW WE USE AI · COOKIES