Technology Management and Agent Readiness

1. Introduction

The subject of this paper is a regulated financial institution — a bank, an insurer or an asset manager — in the EU, the UK or Switzerland, with a delivery estate of several hundred to several thousand applications and an AI coding-agent programme under way. The reader I have in mind runs technology for such a firm.

The thesis is this. The unglamorous machinery of technology management now determines how much of the estate agents can work on. An agent consumes whatever structure exists and fills every gap with a plausible default. Where a system can be described, where a wrong change is caught cheaply, where it can be undone cheaply and where its outcome can be seen, an agent can do useful work. Where those properties are missing, no choice of model repairs the gap. Readiness is uneven across any real estate, change crosses many systems, and so the pace of delivery is set by the least-ready system on the path of each change. The systems on the most paths are the shared, old and central ones.

Two consequences follow. Every deferred upgrade, tolerated bespoke framework, GUI-only tool and undocumented convention carries a running cost in agent capacity the firm cannot use. In the other direction, agents are a cheap instrument for paying that debt down, provided the paying-down is governed like any other change.

What is evidence and what is argument. Section 2 reports published evidence and says who produced it. Section 3 is my argument; the instruments in sections 3.4 to 3.6 are design proposals and have not been tested in a controlled way. Section 4 turns the argument into actions. Section 5 states what the paper does not establish.

A note on two names. “DORA” in this paper means Regulation (EU) 2022/2554, the Digital Operational Resilience Act. The Google-owned DevOps Research and Assessment body of work, which shares the acronym, is called “the DORA research programme” throughout.

Terms. A station is a system, platform or shared tool that a change must pass through. A golden path is the sanctioned, pre-built way of building and running a class of application on the firm’s platform. Standing context is a file kept in a repository that an agent reads at the start of every session, such as CLAUDE.md or AGENTS.md.

2. Background and evidence

2.1 The discipline that existed before agents needed it

The instruments are familiar. The technology radar sorts technologies into rings and forces a periodic, named decision about what the firm builds on. Thoughtworks publishes the best-known example twice a year and encourages organisations to build their own; the edition current in November 2026 uses the rings Adopt, Trial, Assess and Caution, the last of which internal radars, in my observation, usually label “hold” [1]. Lifecycle and deprecation management does the same job at the exit: approved versions, support windows, sunset dates, forced migrations. Platform standardisation and golden paths reduce the variance between teams by making the sanctioned route cheaper than the bespoke one; the developer portal is the usual place they are published, with Backstage, a CNCF incubating project, as the common open-source framework [27]. Version discipline was the least loved of these practices, because its cost was quarterly and its payoff deferred.

The pre-AI evidence base is the DORA research programme, whose published capability catalogue includes version control, continuous integration, deployment automation, test automation, loosely coupled teams and, more recently, platform engineering as practices associated with software delivery and organisational performance [2]. That research priced these practices for human teams. It did not price a second consumer of the same structure.

2.2 Evidence that the delivery system decides AI returns

The DORA research programme’s 2025 report, published as “State of AI-assisted Software Development”, draws on survey responses from nearly 5,000 technology professionals and states that “AI’s primary role in software development is that of an amplifier” [3]. The announcement by the programme’s lead and its researcher puts the consequence in one sentence: “The greatest return comes not from the AI tools themselves, but from a strategic focus on the quality of internal platforms, the clarity of workflows, and the alignment of teams.” The same announcement reports that AI adoption now has a positive relationship with delivery throughput, unlike the previous year, and that it “does continue to have a negative relationship with software delivery stability” [4]. The previous year’s figures were an estimated 1.5% decrease in delivery throughput and an estimated 7.2% reduction in delivery stability for a 25% increase in AI adoption [5]. These are survey associations, not controlled effects.

The controlled evidence is narrower. METR’s randomised trial recruited 16 experienced open-source developers, who completed 246 issues in repositories they knew well. With the AI tools of early 2025 they took 19% longer, having expected a 24% speed-up, and afterwards still believed they had been 20% faster [6]. METR now marks those results as out of date. Its February 2026 follow-up, on the tools of late 2025, reports raw speed-up estimates of −18% for returning developers and −4% for newly recruited ones, both with confidence intervals that reach +9%, and calls its own new data “an unreliable signal” because of selection effects [7]. What survives, in my reading, is the gap between perceived and measured speed, and the observation that the trial ran where the developers’ own knowledge of the code was deepest.

GitClear’s analysis of 211 million changed lines written between January 2020 and December 2024 reports cloned lines rising from 8.3% to 12.3% of changed lines between 2021 and 2024, and lines associated with refactoring falling from 25% to under 10% [8]. This is one vendor’s data set and should be read as such.

On Scale AI’s SWE-Bench Pro public leaderboard, as opened on 10 November 2026, the top entry resolves 61.5% (±3.1) of the 731 public tasks [9]. A task counts as resolved only if the agent’s patch makes a set of failing tests pass without breaking tests that already passed. Two things can be said from this and one cannot. Even the best published configuration fails a large minority of realistic multi-file tasks. And the score exists only because every task ships with tests that separate a right patch from a wrong one. The score does not say what share of wrong changes an enterprise would catch; that depends on whether the firm’s own systems have an equivalent set of tests, which the benchmark supplies by construction and an estate supplies only where someone built it.

2.3 Agent readiness as a product category

The term is already in commercial use. Factory, a coding-agent vendor, sells an Agent Readiness product that evaluates a codebase “across 8 technical pillars and 5 maturity levels”. Its launch post of 20 January 2026 names the pillars — Style & Validation, Build System, Testing, Documentation, Dev Environment, Code Quality, Observability, Security & Governance — and the levels, Functional, Documented, Standardized, Optimized and Autonomous, stating that “each level represents a qualitative shift in what autonomous agents can accomplish” [10]. Open-source imitation has begun: one small repository describes itself as “the open-source alternative to Factory.ai’s Agent Readiness”, with 39 automated checks in seven pillars [11]. I cite it as evidence that imitation exists. It says nothing about the quality of either methodology.

Vendor guidance points the same way. Anthropic’s documentation for its coding agent summarises its own advice as “tell Claude what it can’t see, give it a check to run, and enforce the rules that can’t have exceptions”, and treats the repository’s CLAUDE.md file as the place for what the agent “couldn’t work out from the code itself” [12]. The cross-vendor AGENTS.md format, released by OpenAI in August 2025, was contributed to the Agentic AI Foundation, formed under the Linux Foundation on 9 December 2025, by which time more than 60,000 open-source projects had adopted it [14]. Its site lists more than twenty supporting agents and tools as of November 2026 [13]. Readiness has a de facto file format before it has an agreed maturity model.

2.4 Standards that predate agents and now serve them

Much of what an agent needs from an estate was specified earlier, for other reasons, by the supply-chain-security and observability communities. OpenSSF Scorecard automates repository checks such as CI tests, branch protection and pinned dependencies [15]. SLSA defines levels of build integrity with provenance [16], and the Reproducible Builds project defines the property that the same source, environment and instructions yield bit-for-bit identical artefacts [17]. OpenTelemetry standardises traces, metrics and logs [18]. Open Policy Agent, a CNCF graduated project since January 2021, made policy an executable artefact [19]. The two software bill-of-materials formats are both formal standards: SPDX as ISO/IEC 5962:2021 [20] and CycloneDX as ECMA-424, 2nd edition, December 2025 [21].

None of these was designed for coding agents. The readiness agenda therefore needs few new standards. It needs existing ones adopted, with a second justification.

2.5 The gap

As of November 2026 I have found no published model that connects technology-management discipline to agent capability across an estate. Readiness scoring is per repository and vendor-specific. I have found nothing that ties readiness to lifecycle states, deprecation economics or portfolio decisions, and nothing that prices the loop in which agents repair the readiness they depend on. An absence of this kind cannot be proven by search; the statement is a report of what a targeted search found.

3. Analysis

Everything in this section is argument unless a source is cited.

3.1 Technology management, repriced

For two decades technology management was governance overhead with a deferred payoff. Retiring the bespoke data-access layer, consolidating three logging libraries into one, moving the last services off an unsupported runtime: each was a cost this quarter against a benefit spread over years. It was funded reluctantly and cut first, because nothing visibly broke when it stopped.

Agents change the price through two mechanisms that are usually run together.

The first is structural. An agent can only work on what it can read, verify and safely change. A service with tests, types, a deterministic build and standing context is a workable station. A service whose behaviour is specified only by production traffic and one engineer’s memory is closed to agents whatever model is pointed at it.

The second is proximity to what the model has already seen. A model’s competence is not uniform across technologies. It is densest where public code, documentation and discussion are densest. The consequence for standardisation policy is that the paved road is paved twice: once in the firm’s platform and once in the model’s weights. When the radar puts a mainstream technology in its adopt ring, the firm also acquires what every frontier model already knows about that technology. When it tolerates a bespoke alternative, it commits to hand-writing, in standing context and tooling, what the model would otherwise have known — for every agent, on every task, for as long as the alternative lives.

I state this as a direction and not as a magnitude. Three published benchmarks bear on it, none designed to test it. Multi-SWE-bench extends issue-resolution benchmarking from Python to seven further languages; its authors report that “while existing LLMs perform well on Python issues, their ability to generalize across other languages remains limited” [22]. GitChameleon 2.0 poses 328 Python completion problems, each conditioned on a specific library version, and reports “enterprise models achieving baseline success rates in the 48-51% range” [23]. VersiCode, covering more than 300 Python libraries and 2,000 versions over nine years, finds that “model performance declines as the release time becomes more recent”, which its authors attribute to older versions predominating in training data [24]. Together these support two statements: model competence varies with how well a technology is represented in public code, and models are unreliable at writing for one stated version of a library. They do not measure a firm’s proprietary framework. The step from “weaker outside Python” to “weakest on a framework that exists in one firm” is my inference.

The version evidence also corrects a claim that is easy to make too quickly. It does not show that newer is better for agents; VersiCode points the other way at the newest end. What it shows is that version confusion is a live failure mode. The agent-specific case for version discipline is therefore about uniformity and legibility: one declared, pinned version per technology across the estate, stated in standing context, with tests that fail when an API from the wrong version is used. A firm running four major versions of the same framework has four dialects for every agent to confuse. The conventional case for staying inside support windows stands on its own grounds and is not weakened by any of this. A team that treats “the agent keeps suggesting an API we do not have” as an agent defect has usually misdiagnosed a version-sprawl problem.

3.2 What agent readiness is

Vendor checklists enumerate signals without saying what the signals are for. I propose a cleaner cut: readiness is four properties, and every checklist item serves one of them.

Verifiability is the property that carries most weight. Two vendors say so in their own guidance: Factory writes that “a codebase with poor feedback loops will defeat any agent you throw at it” [10], and Anthropic’s advice to “give it a check to run” is the second of its three headline practices [12]. The mechanism is simple. Where errors are caught at machine speed, an agent’s work can be accepted at machine speed. Where they are not, every change must be read by a person, and the human review queue returns as the constraint. Verifiability thus sets a ceiling on how much autonomy the estate can support at a given station. It does not set the autonomy.

Readiness is not safety. A payments interface with superb tests is highly ready and highly critical. I keep the two judgements on separate axes: the readiness of a station decides whether work on it can be routed to agents at all; the firm’s risk classification of that station — under DORA, whether it supports a critical or important function as defined in Article 3(22) [28] — decides how much autonomy is authorised and what human approval is required. A reader who takes “ready” to mean “safe” has misread this paper.

Readiness is layered. A codebase can be ready inside an unready platform, with excellent tests while provisioning is a ticket queue. A platform can be ready around unready codebases. The layers are codebase, platform, toolchain and organisation, the last covering whether security and legal policies exist in a form an agent can read. A control the agent cannot read is a control the agent cannot honour.

The properties are not equally cheap to buy. Describability can be back-filled quickly, since agents write serviceable standing context. Verifiability is slower and dearer, because a test that asserts correct behaviour needs someone who knows what correct is. This asymmetry governs section 3.5.

Toolchain readiness is a procurement matter. An agent operates tools. A tool that offers only a graphical interface, returns unstructured output or lacks stable exit codes is closed to agents however good its underlying capability. The question to put to a supplier is whether the product exposes a surface that is machine-operable, produces artefacts that can be compared line by line, and emits evidence of what was done. That question belongs in every request for proposal.

3.3 Bottleneck mechanics: the least-ready station on the path

A firm’s average readiness is close to meaningless. What matters is where the unready stations sit.

Change in a large estate is not confined to one repository. Take a new mandatory data attribute on an instrument: it touches reference data, position-keeping, the reporting service and several interfaces between them. If the reporting service is well prepared and the thirty-year-old position-keeping system it reads from is not, agents finish the reporting work quickly and the change then waits for a human-only modification to the legacy side. The diagram shows the shape; the durations are illustrative.

flowchart LR
    C[Cross-cutting change] --> R[Reporting service<br/>well prepared: hours]
    C --> D[Reference-data platform<br/>partly prepared: days]
    C --> P[Position-keeping system<br/>unprepared: weeks, human only]
    R --> Q{Released together}
    D --> Q
    P --> Q
    Q --> L[Lead time set by the slowest station on this path]

For a change that needs all of its stations, lead time is set by the slowest. Not every change crosses every dependency, so the estate as a whole is not governed by a single minimum. The more careful statement is that each change moves at the pace of the least-ready station on its own path, and a station’s drag on the firm is its unreadiness multiplied by the share of change that crosses it. A well-prepared leaf service contributes little because few paths cross it. An unprepared shared system contributes a great deal because most do. This is the familiar logic of constraint management from manufacturing applied to a software estate, and I offer it as reasoning, not measurement.

Three consequences follow.

1. The bottleneck moves to the shared, old and central. The least-ready stations in a large firm are disproportionately the systems everything touches: the system of record, the integration bus, the entitlements system, the reference-data platform. They were delivery bottlenecks before agents. The agent era widens the gap between them and everything else, because every other station has accelerated, and the queue in front of the unready station grows with the acceleration behind it. A firm’s “AI productivity problem” is often a legacy-adjacency problem under a new name.

2. Readiness investment should go worst-first, weighted by dependency centrality. The natural instinct is to point agents at the most modern repositories, because that is where they visibly do well. I report that as my own observation of how such programmes tend to start, not as survey evidence. The demonstrations are real and the portfolio effect is small, because the modern repositories were never the constraint. The readiness budget belongs at the most-depended-upon unready station.

This has a political cost that should be stated openly. Worst-first means funding the unglamorous core while the modern teams, who are usually the loudest advocates for agents, wait. A recommendation that ignores this will be read and not carried out. The CIO has to say in advance that the first money goes where the queue is, and show the dependency map that justifies it.

3. There is a readiness event horizon. A station can decay past the point where agents can help repair it: no tests to say what the system should do, no documentation to say what it is, no build that can be run to see whether a change even assembles. Above that line, agent-led migration is the best-evidenced kind of win, though the evidence is self-reported. The Stanford Digital Economy Lab’s study of 51 deployments (April 2026) describes an insurance firm whose legacy rewrite, quoted at 5,000 hours with seven people, was finished in 600 hours with three — roughly an eighth of the quoted effort, by my arithmetic — and a fintech with over 100 million customers whose business units completed code migrations in weeks against a traditional estimate of 18 months with over 1,000 engineers. The authors note that the study relies on self-reported interview data and is selected towards successes [25].

My reading of why migration is the favourable case is that the old system serves as the specification and the check is a comparison of old behaviour with new. That only works while the old behaviour can still be observed and reproduced. A system whose behaviour cannot be captured has no specification to extract.

The management implication is new. For each legacy station the question is not only “when do we migrate” but “are we still above the line where agents can do most of the migrating, and what minimal investment keeps us there?” Keeping a system agent-recoverable means three things: characterisation tests, which record what the system currently does; captured production traffic that can be replayed; and a build that can still be run from source. It is cheap relative to migration, it is specific, and it can be done years before the migration is funded.

Consider Bank B, a composite continental retail bank whose core banking system is a mainframe-derived COBOL platform with modernisation planned some years out. Bank B is an illustration and not a real institution. If Bank B spends the intervening years capturing end-of-day batch inputs and outputs, recording characterisation tests for its interest and fee calculations and keeping the build runnable, then when the programme starts the old system can act as the reference against which agent-written replacements are checked. If it does not, the knowledge leaves with the retiring engineers and the programme starts below the horizon. The first path is a modest annual line in the technology-management budget. The second is discovered in the programme’s second year.

DORA already points at these systems. As of November 2026, Article 8(7) requires financial entities other than microenterprises to conduct a specific ICT risk assessment on all legacy ICT systems at least yearly [28]. Agent-recoverability is not a DORA requirement. The annual legacy assessment is, in my view, the natural place to record it.

3.4 Proposals: grading, the radar, deprecation, golden paths

What exists today is per-repository scoring from vendors [10], per-repository hygiene checks from the security community [15], and component scorecards inside developer portals. On the last, Spotify reports of its own Soundcheck product that its squads saw “a ~20% decrease in master build failures” and “a ~25% decrease in high-urgency incidents when maintaining a Golden State pass rate of 85%”; that is a vendor’s analysis of its own engineering organisation, published on its product site [26]. None of these connects to lifecycle governance or to the dependency structure of an estate. The four proposals below do. They are proposals.

Readiness is recorded as facts and routes work. Most firms hold, or are building, a machine-readable inventory of what each product contains: components, versions and dependencies, of which the software bill of materials is the standardised core. Extend that record to carry the four properties per component as checkable facts with dates: tests exist and assert behaviour; standing context exists and was last verified on a stated date; the build is deterministic; rollback was last exercised on a stated date. The pipeline then reads those facts when a piece of work is dispatched: work on a station that meets the bar may be routed to agents, and work on one that does not goes to people first. The grade decides the route. It does not decide the autonomy, which is authorised separately by the risk classification as section 3.2 requires. I do not propose rolling these facts up into a single estate-wide index; section 3.5 gives the reason.

The radar gains a third axis. The rings judge capability and strategic fit. Each entry should also carry an agent-readiness rating in two parts: intrinsic — how well current models and agent tooling handle this technology — and local — how ready the firm’s own use of it is.

A technology can be in the adopt ring on capability and score poorly on agent readiness. Surfacing that tension, with named consequences for the roadmap, is what a radar is for.

Deprecation acquires an agent-economics term on both sides. The cost of keeping a deprecated technology now includes the agent capacity it forecloses across every product that touches it, which can be estimated once the outcome measures of section 3.5 exist. The cost of retiring it has fallen where the system is above the event horizon, because migration is the favourable case for agents, subject to the caveats on that evidence given above and to its date: the cases cited were published in April 2026. Both movements push the same way. My judgement, which I cannot support with data, is that a firm still using the deprecation arithmetic it used before agents will retire too little. The remedy is procedural: a standing deprecation review, on the same cadence as the radar, that restates both costs for every technology on the hold list.

A golden path is not published until its agent-readable form ships with it. A path documented only for human readers serves half of those who will now follow it. The definition of “published” should therefore include the path’s standing-context expression, versioned with the path and owned by the platform team like code. A stale agent-readable expression is worse than none, because agents follow it confidently, so it needs the same lifecycle discipline as the path.

3.5 Agents repairing readiness: the split mandate and its failure mode

Readiness debt has an unusual property: much of its repayment can be delegated to the agents that benefit from it. Agents write standing context, back-fill documentation, generate characterisation tests against observed behaviour, add structured logging, produce bills of materials and carry out version migrations. Most of this is repetitive, bounded and checkable. A station made slightly more ready lets agents do slightly more of the work of making it readier, and the effect compounds across every later task on that station, where a feature is delivered once.

That argues for spending early agent capacity on the estate. It does not argue for spending all of it there. A programme that shows the board nothing visible for a year will not keep its funding, and the board’s patience is the working capital the readiness work depends on. The rule I propose is a split mandate: the majority of first agent capacity goes to readiness work on the estate, chosen worst-first as in section 3.3, and a minority goes to a small number of visible features on stations that are already ready. The features buy the time in which readiness compounds. The readiness work is what makes the second year’s features possible outside the modern corner of the estate. I do not offer a ratio; it depends on how much patience the firm has and how far below the bar its central stations sit.

The failure mode is negative readiness. The inputs to this loop are the artefacts whose plausible-but-wrong versions do most harm. A generated document that misdescribes a system misleads every agent that later reads it, and nothing executes documentation to prove it false. A generated test that asserts today’s faulty behaviour as correct fixes the fault in place behind a passing check. Such artefacts raise the readiness score and lower the readiness.

The answer needs no new apparatus. Readiness work is change, so it goes through normal change control: reviewed pull requests, under the agent’s named human owner — the agent wrangler — with the same evidence kept as for any other change. The independent check is a second agent, given the opposite brief, that tries to break the generated tests and contradict the generated documentation; the wrangler samples its findings; internal audit samples the wranglers’ sampling. The asymmetry from section 3.2 says where human attention goes: verify the tests first, because they are the hardest to get right and everything else leans on them, and trust the documents last.

Measure outcomes, not artefacts. Readiness scores will be gamed at machine speed. Coverage targets can be met with tests that assert nothing and documentation counts with generated prose, and agents make both nearly free. This is Goodhart’s law, and manufacturing met it long ago with utilisation and piece-rate targets; I offer that as an analogy and not as cited evidence. The defence is to treat the measured outcome of agent work at each station as the ground truth: task success rate, human-intervention rate, restart rate and review effort per merged change. The firm already records every dispatch, review and merge in its change record, so these are queries against data it must keep anyway. A repository whose intervention rate falls quarter on quarter is becoming ready whatever its checklist says. One with a perfect checklist and a rising restart rate has been gamed.

Two rules bound this. First, the measures stay per station. A composite readiness index for the estate would hide exactly the variance that section 3.3 says matters, and would be one more number to game. Second, measures of agent participation — suggestion acceptance rate, the share of commits written by agents — are not readiness measures and should not be targets. They reward use, not results.

3.6 The evidence dividend, stated narrowly

Several readiness artefacts are also useful evidence for obligations a financial institution already has. I want to state this more carefully than it is usually stated, because the careless version claims that regulation requires or rewards readiness. It does not.

Under DORA, as of November 2026. The regulation has applied since 17 January 2025. It requires a “sound, comprehensive and well-documented ICT risk management framework” (Article 6(1)); it requires financial entities to “identify, classify and adequately document” ICT-supported business functions, the information and ICT assets supporting them, and their dependencies (Article 8(1)); and it requires documented ICT change-management policies, procedures and controls so that “all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner” (Article 9(4)(e)) [28]. None of these provisions mentions machine-readable policy, bills of materials, deterministic builds or agents, and Article 4 makes the whole chapter subject to proportionality. The connection is practical. A machine-readable inventory of components and dependencies is one way of evidencing Article 8(1). Automated tests, a recorded pipeline and an exercised rollback are one way of evidencing that changes were “tested” and “verified in a controlled manner”. A firm that builds these for throughput has produced material its ICT risk function can use, and the reverse also holds. Whether that material satisfies a supervisor is for the firm’s risk and legal functions to judge.

Under the EU AI Act, as of November 2026. The record-keeping and human-oversight requirements of Regulation (EU) 2024/1689 (Articles 12 and 14) are requirements on high-risk AI systems, which Article 6 defines by reference to Annexes I and III [29]. A coding agent working on a delivery estate is not among the uses listed in Annex III, and I do not read those articles as applying to the delivery estate or its tooling as such. Classification of any particular system is a legal question for the firm. The articles matter to a financial institution where it provides or deploys a system that is listed: Annex III, point 5(b), on evaluating the creditworthiness of natural persons, and point 5(c), on risk assessment and pricing for life and health insurance, are the obvious cases. For Annex III systems the application date has moved. Regulation (EU) 2026/1744, in force since 27 July 2026, amended Article 113 so that Chapter III, Sections 1 to 3, apply from 2 December 2027 to systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 to those under Article 6(1) and Annex I [30]. When those sections apply, Article 12(1) requires that such systems “technically allow for the automatic recording of events (logs) over the lifetime of the system”, and Article 26(6) requires deployers to keep the logs under their control for at least six months [29]. The link to readiness is again practical and indirect: a firm whose platform already produces structured, attributable logs by default has less to build when one of its systems falls in scope.

UK and Swiss parallels. Neither regime uses the vocabulary of this paper, and each supports the same narrow point. For UK banks and insurers, the PRA’s Supervisory Statement SS1/21 requires firms to set impact tolerances for their important business services, which presupposes knowing which systems those services depend on [31]. For Swiss banks, FINMA Circular 2023/1, in force since 1 January 2024, requires change management that defines “procedures, processes and controls for all phases in the development or procurement of ICT”, and one or more inventories of ICT assets covering hardware, software and dependencies [32].

The board argument that survives this narrowing is modest and, I think, still useful: readiness spending is not a second budget competing with resilience spending. Much of it is the same work.

On cloud vendors. Nothing in this paper depends on one cloud. Each of the three large providers offers policy-as-code, service-catalogue and pipeline services in which the four properties can be expressed. The readiness-scoring market, by contrast, is young and proprietary. The firm should own the model and treat scoring products as interchangeable implementations of it.

4. Recommendations: what a CIO does differently

1. Fund the estate, not the programme. Most of what is sold as an “AI readiness programme” is technology management that the firm stopped funding. Use the four properties as the audit of where it stopped, and put the money back into the radar, version consolidation, deprecation and the platform.
2. Draw the dependency map before choosing where agents start. Identify the stations most changes cross. Fund readiness worst-first by centrality, and tell the modern teams why they are waiting.
3. Split the first agent capacity. A majority on readiness work at the central stations; a minority on a few visible features where the estate is already ready.
4. Give every legacy system a recoverability line in the annual legacy risk assessment. Characterisation tests, replayable traffic, a runnable build. Decide explicitly which systems are being kept above the event horizon and which the firm accepts will fall below it.
5. Add the third axis to the radar and a standing deprecation review to its cadence. Restate both costs — capacity foreclosed by keeping, effort reduced in retiring — for everything on the hold list.
6. Change the definition of “published” for golden paths. No path is published until its agent-readable form ships with it, versioned and owned.
7. Score machine operability in every request for proposal. A callable interface for every function the firm will automate; outputs in a structured, comparable form; stable exit and error codes; an exportable record of what was done.
8. Measure outcomes per station and refuse the index. Task success, intervention, restart and review effort, from the change record. No composite readiness score. No participation targets.
9. Keep readiness and risk on separate axes in policy. Readiness decides whether agents may work on a station. The risk classification decides how much autonomy they have there.
10. Put readiness into due diligence, for acquisitions and for critical suppliers. An unready estate is a delivery liability: once acquired, it will run at hand speed inside a firm that runs faster. The checklist below fits on one page.

5. Limitations

• The four-property model and every instrument in sections 3.4 and 3.5 are proposals. None has been tested in a controlled comparison. The claim that they compose into an estate-level practice is argument.
• “Paved twice” is established in direction only. The benchmarks cited cover public languages and public Python libraries. No published benchmark that I found measures agent performance on proprietary frameworks or on a firm’s legacy dialects. The version evidence is mixed: it shows version confusion, and it shows models weaker on the newest releases, which is the opposite of a simple “newer is better” reading.
• The bottleneck argument is reasoning, not measurement. The statement that drag equals unreadiness multiplied by share of change is a heuristic. It ignores queueing effects, partial workarounds and changes that can be re-sequenced. I have no estate-level data set to test it against.
• Worst-first funding has not been shown to survive organisational politics. The paper names the resistance and does not solve it.
• The self-referential loop is only partly closed. If agents produce readiness artefacts and are measured by readiness outcomes, independent verification matters. The arrangement proposed — adversarial second-agent review, wrangler sampling, audit sampling of the sampling — is untested, and its sampling rates are unspecified.
• Readiness is not safety and the paper gives no method for the second. Risk classification, autonomy levels and approval design are outside its scope.
• Much of the evidence is weak in known ways. The DORA research programme’s findings are survey associations. METR’s 2025 result is flagged by METR as out of date and its 2026 data as unreliable. GitClear and Spotify are single vendors reporting on their own data. The Stanford cases are self-reported and selected towards success. The benchmark leaderboard moves monthly.
• The vendor landscape is fragile. Factory’s product may be renamed, acquired or withdrawn; the open-source repository cited is small. The argument is bound to the shape of these products, not to their survival.
• The regulatory statements are a technologist’s reading, timestamped November 2026, and are not legal advice. In particular, whether a given AI system is high-risk under the AI Act, and whether any artefact described here satisfies a supervisor under DORA, are questions for counsel and for the supervisor. The UK and Swiss parallels are indicative only, and the insurer and asset-manager equivalents in those jurisdictions are not covered.
• All quantitative claims decay. Every figure carries its date and should be re-checked before reuse.
• Verification. The source checks for this version were carried out by an AI research agent, which opened the pages listed below on 10 November 2026. That is not peer review, and the paper has not yet had a legal or practitioner review.

References

All web sources accessed 10 November 2026.

1. Thoughtworks, “Technology Radar” (Volume 35, November 2026) and “Technology Radar FAQ”. https://www.thoughtworks.com/radar and https://www.thoughtworks.com/radar/faq
2. DORA research programme, “Capabilities” (capability catalogue). https://dora.dev/capabilities/
3. DORA research programme (Google), State of AI-assisted Software Development 2025. https://dora.dev/research/2025/dora-report/ ; publication record at https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/
4. N. Harvey and D. DeBellis, “Announcing the 2025 DORA Report”, Google Cloud Blog, 23 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
5. Google Cloud Blog, “Announcing the 2024 DORA report”, 23 October 2024. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report ; report page: DORA research programme, Accelerate State of DevOps Report 2024, https://dora.dev/research/2024/dora-report/
6. METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
7. METR, “We are Changing our Developer Productivity Experiment Design”, 24 February 2026. https://metr.org/blog/2026-02-24-uplift-update/
8. GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”. https://www.gitclear.com/ai_assistant_code_quality_2025_research
9. Scale AI, “SWE-Bench Pro” public leaderboard. https://labs.scale.com/leaderboard/swe_bench_pro_public
10. Factory, “Introducing Agent Readiness”, 20 January 2026, https://factory.com/news/agent-readiness ; and “Agent Readiness Reports”, https://factory.com/agent-readiness
11. kodustech/agent-readiness, GitHub repository (MIT licence). https://github.com/kodustech/agent-readiness
12. Anthropic, Claude Code documentation, “Best practices for Claude Code”. https://code.claude.com/docs/en/best-practices
13. AGENTS.md, project site (Agentic AI Foundation, under the Linux Foundation). https://agents.md/
14. The Linux Foundation, “Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)”, press release, 9 December 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
15. Open Source Security Foundation, “OpenSSF Scorecard”. https://github.com/ossf/scorecard
16. SLSA (Supply-chain Levels for Software Artifacts), specification version 1.2. https://slsa.dev/spec/v1.2/
17. Reproducible Builds project, “Definitions”. https://reproducible-builds.org/docs/definition/
18. OpenTelemetry (CNCF), “What is OpenTelemetry?”. https://opentelemetry.io/docs/what-is-opentelemetry/
19. Cloud Native Computing Foundation, “Open Policy Agent (OPA)” project page (graduated 29 January 2021). https://www.cncf.io/projects/open-policy-agent-opa/
20. SPDX, “Specifications” — ISO/IEC 5962:2021. https://spdx.dev/use/specifications/
21. Ecma International, ECMA-424, CycloneDX Bill of materials specification, 2nd edition, December 2025. https://ecma-international.org/publications-and-standards/standards/ecma-424/
22. D. Zan, Z. Huang, W. Liu et al., “Multi-SWE-bench: A Multilingual Benchmark for Issue Resolving”, arXiv:2504.02605 (April 2025), https://arxiv.org/abs/2504.02605 ; NeurIPS 2025 Datasets and Benchmarks Track, https://neurips.cc/virtual/2025/poster/121692 (the quoted sentence is from the NeurIPS abstract).
23. D. Misra, N. Islah, V. May et al., “GitChameleon 2.0: Evaluating AI Code Generation Against Python Library Version Incompatibilities”, arXiv:2507.12367 (July 2025). https://arxiv.org/abs/2507.12367
24. T. Wu, W. Wu, X. Wang et al., “VersiCode: Towards Version-controllable Code Generation”, arXiv:2406.07411, version 2 (October 2024), section 3.2. https://arxiv.org/abs/2406.07411
25. E. Pereira, A. W. Graylin and E. Brynjolfsson, The Enterprise AI Playbook: Lessons from 51 Successful Deployments, Stanford Digital Economy Lab, April 2026, PDF pp. 21 and 63, and the Limitations section. https://digitaleconomy.stanford.edu/app/uploads/2026/03/EnterpriseAIPlaybook_PereiraGraylinBrynjolfsson.pdf
26. S. Chandrasekaran, “How Soundcheck improves tech health and developer productivity at Spotify”, Spotify for Backstage blog, 19 September 2023 (updated 30 June 2026). https://backstage.spotify.com/discover/blog/how-soundcheck-improves-tech-health-pt-1
27. Cloud Native Computing Foundation, “Backstage” project page (incubating). https://www.cncf.io/projects/backstage/
28. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), OJ L 333, 27.12.2022, p. 1 — Articles 3(22), 4, 6(1), 8(1), 8(7), 9(4)(e) and 64. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554
29. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), OJ L, 2024/1689, 12.7.2024 — Articles 6, 12, 14, 26(6) and 113, and Annex III, point 5; consolidated version of 27 July 2026. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R1689-20260727
30. Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI), OJ L, 2026/1744, 24.7.2026 — amendment to Article 113 of Regulation (EU) 2024/1689. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744
31. Prudential Regulation Authority, Supervisory Statement SS1/21, “Operational resilience: Impact tolerances for important business services”, first published 29 March 2021, current version 11 March 2022. https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/operational-resilience-impact-tolerances-for-important-business-services-ss
32. FINMA, Circular 2023/1, “Operational risks and resilience – banks”, 7 December 2022, in force 1 January 2024 — section on ICT risk management, “Change management” and “ICT operations”. https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/rundschreiben/finma-rs-2023-01-20221207.pdf