Stop making your agents rebuild the world

The agent got the answer right. It inspected our project, wrote a small script, fixed an edge case and returned what we needed.

Then the session ended.

Another agent arrived with a similar problem and began writing almost the same script. We recognised the steps. Find the files, parse their contents, check the result: each session could finish the job, yet the next one still had to work out how to do it.

What, exactly, had the first session left behind?

We thought we needed better instructions

Our first response was to improve the prompts. We collected recurring workflows into skills: reusable instructions that told an agent where to look, which checks to run and how to report the result.

They helped. The next agent had a clearer route through the work, and we had somewhere to put the lessons from earlier sessions. When it repeated a familiar mistake, we could add another explanation.

But the instructions kept growing. The agent still had to read the procedure, interpret it and turn it into something it could execute.

If you have ever added another paragraph to a skill to prevent the same mistake, you know how reasonable that feels. We were making the recipe more precise each time someone had to follow it.

Consider a tray of star-shaped cookies. You could trace each outline with a knife, carefully repeating the same cuts until every star looked right. Better instructions might improve the result.

They would still leave you holding the knife.

Once the shape had settled, we needed a cookie cutter. Our agents were leaving answers behind; what we kept asking them to recreate was the procedure that produced those answers.

We kept what had worked

We started retaining the useful scripts. We gave them defined inputs, tested their behaviour and made them available to the next session.

Now something survived beyond the instructions. A later agent could use an implementation we had already inspected, rather than writing another version of it.

That helped, but another problem appeared. The agent still needed to find the right script, supply its arguments and recognise its failures. Too much of that coordination remained scattered through the skills.

We had kept the cutter. Finding and using it still took explanation.

We gave the scripts one way in

So we wrapped those operations in a consistent command-line interface, or CLI, called task. The agent could request a named operation and inspect its result without reconstructing the commands underneath.

The skill could become smaller. It still needed to explain when to use the operation, what its result meant and which decisions remained open. We could change and test the implementation in one place, then let each new session call that same code without reconstructing it.

The important part wasn’t the command line itself; it was the boundary.

Guidance above, repeatable execution below.

Agent

Interpretation and judgement

Skill

Intent, timing and guidance

task CLI

Defined inputs and observable outcomes

Files

Project state

Checks

Scripts run the mechanics; results return for interpretation.

Our memory workflow made that distinction concrete. We turn records from earlier sessions into shorter memories so the next agent does not have to read the entire history.

Which decisions still matter? The agent has to weigh newer information against older guidance and decide what would be dangerous to lose. That takes interpretation.

Checking that each memory had the required source reference was different. We put that scan behind the CLI, giving the next agent a way to inspect the findings without writing another parser.

task memory lint --provenance

The command can check that a source reference is present. It cannot decide whether that source actually supports the claim.

We started looking for what survived

We still need prompts and skills. And when a procedure is unsettled, letting an agent explore can help us discover what belongs in a tool.

But repetition now gives us something to investigate. If you see an agent reconstructing a familiar command or parsing the same format again, look at what the previous session left behind. Perhaps the instructions are already clear enough; the missing piece is a reusable capability.

Before we add another paragraph to a skill, we check whether there is a procedure we can keep, test and turn into a reusable capability.

The agent should not have to rediscover what the system already knows.