On a recent project we moved an Azure estate from one tenant to another, with a team of agents doing most of the work. The estimate was six weeks. We finished in two. Today the same migration runs as a script that uses almost no tokens at all.
If you are being asked to fund agentic work, you will want to know what it costs to run once people start using it. My answer comes from that project. The cost falls when the agents turn what they learn into tools, and those same tools are what make them useful for the next job.
Agents improve
when their lessons are saved.
The job was a chain of agent steps. Export everything in the source Azure environment, survey what came out, write the Bicep templates Azure uses to build resources, and fill those templates with the right values so the new tenant matches the old one.
The first version had two reviewers on every build: an honesty review, where an agent checks that the work claimed was actually done, and an adversarial review, where another agent tries to break it. The output was still incomplete, checking it meant rerunning the whole migration for one or two issues, and an error sent the run back to the start. A full day went by with no noticeable progress. Adding more review, up to six agents checking one resource export, did not change that, because the agents had nowhere to store what they learned and made the same mistakes on every run.
So we gave each area of the work its own specialist agent, and after every run those agents improved their own instructions until a mistake stopped repeating and the step worked the first time. Once that held, the reviews could flex: the agents decided for themselves whether one pass was enough. We added automatic checks that every export had the right structure. Then we asked the agents to improve the export code and the templates themselves, so the whole migration would run as a fixed, repeatable pipeline.
From then on, whenever an agent learned something, we asked for three things: improve the code, update its own instructions, and write the fact into the second brain, the shared store of facts the team and its agents read from.
Each run after that cost less than the one before. Some resource types had been missing about a fifth of their exported details and recovering only a little more each run. Once the agents had learned the job, they captured close to all of it on the first attempt. Now they capture all of it through scripts, and the agent just runs the tool.
In all it took 20 full runs before every resource had copied over to the new tenant correctly.
The work ends
as a script.
For cost, the part that matters most is what the migration looks like now. It runs on almost no tokens, because the script does the work.
Nearly all the agents' effort on that project went into two things: building the setup that lets them learn from each run, and learning how to export and import this kind of estate. That knowledge is now written into a workflow that can be pointed at the next estate. Roughly 10% went into the production run itself, including testing and a few standard starting environments the new tenant needed.
Here is what the heavy stretch looked like. For about seven days of the two weeks, the agents ran fairly non-stop on Claude's highest flat-rate plan. By my estimate, measured in aggregate, the tokens would have cost about $800 on an average day, and up to $1,400 on the days the plan's allowance reset. On a couple of days the allowance was used up and the cost was zero. With those days included, a week came to about $4,000 to $5,000 at metered prices, all of it covered by the subscription.
Every improvement to the agents' instructions brought the token cost down, until the script took it to almost zero.
Against a traditional project done entirely by people, finishing in two weeks instead of six paid for the work straight away. We put the four weeks we saved into turning that code into a reusable tool, and we are now extending it to Microsoft 365 workloads. I now run every project this way, and I expect the next one to go faster again, with fewer people involved.
Tools give the model
its reach.
Some use cases can become 100% deterministic code, and a migration is one of them. The model still does the work around that code, and that is where its flexibility shows.
We use agents as a flexible layer between people and their tools, and every tool we give them expands what they can do. When a specialist agent's instructions change, the model picks up the change straight away, so keeping it current takes little effort. The skills built for the migration, the written instructions each specialist agent follows, now get reused to stand up new infrastructure, to package and deploy standard starting environments, and to put a demo together quickly. None of those needs a new screen. Anything temporary or one-off still needs the model, working with the tools it has been given.
That is why I think of this as a new kind of application. The client ends up owning reusable code, the same as with traditional software. There may be bespoke views on top of it: progress dashboards, inventory reports, output reports, and workflows that produce documentation or agent instructions tuned to their organization.
In a traditional application those internals are wired to buttons, and each button gives one expected result. Here the internals are tools, and nobody has to build a form to drive them. You ask in chat and the model picks the right tool. It can also combine tools in ways nobody designed a button for, which gives it far more flexibility than a traditional interface.
What does need to stay fixed is the output. Reports and documents have to be standard, repeatable and stable so people can learn to read them, and agents can too. That stability is what lets each run feed the next: agents improve their instructions, the second brain gains facts, and the code gets better.
An operator
steers the loop.
There were close to 100 working sessions on that project, and people kept the agents on course throughout. The judgment calls were human, and so was the final check in the new tenant that resources were mounted and the data had actually copied.
The call I made most often was an ad hoc request to update the wiki or a skill. Early on, before the rules and guardrails are in place, you have to be specific about when a lesson gets written down. A skilled operator can see an agent stalling, taking too long over something basic, or getting the same thing wrong several times in a row. The fix is to have it step back, save what it learned, apply it and try again. Most of the time that works, and each time the knowledge base, the agent instructions and the tools all grow.
The other call was to simplify and stay focused. Early in a project agents tend to produce far more than anyone asked for, and sometimes fixate on filling gaps you never wanted filled. So each project gets a short file stating its purpose, and an agent whose work does not serve that purpose drops it and refocuses. The guardrails build up in order, and after a while they keep the agents on track without prompting.
Scope needed the same discipline. In the first week we had pulled in three Azure subscriptions where one was enough, so we cut back to fit the estimate, and on the first Friday we rebuilt the second brain from scratch, keeping only what was still useful from the first one.
Which of your workflows are building tools you will own, and which are paying for the same mistakes every week?
Save the lesson
before the session ends.
This is the command I give agents so that a lesson becomes a script, a skill or a fact before the session that learned it is gone. Save it as .claude/commands/learn.md, and run /learn whenever a run hits a problem it has hit before or you catch yourself asking for the same thing twice.
---
description: Turn what an agent just learned into something the next run uses. Run it when a run hits a problem it has hit before, or when you ask for the same procedure a second time.
---
# /learn
A lesson that lives only in this session is lost when the session ends, and the next run pays for it again. Save it now, while you still have the context, never at the end of the session.
`$ARGUMENTS`: what went wrong or what was repeated, in one line.
## 1. Fix the work first
Fix the defect in this session, in the file that owns it. A note about the problem is not a fix. If you cannot fix it, because it needs a person's decision or is outside this job, say so in your reply: name the file and what you would have changed.
## 2. Make the next run cheaper
Ask one question: could a script do this step the same way every time?
- **Yes:** write or improve the script, then change the instructions so the agent runs it instead of doing the step itself.
- **No, it needs judgement:** update the skill or command that should have prevented the mistake. Correct the line that was wrong where it sits; do not add a new rule beside it.
If this is the second time anyone has asked for the same procedure, it becomes a command now. Check that no existing command already covers it first, and improve that one if it does.
## 3. Write the fact down
Add what is now known to be true to the wiki, on the page that owns the subject, replacing anything it contradicts. Facts only: no story of how you found it, no notes to the next agent.
## Report
- Fixed: the file and what changed.
- Made cheaper: the script, skill or command changed, or "none, and why".
- Fact recorded: the wiki page and the sentence added or corrected.
- Not done: anything that needs a person, and who.