Agents that figure it out once, then never again

The expensive part of autonomous work isn't doing the task. It's figuring out how. Make your agents bank that figuring-out as reusable code, and one-time reasoning becomes permanent capability.

I run a data-intelligence business: a niche vertical-data product built almost entirely on a fleet of AI agents. They pull from messy public sources, reconcile the results into a graph of entities, and surface the good ones to a small set of customers. I've written elsewhere in this series about the shared brain they think out of and the task queue that feeds them. This piece is about a habit those agents have that quietly makes the whole thing cheaper every week: they write their own tools, and they remember them.

Most people running agents are paying full price for the same reasoning over and over. The agent lands on a gnarly portal, spends twenty minutes and a small fortune in tokens working out how to get data out of it, succeeds, and then (having taught itself something genuinely hard) throws the lesson away. Next week a different agent hits the same portal cold and pays the same twenty minutes again. That's the default behavior, and it's a slow leak you don't notice until you look at the bill.

The fix is a doctrine, not a feature. Here's how I run it.

Every mode is expected to write real code

The single most important decision was telling the agents, in their operating instructions, that building software is part of the job and not an exception they need to ask about.

The mandate in my system reads roughly: every mode is explicitly authorized and expected to build real tools that make the work deeper or faster. You do not need permission to build a tool. You need a reason. And the reason bar is low. If you find yourself doing the same thing by hand three times, stop and write the tool.

This matters because the agents have a real runtime. They're not stuck in a chat box with a single fetch primitive, hoping a page renders. They have a language interpreter, a package manager, a headless browser, a shell, and a filesystem. The instruction makes that explicit so the agent reaches for it. When a plain fetch returns an empty shell because the page is rendered by JavaScript, the agent doesn't shrug and mark the source "inaccessible." It writes a headless-browser script that waits for the content to render and pulls it out of the DOM.

The doctrine also separates what from how. A central quality standard defines what data must exist and to what bar. Each mode owns its own methods: its tools, its workflow, its optimizations. A new requirement from me can say "every site needs an aerial image"; it must not say "open this map tool, zoom to level 18, take a screenshot." The first is a goal. The second is an implementation detail the mode should be free to improve. Tools rot fastest when someone with authority hardcodes a how that the mode has already outgrown.

Bank the tool the first time, reuse it forever

Writing the tool is half the move. The other half (the half almost everyone skips) is logging it to shared memory so the next session finds it instead of rebuilding it.

In my system, when an agent builds something reusable, it writes the complete working code into the brain under a predictable key: TOOL_<MODE>_<NAME>. Not a description of the tool. The actual runnable code, plus everything needed to run it.

And every session, before it starts work, an agent runs one query:

SELECT file_key, title, summary
FROM brain
WHERE file_key LIKE 'TOOL_%'
ORDER BY updated_at DESC;

The rule attached to that query is blunt: if a tool exists for your task, use it. Do not rebuild. If it needs improving, improve it and log the change.

That one query is the whole compounding engine. It turns the toolbox from a pile of dead scripts on someone's laptop into a library the fleet actively shops before doing anything expensive. The agent reads the summaries, recognizes that there's already a scraper for this portal vendor, pulls the code, and runs it. The hard reasoning that produced that scraper, done once, months ago, by some other session, is now free.

What a banked toolbox actually looks like

To make this concrete without giving away anything specific: the libraries in my system don't contain one clever god-tool. They contain a dozen-plus small, specialized, individually documented tools, each aimed at one stubborn class of source.

The shape is striking once you see it. There isn't a single "scrape any portal" function. There's one tool per portal vendor, because each vendor's platform is its own little puzzle, and the agent that first cracked it banked the solution separately. One entry handles a vendor whose data only comes back through a JSON API, no browser needed. Another handles a vendor whose content is hidden in CSS-collapsed DOM nodes, so you can't read the visible text; you have to query the DOM directly. Another handles an old form-postback platform where pagination works through a non-obvious event mechanism. Another captures map imagery and hands it to a vision model for classification.

Read like that, the library is a map of every hard-won lesson the fleet has ever learned about the outside world. Each row is a battle the agents only have to fight once.

The discipline that keeps it from rotting

A tool library is an asset that decays if you let it. The thing that keeps mine honest is a fixed template for every entry. (That template, ready to copy, is on the downloads page.) A banked tool isn't done when the code works. It's done when the entry records:

• Exact invocation. The literal command, with argument order. run_<vendor>.py <base_url> <entity_id> <name> <body_id>. Not "call it with the relevant parameters." A future agent should be able to copy-paste and go.
• Inputs and outputs. What it consumes, and precisely what it writes back: which tables, which files. A tool that silently does I/O is a tool nobody trusts enough to reuse.
• Dependencies. What has to be installed first.
• The gotcha. This is the gold. The one-line "KEY INSIGHT" that captures the non-obvious thing that made it work. The agenda lives in hidden DOM nodes, query it directly. This vendor abbreviates month names so the naive date parser misses half the rows. Download the PDF over plain HTTP because the browser's download interception fails here. That sentence is the distilled output of the original expensive reasoning. It's the part you're really banking.
• A changelog. When a tool is improved, the change gets dated at the bottom. Tools are living code, not fossils.

That gotcha line is why this works at all. Anyone can save a script. What you're actually preserving is the insight that the script encodes, stated plainly enough that the next agent understands not just how to run it but why it's shaped the way it is, and how to fix it when the source shifts.

Where the line is: banked tool vs. one-off

Not everything should be banked. Over-banking is its own kind of rot: a library full of hyper-specific scripts nobody will ever call again is just clutter you have to read past every session.

My rough boundary:

• Bank it if it's reusable across entities, sources, or runs; if it encodes a non-obvious technique; or if re-deriving it would be expensive. Anything that turns a recurring multi-hour slog into a quick run is a permanent capability: bank it.
• Don't bank it if it's genuinely a one-off: a throwaway transform for a single record, a quick check you'll never repeat, glue specific to one task that will never recur. Write it, use it, let it go.

The test I encourage is simple: would a future session, on a different entity, want this? If yes, it's a tool. If no, it's a scratch script. When in doubt, lean toward banking, but write a one-line summary good enough that the next agent can decide in five seconds whether to open it.

The compounding payoff

The economics flip once this is running. The first time the fleet touches a new region or a new class of source, it's slow. The agents are building the tools. Every pass after that is dramatically faster, because the tools already exist and the next agent just shops the library and runs them.

That's the whole thesis. A fleet that writes its own tools and remembers them converts one-time reasoning cost into permanent capability. The toolbox only grows. The reasoning you paid for once keeps paying out across every future session, every new entity, every agent that thinks to run the lookup query first. The system gets cheaper and faster the longer it runs, which is exactly backwards from how most software ages, and exactly what you want.

Takeaways

• Make tool-building part of the job, not an exception. Tell your agents in plain instructions that they're expected to write real code when it makes the work faster or deeper. Lower the bar to "I did this by hand three times."
• Bank the tool to shared memory the moment it works: the complete runnable code, under a predictable, greppable key. A tool nobody can find is a tool that gets rebuilt.
• Make every session shop the library before doing expensive work. One lookup query at startup, plus a hard rule: if it exists, reuse it; don't rebuild.
• Record the gotcha, not just the code. The one-line insight that made it work is the real asset. It's the expensive reasoning, distilled.
• Hold a line between banked tools and one-offs. Reusable or insight-bearing gets banked; throwaway glue gets used and dropped. A clean library is one the fleet actually trusts.