The Self-Equipping Agent

An AI wrote a driver for a database whose vendor was sold off and whose client no longer exists — then re-engineered that driver past its own 4 GB wall in six minutes. That is not “AI codes faster.” It is a change in the unit of engineering, and it reprices your entire backlog.

By Scott Farrell · LeverageAI

I was restoring old files for a personal memorabilia project — thirty years of digital sediment — when the agent hit a wall. It had found some Lotus Notes data. Old Notes data, from a technology whose vendor sold it off years ago and whose client software I no longer had installed anywhere.

I told it to open the file. And of course, we don’t have Lotus Notes.

No Notes client? Fine. The AI wrote enough Notes software to get my data back.

Claude Code⁸ shrugged — “no worries, I’ll just invent a driver in C++” — and it did. It opened the Notes NSF file. It took under three minutes.

The easy reaction is: yeah, yeah, AI wrote a parser. If that’s all you see, you’ll miss the thing that actually happened. This piece is about the thing you’d miss.

The tomb door moved

Recovering data from an extinct format used to be a ritual, and the ritual was expensive. It went roughly like this:

Every extinct format was a sealed tomb, and the cost of opening it was absurd. So most of them stayed sealed. Today, the agent manufactures the archaeological tool at the tomb door. The ritual collapses to: what is this? I need a reader. Writes one. Opens it.

It matters that this isn’t a trivial file. An NSF is a real database. HCL still documents a whole native C API for it — NSFDbOpen, NSFSearch, NSFNoteOpen, NSFItemInfo — a storage model with typed items, access controls, object stores and a long lineage of on-disk formats.⁵ An independent reverse-engineering project, libnsfdb, has spent years on the format and still describes itself as experimental, analysis-only.⁶ So writing an NSF reader is re-implementing a proprietary database engine, not unzipping an archive.

To be honest about what happened: the agent didn’t derive the entire NSF format from first principles in a few minutes. It found enough existing format knowledge and structural clues to synthesise the particular reader it needed. And that’s almost more interesting — because format extinction is ceasing to imply information extinction. But how far that reach extends across every dead format on earth is a separate argument, and one I’ve made elsewhere in The Backup Is the API. This piece is about something narrower and, I think, sharper: the engineering economics of what just happened.

Capability acquisition became a step

Here is the beat that turns a cool anecdote into an argument. As the agent worked through the archive, it found another NSF, and reused its reader automatically. Then it found one bigger than four gigabytes.

“Oops — our driver doesn’t handle blobs past 4 GB. Don’t worry, I’ll re-engineer it.” Five or six minutes later, it did, and it kept going.

Read that again. The boundary it hit was in its own freshly built software. Its abstraction was too narrow, so it changed the abstraction and continued the archaeology. That is not “AI helped me write a converter.” That is an adaptive toolchain being synthesised in the path of the work:

The extraordinary part is that capability acquisition became a step inside the workflow. Traditional software design says: we have capabilities A, B and C — now design a workflow from them. The agent says: I need D, I don’t have D, I’ll make D, back to work.

I didn’t procure an NSF Reader Pro™. I had a mission — recover my old world — and the software’s shape was determined by whatever obstruction the mission met. Call it mission-shaped software. The striking thing is that the lifetime of that software may be twenty minutes. It doesn’t need a product name, a UI, installation docs, a roadmap, generic configuration, support for every NSF ever made, a vendor, or a purchase decision. It needs to open my files today.

Notice what this does to the tidy diagram we usually draw. We picture an architect anticipating the topology in advance: LLM step, then a query, then another LLM step. But here nobody designed “mount the VMDK, reverse the struct, boot QEMU.” The workflow was not designed first and executed second. The workflow precipitated out of contact with reality. The pipeline is the trace left behind by thinking. And this isn’t a one-off trick: Anthropic now documents agents persisting their own code as reusable functions, building “a toolbox of higher-level capabilities” over time.¹¹ The distinction between tools the agent has and tools the agent can create has almost disappeared.

The unit of engineering

Now put the agent’s five-minute fix next to the company that owned this format. The comparison is the point of the whole piece.

IBM’s own documentation records the ladder: Release 4 topped out at 4 GB, Release 5 raised it to 64 GB,² and that 64 GB ceiling stood for the better part of two decades before Domino 10 lifted it to 256 GB — HCL’s docs say it plainly: “previously it was 64 GB.”¹ Each move was a product generation: storage architects, compatibility analysis, on-disk-structure evolution, a test matrix, release engineering, customer migration. The 256 GB change still shipped with rules about which ODS version you needed and how replication behaved beyond 64 GB.¹ That is product-scoped engineering, and it took years — cumulatively, plausibly person-decades of ecosystem effort.

IBM moved a boundary as part of a product generation. The agent moved a boundary as part of reading the next file. That’s not “coding faster.” The unit of engineering has changed.

I want to be scrupulously fair here, because the distinction is load-bearing. These are not equivalent engineering burdens. IBM had to support millions of users, preserve vendor compatibility, guarantee decades of upgrades, and ship a durable, supported database platform that could safely read, write, replicate, recover, compact and index across an entire enterprise ecosystem. The agent had to do exactly one thing: read my NSF corpus and get the records into Postgres. It didn’t solve IBM’s problem, and I can’t hand you a precise “IBM spent 17.3 engineer-years on the 4 GB barrier” figure — no internal project accounting exists for that.³

But that’s exactly why the observation matters. Historically we engineered the general solution because software was expensive: spend the human-years, make the reader handle the whole supported world, do it once. The agent doesn’t reach for generality. It says: I have encountered file 8437; my present software can’t cross this boundary; I will change the software to cross the boundary I’ve actually met. You didn’t need the product boundary moved. You needed the boundary moved for this mission, against this corpus, right now.

One night, one mission: the recovery, end to end

The 4 GB fix is one beat in a longer expedition, and the full trace is worth seeing, because no sane human would ever design a pipeline with these boxes at the start. They emerged because reality fought back and the agent kept forging the next capability it needed to move forward.

1. 1Restoring old files, it hits a Lotus Notes NSF. No client anywhere.
2. 2It goes spelunking through old VMDK disk images (mounting them, pulling out the files it wants) and finds a Notes DLL and some Notes ID files.
3. 3I don’t know the passwords. It drives the DLL under Wine⁶ — no full Notes install, just the runtime component — builds its own recovery harness around it, and, because it’s not running the whole application, sidesteps Notes’ login timeouts. It generates and downloads word-lists, mangles them with Python, and runs billions of attempts.
4. 4Brute force fails on one ID. So I broaden the goal: try the other Notes IDs (same filename, years apart, likely different passwords), and search the Postgres data we’d already recovered — unencrypted — for plaintext passwords. It works. It recovers the IDs and passwords across the archive.
5. 5It writes a C++ NSF driver from close to scratch: iterating struct offsets, discovering a 16-byte offset for the Notes ID, working out the field layout — building it, as I watched, largely “out of its head” with a little web reference.
6. 6It replicates NSF → Postgres in under three minutes, preserving the Notes universal ID across replicas.
7. 7It hits the >4 GB NSF, re-engineers the driver in five or six minutes, and continues.
8. 8I want to log into the original system. The old Intel VMware image won’t run cleanly on my Apple-silicon Mac, so — unprompted — the agent spins the VM up in QEMU on a Linux box instead, translates the old VMware config into QEMU drivers, screenshots the boot sequence to work out how to bypass the “inaccessible boot device” screen, moves the VM onto a scratch SSD for speed, and hands me a VNC command to log in.

This was a long-running agent job — two overnights, driven by a single goal. And that duration is not incidental. It changes what the agent is.

The six-hour organism

A six-hour agent at hour six is not the execution capability it was at minute one. At the start it had a shell, generic tools, and a filesystem. By the end it had an NSF scanner, a password-test harness, an extracted identity catalogue, VM-mount scripts, a word-list transformer, a custom C++ reader with known field offsets, a validated test corpus, recovered passwords, a QEMU config, a migrated VM, and working VNC access.

The mission accumulates machinery.

A long-running goal agent is building itself a mission-local capability stack. It gets more capable with respect to that goal as it works. This isn’t a metaphor stretched for effect — it’s the measured trajectory of the field. Anthropic reports agents maintaining focus for more than thirty hours on complex, multi-step tasks;⁹ METR finds the length of tasks a frontier agent can complete autonomously has been doubling roughly every seven months, and accelerating since.¹⁰ The longer the coherent run, the more machinery the mission can accumulate before it loses the thread. (The architecture that makes those long runs stable — stateless workers plus a stateful kernel — is the subject of our work on breaking the one-hour barrier.)

Which has a sharp operational consequence. If you interrupt a long-running agent to bolt on the next task, you’re not just distracting it — you may be yanking an intelligence out of a locally accumulated cognitive environment that took six hours to form. It’s the oldest management lesson there is:

That’s why expressing intent, rather than dictating steps, is what let this happen at all. I never specified “mount the VMDK, reverse the struct, boot QEMU.” I gave it a few hints and told it what I was trying to do, and it self-organised the whole expedition. You give it your intent — not a list of steps — and if it understands the intent, it can go and do the work. A good model with a persistent goal, broad machine access, accumulated scripts, and the ability to create new instruments stops being a very smart prisoner in a chat box and becomes a self-equipping expedition.

Reality reprices the future

Here is the part that outlasts the anecdote. The recovery didn’t just produce recovered data. It changed my internal price table of what’s worth attempting.

Reality doesn’t merely answer the question. It reprices the future.

My capability frontier moved, so the next day I generated intents that the day before I’d have silently discarded as unrealistic — before they ever reached a conscious backlog. Previously the brain does idea → “too hard” → discard. Now it does idea → “hang on, it recovered Lotus Notes from VMDKs” → maybe possible → capture. The range of thoughts permitted to become intents expands. Contact with reality brings perturbation — even when I think I know what AI can do, today shatters another barrier, and what was true yesterday isn’t true tomorrow. The perturbation isn’t noise in the loop. It’s fuel.

And the macro-economics point the same way. The reason legacy is expensive is precisely that reaching it requires scarce, disappearing specialist capability: the US federal government alone spends over $100 billion a year on IT, roughly 80% of it operating and maintaining legacy systems, some still running on COBOL and Assembly with a dwindling pool of people who can support them.¹² When an agent can manufacture the reaching capability on demand, the price of “touch the obsolete system at all” collapses — and a specialist project becomes an overnight goal. (What you then keep or delete from that newly reachable archive is its own question, one I’ve taken up in Keep the Bronze.)

The 25-year proof

I have a controlled experiment for this, and it’s my own history. In the early 2000s I built a Lotus Notes application for Freemans Australia — insurance loss adjusters, fifty offices, working out of disaster zones on notebooks with intermittent connectivity, replicating back when they got a line. Then their clients, the insurers, wanted visibility. Notes was the wrong thing to hand them, so I invented a signed, claim-scoped URL — a capability link emailed per claim, opening exactly one claim read-only — years before S3 made signed URLs ordinary.

To serve that on the web, I back-ended it into Notes, found Notes couldn’t take the load no matter what I did, and so I hand-wrote a replicator to push the Notes data into DB2. That got too slow, so I multithreaded it and added checkpointing until I had a behemoth of a replicator feeding a fast WebSphere/DB2 serving layer. It worked for years. It also took months of my life.

Twenty-five years later, I’m recovering Lotus Notes data and chucking it into Postgres because I can’t be bothered reading it from Notes. Same bloke, same source technology, nearly the same data-movement instinct — get the data out of the awkward operational format and stage it somewhere tractable. In the 2000s I moved it because the serving environment needed DB2-shaped data. In 2026 I move it because the cognitive environment — the AI — thinks far more freely over Postgres and text.

The difference is that the second time, the software arrived as a side effect of expressing the intent.

That’s “code is not the asset” with a 25-year receipt. The first time, the transformation substrate didn’t exist, so I was the substrate. The second time, I kept the architectural decision and barely touched the machinery.

And it’s not a fluke of one lucky corpus. In a separate session, against a different backup set, the agent hit the same wall — no Python NSF connector — and again synthesised its own C++ driver, running ten parallel threads, deduplicating across partial replicas by their universal IDs. Two independent cases pointing at the same move is enough to call it a principle, not an anecdote.

What to do with this

If you run agentic tools, the shift you should internalise isn’t “the AI is faster.” It’s that capability acquisition is now a step in the workflow, which shrinks the unit of engineering to the next file — and that means a whole class of work you’ve priced at yesterday’s rates is now radically cheaper. Your “impossible” backlog was written under the old economics. It’s stale.

So re-price it. Find the extinct system, the encrypted archive, the format nobody can open, the twenty-year-old data hoard you kept for no reason and could never justify touching. Give an agent a general-purpose machine, a single clear intent, and a night. Then leave it alone and see what it builds itself to get in.