dromologuedromologue.ai
THE BIG IDEA OUR APPROACH THE ENGAGEMENT Arrange the day
DROMOLOGUE.AI  ·  SEPTEMBER 2026

How we work with clients

The Big Idea, Our Approach, and Your Outcome.

Start reading SCROLL  ↓
WHAT THIS IS

The question is not what we will do. It is what you will own at the end.

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.

PART ONE The Big Idea Why the return on AI arrives late, and what actually causes the delay. PART TWO Our Approach The unit we change, the rhythm we work at, and what one iteration does. PART THREE The engagement One free day, a workshop, an Increment, and what you keep if you stop.
a demonstration ends with the engagement; a practice does not
PART ONE

The Big Idea

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.

83% HAVE ADOPTED AGENTS
84% HAVE NOT REDESIGNED THE WORK

Everyone has deployed. Almost nobody has redesigned.

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.

MEASURABLE RETURN 80% report measurable economic return from their agent investments, in a survey of more than five hundred technical leaders. ANTHROPIC WITH MATERIAL
SIGNIFICANT RETURN 29% report significant return from generative AI, falling to 23 per cent for agents, across 2,400 employees and C-suite leaders. WRITER
WHY BOTH ARE TRUE Measurable is a reading on a use case. Significant is a reading on a business. Both are credible. The returns split along the same line as the deployment does.
SALESFORCE  ·  DELOITTE  ·  ANTHROPIC WITH MATERIAL  ·  WRITER deployment is a purchase; redesign is a decision
THE SPEED GAP

The technology doubles every four months. You replan once a year.

Two clocks, running at different speeds. The distance between them is the whole problem.

2019 TO 2025 7 months to double the length of task an agent can finish.
FROM 2023 4.3 months The same measure, on the more recent data.
FROM 2024 ~3 months Nearer three, and still shortening.
WHERE THAT HAS REACHED

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.

AND IT STILL HOLDS EITHER WAY The capability arrives in months. The planning round arrives once. Halve the highest figure for the saturation and the argument is unchanged, because the argument is the gap between two clocks and not the reading on either.
Model capability task length doubles every four months
×2 ×2 ×2
Your operating model changes once, in the planning round
one planning round
MONTH 0MONTH 4MONTH 8MONTH 12
METR, TIME HORIZON 1.1 AND THE TIME-HORIZONS DATASET the models are not the constraint; the cadence is
WHERE THE VALUE SITS

Most of the budget goes to the cheapest thirty per cent

10 algorithms
20 technology and data
70 people and process

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.

THE MOST COMMON CAUSE OF FAILURE AI projects fail at about twice the rate of other technology projects, and the leading cause is disagreement about what the system was supposed to do.
AND THE MEASUREMENT UNDERNEATH 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.

WHAT TECHNICAL LEADERS SAY STANDS IN THE WAY
System integration
46%
Data quality
42%
Change management
39%

The model is not on the list.

BCG  ·  MCKINSEY  ·  ANTHROPIC WITH MATERIAL  ·  RAND CORPORATION the cheapest thirty per cent absorbs most of the budget
PART TWO

Our Approach

One small team formed for the work, one real use case, a release every week, until it is in production and adopted.

THE ENGINE

We are building an engine, not running a pilot

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.

TEAM ONE The first pass
TEAM TWO Starts further along
TEAM THREE Faster again
TIME TO PRODUCTION
VALUE IT DELIVERS
A use case live in production, and adopted
A use case live in production, and adopted
A use case live in production, and adopted
CHANGE IT DELIVERS
Disciplines moved in the operating model, instrumented and evidenced
Disciplines moved in the operating model, instrumented and evidenced
Disciplines moved in the operating model, instrumented and evidenced
WHAT THE NEXT TEAM INHERITS
The scaffold, the discipline skills and the contracts to your core inherited without paying for it again
COMPOUNDING
each team starts where the last one finished
That is the engine: value in production now, an operating model that can be run rather than described, and a shorter run for every pod that follows.
a pilot delivers once; an engine delivers every quarter
THE UNIT OF WORK

The unit of work is the release, and an increment produces two things

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.

ONE, AND IT CARRIES THE VALUE CLAIM The solution, in production A working answer to a real business problem, in real use, with a measured effect on a number your business itself named. It reaches you as a customer release, and no other kind of release is reported to you as value.
TWO, AND IT IS WHY THE FIRST ONE REPEATS The operating model, instrumented Held in the discipline skills your team writes and keeps. The skill is also the unit in which AI is consumed, by your people and by your agents alike, so instrumenting the disciplines is how you govern both.

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.

the application is the value; the skills are the operating model made operable
THE RHYTHM

Working code every week. No exceptions.

Working code that does something useful, demonstrated. Not a prototype, and not a slide showing what the prototype would do.

W1
W2
CR
W4
SUB
W6
W7
W8
W9
W10
W11
LIVE
FOUR KINDS OF RELEASE CARRY THAT RHYTHM
Demonstration Proves a technical capability or shows a business requirement met. Tested for what it demonstrates rather than taken through the full production checks.
Build The nightly build of the whole system, with its test results and dependency checks readable on it.
Production Weekly. Takes the full system through your production checks and goes to your own stakeholders for direct feedback.
Customer In front of real customers, progressively where that suits, by ramp, canary or A/B test.

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.

AND THREE MILESTONES, WHICH ARE WHAT THE INCREMENT IS JUDGED ON
AS EARLY AS IT CAN BE MADE TO HAPPEN The first customer release A thin slice, fully compliant, in front of real users.
WITHIN A MONTH Substitution Usable by a subset of users, in place of the alternative rather than alongside it.
BY THE END OF THE INCREMENT Live Replacing the alternative, and embedded in how people now work. That last one is the hard one, and the only one that counts as finished.
the weekly demonstration proves motion; reaching customers proves change
HOW IT IS MEASURED

Four metrics, and they all roll up from the pods

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.

Organise how the firm is arranged, staffed and funded
Structure
Talent
Finance
Build how systems are designed and made, and on what material
Architecture
Engineering
Data
Assure how you stay safe and provable while moving fast
Risk
Security
Ethics

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.

ARE WE IMPROVING AT ADDING VALUE Value per cost, per customer release Value is the revenue attributed to the release plus the costs it reduced, read a month after the release, because value is measured in front of customers.
ARE WE IMPROVING AT BUILDING Backlog to production, elapsed The days a release waited on your own signatures are subtracted, then reported beside the figure by gate and signatory, because a gate is your governance and not our delivery.
IS OUR CONFIDENCE IMPROVING Obligations discharged by a policy that can stop a release Obligations discharged rather than policies written, because counting policies rewards writing policies. A check that only inspects does not count, and an obligation met by a named person signing is reported with its signatory rather than counted against the team.
IS OUR OPERATING MODEL IMPROVING Practice conformance, per team Counting only what was observed, reported with a nine-way cut so you can see which of the nine disciplines moved and which fell.

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.

four questions, answered from the work
WHAT ACCUMULATES

All applications decay. Two things appreciate.

The application this Increment builds is still the thing that pays for the Increment. These two are what make the next one cheaper.

REPLACED IN TIME
Application
Application
Application
Application
BETTER EVERY TIME SOMEBODY USES THEM
Nine discipline skills One for each discipline, holding how your firm architects, funds, staffs, secures and governs this kind of work, and written in five parts your own people learn to write: Purpose, Principles, Practices, Platform and Plan. Together they are the instrumentation of your operating model rather than a description of it. Paper two takes each of the five apart.
Contracts to your legacy core What the AI systems may ask of the core systems, in what form, with what guarantees, and what happens when the answer changes.

These two are your organisational memory and your organisational context. Together they form a single surface.

an application depreciates; a practice appreciates
PART THREE

The engagement

Three months is the unit. You extend by buying the next unit, not by signing a long programme at the start.

THE LADDER

Each step is bought with evidence from the last

STAGE ONE · NO FEE One day On site. A map, a register, a shortlist and the sponsor's priorities, made in the room.
STAGE TWO The workshop One to three days. Leaves a running scaffold and an Increment designed.
STAGE THREE The Increment Three pods, three months. Use cases in production and a surface built.
OPTIONAL The next Increment More teams, or none. You decide with three months of evidence in hand.

Which step you start on is read, not chosen

The free day places you on two axes, taken from your own artefacts rather than from a questionnaire. Each reads low, medium or high.

ORGANISATIONAL How well you can decide, fund, staff and govern this work Read from Structure, Talent and Finance.
TECHNICAL How well you can build, run and operate it Read from Architecture, Engineering and Data.
A FLOOR, NOT AN AXIS Risk, Security and Ethics sit under both A firm that cannot say which obligations apply to a change, or stop a release against them, starts at the bottom whatever else it reads.
TECHNICAL LOW A workshop rather than an Increment, sized by the other axis. Day one where the organisational reading is low. Day one and a use-case selection where it is medium, so you leave holding a sequenced backlog you can fund. Days one and three where it is high, adding the change-leadership material and a first Increment designed. Day two, the hands-on build day, is left out of all three: a build day at a firm that cannot yet ship produces a demonstration and no capability.
TECHNICAL HIGH The Increment, whatever the organisational reading, because a firm that can already build has its problem above the build.
BOTH MEDIUM OR BETTER The Increment.
BOTH HIGH You take the nine discipline skills under licence and run them yourself. That is rare on a first reading, and is usually where a firm arrives after two or three Increments.

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.

every step is bought on the evidence of the one before it
STAGE ONE

One day, on site, no fee

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.

The sponsoralone, first, before hearing anything from us
Your senior leadershalf-hour sessions across the nine disciplines
Two or three delivery teamshow would you take a live use case to production
The sponsor againto receive the result and set the priorities
WHAT WE ASK

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.

HOW WE RATE

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.

The map The nine disciplines plotted against your sponsor's ranking and against what you can evidence. The useful part is where our rating and your ranking disagree.
The register Every artefact we asked about, its level, and whether we saw it, were sent it, or were only told about it. What does not exist becomes named work in the first iteration.
The shortlist Your candidate teams paired with your live use cases, naming a provisional first three. This is where selection starts, not where it ends.
The priorities The areas of focus, ranked by the sponsor at the end of the day, against the map and the register. This is the input to day one of the workshop.
The placement Where the day puts you on the two axes, set beside where you placed yourself before it began. Your own words against your own artefacts, which is usually the most useful thing anybody learns.

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.

asking when an artefact last changed moves a lot of ratings down a level
WHAT WE NEED FROM YOU

All we need for the first day

01A room, for one day.
02Time with your senior leaders, in half-hour sessions.
03Two or three delivery teams, for an hour each.
04Your use-case list as it stands, including the ones you dropped.
05Whatever figures exist on AI spend, and on how many pilots reached production.
06A sponsor who will open the day, and close it by setting the areas of focus.
ONE REQUEST Do not tidy anything first. What gets removed in tidying is usually the evidence we came to see.
PARTNERS

If a partner already owns the build

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.

TERM ONECoach alongsideWe coach alongside their delivery teams, at their cadence.
TERM TWORe-sequenceWe take a stalled programme and put its work back into an order that can be justified.
TERM THREERun it as the CrucibleWe run the whole arrangement. Only this one builds you the surface.
we work with the firm that owns the build, not around it
WHAT WE WILL NOT SAY

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 WILL

After 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.

IF YOU STOP AFTER ONE INCREMENT, YOU KEEP ALL OF IT
The use cases running
The teams that have changed and can run the next iteration without us
The surface those teams built
And the plan, whether or not we are the ones who run it

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.

THE PAPERS

The mechanics, for the people who will run them

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.

PAPER ONE How one team runs a use case Scope, Scaffold, Specify and Ship; why the platform grows in the order the use cases require and not before; the four kinds of release; and the three milestones an Increment is judged on.
PAPER TWO What a discipline skill contains The eight parts of a skill, the five Ps your people learn to write, the surface every team reads from and writes back to, what each discipline assumes rather than teaches, and who owns what at the end.
PAPER THREE The engagement, in detail The diagnostic day hour by hour, the workshop day by day, the Increment and its cadence, what the engagement asks of you and cannot do without, and the three terms on which we work alongside a delivery partner.

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.

the page is the argument; the papers are the mechanics

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: 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.

Book a call OR WRITE TO TRANSFORM@DROMOLOGUE.AI
SOURCES
2026 Connectivity BenchmarkSALESFORCE State of AI in the Enterprise 2026DELOITTE The 2026 State of AI Agents ReportANTHROPIC WITH MATERIAL 2026 AI Adoption in the EnterpriseWRITER Time Horizon 1.1METR Task-Completion Time Horizons of Frontier AI ModelsMETR The State of AIMCKINSEY From Potential to Profit : Closing the AI Impact GapBCG The Root Causes of Failure for Artificial Intelligence ProjectsRAND
dromologuedromologue.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