Weirdly, almost nobody in engineering is talking about that file - Skills.

The conversation is about agents: how to build them, orchestrate them, evaluate them, chain them. As usual, we in technology have spent a year describing the new technical workforce (agents - before we become theirs) and saying almost nothing about how their work is described. That same error got us into all sorts of trouble with micro-services. By the time we had finished patting ourselves on the back for this new architecture we suddenly realised that the description of those granular services often didn’t map to the job to be done.

Nobody adopts a platform. They adopt a way of doing a job. The reason skills spread faster than agents is not that they are more powerful. They are smaller. A skill is a description a competent person can write in an afternoon about work they already do, and the thing that reads it is often already installed - e.g. the harness you are using, which instructs its agents with your skills.

The name and description of every skill are loaded at startup; the body is read when the job is invoked; the scripts and reference files are opened only if the work reaches them. An organisation can hold a hundred descriptions of its own work in front of a general model for less context than one of them consumes once it is running. That is a different acquisition curve from agent building, and a different budget line.

The agents do the actual work. But the skill describes the work to be done.

The word agent has the answer inside it. From agere, to drive, to do: an agent is one who acts on behalf of a principal. There is no such thing as agency in the abstract; there is only agency conferred, bounded and instructed. Every serious debate about agents is a debate about the quality of the instruction, that seems to hide the instruction itself!

The model context protocol, the open standard by which a model reaches external tools and data, supplies a good example connection. MCP does not supply the procedural knowledge for using that connection well. Anthropic’s engineers reported a five-server configuration consuming around 55,000 tokens in tool definitions before the user had said anything, and a Google Drive to Salesforce workflow that fell from 150,000 tokens to 2,000 when it was rewritten as code the model called on demand rather than tools stuffed into its context.². That is one illustrative case rather than a benchmark but the independent tests since have gone the same way. The lesson is not that tools are bad, it’s that they need context. In terms of the example above, they need to know when and what to ‘demand’…

Clayton Christensen, looking at product design, had a great insight. The critical unit of analysis, he realised, is the circumstance and not the customer.³

People do not buy a milkshake; they hire one for a long commute and a boring drive. The competition is a banana. His framework - Jobs To Be Done - is a lens for finding the job the buyer is already trying to do. When thinking about what we need to get AI to do, we need to think of our jobs to be done first… and then think about how to make the milkshake and what flavours it might have.

McKinsey’s 2026 global survey found eighty per cent of respondents reporting that AI had improved their own productivity, while the share reporting any EBIT impact at all sat at thirty-seven per cent, essentially unchanged from a year before⁴. The organisations getting financial return were the ones that had redesigned the work rather than inserting AI into work as it stood: nearly three-quarters of high performers against a quarter of everyone else.

The year before, the same research put the proportion scaling agents in any given business function at no more than ten per cent. The much-quoted MIT finding that ninety-five per cent of enterprise generative AI pilots return nothing is preliminary and contested on its method, and the reason its authors give still holds up against everything beside it: the failures are not model failures, they are a learning gap, brittle workflows and misalignment with, you guessed it, the jobs to be done.

Where agents do belong, they belong small. Ten steps at ninety per cent reliability each succeed about a third of the time; at eighty-five per cent, a fifth. The arithmetic is the whole of the production problem with long autonomous chains, and no amount of enthusiasm alters it. What raises reliability in deployed systems, on the evidence published so far, is structure around the model rather than a better verification step at the end. Skills can be used for scoping, routing and handoffs between specialists whose work can be checked.

OWASP’s 2026 top ten for agentic applications puts it in one line every architect should steal: autonomy is a feature to be earned, not a default setting⁶. Obviously, least agency sits beside least privilege. An agent should be scoped to a singular task, carry short-lived credentials for that task, run inside a sandbox with an egress allow list, and be registered somewhere a human can find it. Engineers build that today. A business analyst does not. But in my view, they do so together in small pods - working with each other and iterating on getting the match between the job to be done and its granularity of execution right.

A caveat exists though. Rich Sutton’s⁷ view is that hand-built structure loses to general method plus scale, again and again, over decades. Applied here it says skills are a kind of scaffolding, and scaffolding is what the next model absorbs. The people building the harness, the program that holds the model and decides what it can see and call, say this openly: bet on the model, not on the wrapper; build the feature even though you will delete it in three months. Lance Martin at LangChain watched his own multi-agent research structure become the bottleneck as models improved, and warned that abstractions are dangerous precisely because they make structure hard to remove⁸. One comparison on a hard agent benchmark found that swapping the model moved pass rates roughly three times as far as swapping the harness. If you are betting on anything other than raw capability, the last five years say you lose.

This kills a particular kind of skill: the one that tells the model how to do something it could work out - NOT the job to be done in your company. Maybe a model can infer how to draft a payment message based on pervasive message standards like Swift, PSD2 etc. But it cannot infer that your bank changed it’s tolerance for anti money laundering and that a new process exists for vetting certain kinds of transactions.

That is not scaffolding around the model. That is the precise well formed requirement, and the requirement has always been the scarce artefact in enterprise software. More so, managing its evolution over time…

It’s not all rosy for the skills though. Business users authoring their own automation is a prediction that has failed three times. Spreadsheets, then low code, then robotic process automation: one survey of citizen development put fifty-four per cent of projects down as failures inside a year and fewer than one in five as clear successes, and the failure modes were ungoverned logic, no engineering involvement and a silo per tool⁹. A hammer does not make a carpenter.

Skills also come with a new attack surface. Snyk’s study of one public skills marketplace this year found prompt injection in thirty-six per cent of a sampled set and over a thousand malicious payloads, in a market where daily publishing had grown roughly tenfold in three weeks¹⁰ .A markdown file that instructs an agent holding your credentials is exactly what Simon Willison calls the lethal trifecta: private data, untrusted content, and a way out.

These are arguments about what a skill is. Treat it as a personal macro downloaded off the internet and you have built the worst of low code with a credential attached. Treat it as a governed description of how this organisation does a piece of its work, held in a registry, reviewed like code, versioned, owned by a named person and executed under least agency, and you have something the citizen developer wave never had: one artefact that is simultaneously the requirement, the documentation and the running instruction.

Ask what your AI programme has produced this year and maybe you will be shown a list (or demo?) of agents, a platform diagram and a count of pilots. Ask for the list of jobs and there often isn’t one.

An organisation that can describe its work can buy any model and swap it next quarter. An organisation that cannot will keep building agents that do something nobody asked for, faster and at greater expense, and will call the result a capability.

As professionals in this space, we need to get back to talking about the jobs to be done, enabling our users to define them using skills, and building processes and tests that make that safe and easy for the new kinds of builders we are about to unleash.

What is the change that we have been clamouring for? The simple idea that building and shipping real working software and improving it incrementally through feedback from users is the best way to deliver value. Those who build something should run it and fix it too. large designs (or intentions) up front anticipate features useful to customers rather than actually eliciting them. We eliminate waste by shipping what we know is needed (although our solution may be novel) with as small a team as possible (minimising handoffs) and iterating from there. It’s all in the original ‘Agile Manifesto’ and the Lean / TPS canon.

All organisations wanted these benefits, but most interpreted the reduction of waste (muda in TPS terms) as increase in delivery velocity. And so a narrative grew around how to ship faster, not ship better. Methods like SAFe, took the commercial gap and offered an approach to this that was coherent with existing organisational structures and ways of working. The ceremonies of stand-ups, release planning etc didn’t actually change how an organisation saw and planned value, it just created an organisational interface between technology delivery and a business operating model that goes all the way back to Frederick Winslow Taylor. It is worth noting that not a single practicing software engineer or architect I know has any truck with SAFe. The point is not to criticise SAFe per se (it was a good commercial opportunity), but rather to point out that it is a symptom of which we speak… commercially successful new methods of working were adapted to existing ways of running a company not the other way around, and in so doing were blind to the inputs of those actually doing the building.

The same thing happened with DevOps. And it’s mutant marketing cousin, DevSecOps1. The reduction of handoffs between development and operations, and the creation of smaller end to end accountable teams was replaced by ‘DevOps’ teams. Who were basically operations teams. The much vaunted ‘shifting left’ of security did result in some security testing and other ‘policy as code’ initiatives but usually was throttled by the capacity of security teams to advise earlier. In both these cases, existing organisational structures in technology functions proved hard to change. We became the problem. The SRE (site reliability engineering) movement attempted a rear-guard action to bring visibility to the results of poorly managed change on production, but again we ditched things like failure budgets that defined the trade-off between change and stability, and created SRE teams.

None of this was helped by the fact that management consultancies with no actual experience building and running systems produced strategies inferred through top-down observation of many clients. Most of what was proposed withered in implementation - their recommendations were usually an extension of the idea of increasing differentiation of labour - separating change from run being a favourite - and this further entrenched the creation of specialist teams like devOps, SRE etc. So we’re back to Frederick Winslow Taylor or perhaps Henri Fayol.

Of course, firms did also look elsewhere for help. They looked at the hyperscalers and frontier software companies like Google, Amazon, Facebook, Netflix etc. These players, especially those selling services, were keen to share how they did things. But when asked how to get there from ‘here’… they were either silent or confused.

And yet… some companies did make the move. The so-called disrupters with the ‘tech’ suffix: Fintech, Regtech, InsurTech, EdTech… They were smaller, had less legacy process and technology to change, hired people with sector knowledge but less commitment to an established organisational career path, typically focused on a specific part of the market and, importantly, were less regulated. With a few exceptions (like Revolut) these ‘disrupters’ didnt change the market much. In banking for instance, they fought over the less sticky customers - generally more price sensitive and financially savvy. But the majority stayed where they were. Even, in the case of the UK, given a regulated guarantee enabling you to switch banks for free and open market initiatives like Open Banking and PSD 2. So much for the scrappy startups with amazing UX shipping changes every week and integrating a whole new financial ecosystem taking on the big banks. Even in the case of those that could move, it seemed that the threat to the big players was marginal.

There may not have been a serious threat but there was also significant inertia. And advantage in the inertia. The larger players, like global banks, pharma and retailers had huge amounts of customer data and well established channels that enabled cross-sell and up-sell. These barriers to entry were coupled with huge legacy estates and entrenched expert leadership mindsets. I characterise this kind of leadership as wanting to build a career (or more generously, a business) not a thing.

The entrepreneurial drive that seeks to build something truly new was either missing or fatally constrained. So very few of them (uh, us?) took the risk to fundamentally change how they operated in order to produce something that was not possible given how they currently operated. Not many firms were willing to go to the public markets and talk about radical organisational change being necessary due to a bunch of heavy metal t-shirt wearing, ponytailed engineers talking about a new future… We all agreed to re-label what we did do - train a few thousand in ‘agile’, DevOps etc. - as radical, call it ‘digital transformation’, and declare a win.

All of this manifests in an attenuation of feedback:

• When we ship software, feedback from users is very slow to feed back to those who built it, resulting in poor prioritisation of what to build or fix next. Customer feedback leaks and all the builders get is a trickle.

• Once we have deployed software, feedback from production operations - performance, scaling, security threats - is diffuse and generally only happens when there is what we euphemistically call, ‘an incident’.

• When we ship software, the signals that tell us if the software is generating the customer behaviour we wanted and therefore generating the value we planned the release on, are either missing or so attenuated when technology receive them that they don’t change our build behaviour at all.

The result of this is that to many firms, technology remains a valuable but rather flaky capability and letting its promises shape how you run the company is likely not a good idea.

In essence, for large established businesses where technology is not literally the core proposition it offers (e.g. Barclays, not Microsoft or Netflix) the critical barriers to organisational change, or the material cause of organisational inertia, has been threefold. Technology has revolutionised markets and it managed to do so without requiring fundamental organisational change. So why change?

• Whatever new things we do, we still have to manage, integrate and run the old things and these old things typically need to be worked with in a certain way. That cost will always dominate in proportion to the size of the firm and what it has to lose.

• Scale remains the single most significant protector of market position. When true innovators challenge the cost / value equation (as discussed by Schumpeter or Christensen) that new scale results in decay not change of the old order.

• When we do a new thing in a new way, it is safer to compartmentalise it and apply it to a well defined but less critical part of the business, where success is exceptional - by definition - and therefore the lessons not applicable to the ‘core’ business.

So where does this leave us? Most large enterprises still ship infrequently, manually test with a 3rd party, have large projects that surprisingly fail at the last production hurdle and exhibit low trust between business and technology functions. It still takes ages to get anything done. That applies to everyone, so it’s OK. Even the hyperscalers now have huge legacy tech debt which slows them down. It’s a race to diminishing marginal returns unless we do something different. Must we?

In my view, AI is a revolution of translation. That sounds minor, but it isn’t. The word, translation is used because it entails a sender and a receiver actually achieving common understanding. A foment has been whipped up by AI code assistants and chatbots, but the furore over the ease and autonomy of AI obscures a deeper change under way of how we translate our requirements into reality and respond to feedback about how they fit with that reality. In other words, understand if we got it right. As the examples above show, we have always had not only a problem of translating requirements into specifications for building but also poor signals enabling the improvement of these specifications. Because the process has been so heavy, and organisationally so fraught, we figuratively went with our first draft translation almost every time.

What if translation were really cheap? It is this change that holds within it the motive power to restructure how every company builds, sells, ships and advises but more importantly, in the light of the comments above, force companies to do so.

We know that with AI, ‘making’ software is now cheap. You can argue all you want about its internal design decisions, how idiomatic the code is and so on, but the reality is that whatever fault you find with it, it can be iterated and improved in hours. The competence required has moved from (code) syntax to (business) specification AND improvement. In other words, writing the code and describing what you want the code to do is very rarely right first time. So, inherent in (rather than just described in, an SDLC) the approach we begin to take today is an efficient, fast and cheap feedback loop. This simple mechanism of real translation radically reduces the cost to change. Small incremental experiments are also safe.

The efficiency of this basic requirements feedback loop makes it cheap to allocate experts to the specification process. Instead of reviewing long specification documents, they can participate in the creation of solutions in parallel with the documentation of them. The issue of course, is whether this will actually happen. Will business experts continue to be pigeonholed in their part of the ‘legacy’ process? Probably yes - unless you follow our Crucible approach - but the probability of a breakout event is much higher than ever. The barriers to translation are now close to zero. All you need is a few examples of “… hey could you spend a few hours with me working on this project?” resulting in, “I can’t believe we got so close to what I wanted in just a few hours!”

Taken across whole industries, this will happen more and more - this dynamic and opportunistic counter-structural allocation of resources. Already we see it in ‘business’ led AI initiatives using chatbots like GPT, Copilot, Claude etc. Who are the ‘engineers’ in this scenario? Most of these improvements are fairly simple (but effective) productivity enhancers for processes and reporting but what happens when whole business capabilities are transformed at this speed and efficiency? A new archetype emerges, ‘The Builder’, to which I will return shortly. But first, consider the impact of these ‘breakouts’ where traditional business and technology staff start co-creating together. Compartmentalisation becomes very difficult to control. In Dromologue’s change model, “I can’t believe we got so close to what I wanted in just a few hours!” becomes an ‘event’ - an organisational truth (that the existing process is for the best) turned on its head and showing a new way of working. Events change organisations. Not townhalls. Not posters. Not insipid corporate emails. Events.

These organisational events will themselves become industry events and all of a sudden, the personal risk to leaders of making the changes needed to bring about more of these events is far outweighed by the successes of those already making those moves. Certainly, one of these moves will be the use of AI to rewrite, refactor and replace the legacy tech that has been such a handbrake to operational cost savings in large enterprises. As an example, most large enterprises migrated applications to the cloud without refactoring and in so doing created the illusion of a cloud oriented ecosystem while enjoying few of the scalability, velocity and cost benefits of native cloud applications. The reasons are the same as those above. It was risky to re-engineer for an unclear economic benefit, while ticking the cloud migration box was an easy win. Cloud was always a method and not a location, but it was easier to ride the industry orthodoxy wave and not be left out2. The metaphor of translation with respect to re-writing software is very apt: we suddenly discover how much waste there was in the original implementation and find - only through talking to those who use the application - exactly what needs to be provided in the newer version.

None of this changes the scale argument though. In this, I’m influenced by the economist, Joan Robinson; that demand in the major (non-technology) sectors will continue to be shaped by the major scale players and how skilled labour is applied will be shaped by them3 and in so doing fundamentally restructure how technology is used across many industries, including the disrupters. The question then remains: How do you scale from a few ‘breakouts’ to an organisation wide approach to building that maximises the translation benefits of AI?

Our view is that organisations configured to maximise these benefits will emerge at an increasing rate as the benefits of the smaller experiments start to turn into real bottom line value. The configuration of these firms will be based on a new archetype of ‘Builder’ and not engineer, business analyst, SME etc. Those skills will remain important (and will of course evolve) but the delivery of value will no longer be in the form of what we think of today as the project delivery lifecycle, with well defined organisational boundaries between business and technology. The modern enterprise will be comprised of teams of builders; comprising engineering, business domain, architecture and finance skills; aimed at delivering bottom line value for a well defined organisational capability that they own end to end. In other words, a small team owns the translation of value for a valuable part of the enterprise.

It is no small challenge to transition from having a 100 AI ideas, and a dozen in production, to the kind of organisation that ALWAYS works this way. It requires a change in how you organise, how you build and importantly, how you assure (the accuracy of your translation). Dromologue.ai is built on the simple idea that if everyone has AI technology your differentiation and ultimate success comes from how you configure your company to use it.

You don’t have to be the first to break out, but you do need to be ready to move when you need to, and the speed at which you will be required to move will be far faster than your current operating model allows.

Subscribe now