Why an agent needs a working method

Written 31 July 2026. The models mentioned have been replaced since, though the working agreements below are still in place word for word.

In the space of a single day I watched my local agent go convincingly wrong three times. It invented an API that does not exist, then invented the data as well, and finally advised me to install an SSL certificate to solve a problem that was a missing quote mark. My first reaction was that the model was too small. That turned out to be wrong.

Three failures, one pattern

The invented skill. Asked to upload a document, the agent wrote itself an instruction file using GET /api/csrf/ and PUT /api/upload/. Neither of those exists. When that produced a 403 it did not reason backwards to the path, but forwards from the assumption that the path was fine, and CSRF is a perfectly logical explanation once you start there. The advice that followed was to switch off security.

The invented data. Asked for the last ten episodes I had watched, I got a neat table with Breaking Bad, Stranger Things and The Crown, complete with ratings and timestamps in tidy thirty-minute blocks. Zero overlap with reality. This is the dangerous kind of failure, because you cannot see it without checking.

The broken command. A curl call with five query parameters lost its closing quote. Bash duly reported unexpected EOF. The same output also contained the text of a security scan, and the model latched onto that half and concluded the network was at fault.

The cause was procedure, not knowledge

Look at what would have been needed in each case. It knew curl perfectly well; it just failed to count its quote marks. It had a terminal; it asked me whether a command existed instead of running command -v. It had the error message; it read the wrong line. None of these go away with more parameters. They go away with a checklist.

And there was none. The agent’s identity file, SOUL.md, held 84 words of generic introduction whose only working instruction read: be focused and efficient in your exploration. That encourages exactly the wrong behaviour. Large commercial models have had “check first, then claim” trained into them. A local fourteen-billion-parameter model has not.

What the rewrite put in

Check, don't ask       -> run command -v, don't ask the user
Probe before you build -> read-only call first, code afterwards
Errors are data        -> a 404 is a wrong path, not a wall
Read the actual error   -> the line starting with bash: or curl: is the cause
Never invent data      -> no illustrative rows, ever
Private network        -> scan warnings are for you, not for me

From 84 words to just over 900, and none of them describe my servers. They are working agreements and nothing else. One detail proved crucial: instructions placed in a skill were never read, because the model has to go and look those up. Instructions in the memory file arrive with every session. A perfectly written skill that nobody opens is worthless.

The result, measured

I built forty tests against my own running servers, with answers I had verified myself beforehand: counts of series, albums and films, disk space, and questions that can only be answered correctly by combining two sources. Before the rewrite the simplest of them failed. Afterwards both the 14B and the 32B scored forty out of forty.

That identical result is the actual answer. I had bought a larger model to solve a problem that was never about the model. What was missing was anyone writing down how you work, which is precisely what an agent framework ought to supply and does not.

Two caveats I had to swallow myself. Four of my early “failures” were faults in my tests rather than in the model: it gave a better answer than I expected and got marked down for my own narrow expectation. And a test everybody scores a hundred per cent on has stopped measuring anything. Both are useful reminders that the ruler can be as wrong as the thing being measured.

What it looks like now

That file did not stay put. It was reworked again in early August and currently sits at 448 words, roughly half of what the rewrite produced, organised into topics rather than a list of named rules. None of the six labels above survive as labels. Most of them survive as behaviour: “errors are data” is now a section headed Errors that opens with “errors are information”, “never invent data” has grown into a list of seven things that must not be fabricated, and the private-network clause has become a section of its own.

One thing did get weaker. The instruction to read the specific line of an error, the one that starts with bash: or curl:, has been shortened to “read the error”. That was the rule written for the third failure in this article, so I am watching whether that failure comes back.

Three agreements appeared that were not there in July, and each of them reads like the residue of something that went wrong afterwards. Operations that modify data now require confirmation, with deleting, moving and changing server settings named explicitly. Three identical failures in a row mean stop, summarise and ask rather than keep trying. And success may not be claimed unless it was observed, which is the sort of line you only write after being told something worked when it had not.

There is also a rule that looks like it contradicts the previous article in this series: never replace a Hermes tool with curl, Python or a terminal command unless the tool has already failed. It reads as the opposite of building your own wrappers, and it is not. The wrappers are the tools. Once a tested command exists for a job, reaching past it for an improvised shell call throws away the entire reason it was written.

A system prompt turns out to be less like a configuration file you get right once, and more like a set of house rules that grows a clause every time something breaks.