Nothing works until the reading does
My first agent failed even though the model could write perfectly well. The missing piece was context: it didn’t know enough about the situation before it acted.
The first agent I tried to build at Akarii was unusable. I’d expected to struggle with the quality of its output, but that wasn’t what broke it.
The model could produce good code and fluent answers. The problem was that it often didn’t know the right things before it started. It wrote confidently from an incomplete picture.
Improving the prompt style didn’t help much. If the agent had read the wrong files or missed the relevant history, the response was built on bad foundations.
Where the hallucinations came from
That project was my first serious encounter with hallucination. The model would encounter a gap in its context and fill it with something plausible, often without signalling much uncertainty.
I started treating many hallucinations as context failures. The bad answer was visible, but the useful debugging question was upstream: what did the agent read, and what should it have found before answering?
Why the good products feel like magic
The best model-powered products often look effortless because the system quietly found the right context at the right moment. By the time the model writes, much of the product work has already happened.
As a user, you only see the final answer. You don’t see the searches, retrieval, permissions, and filtering that made the answer relevant. That hidden reading is a large part of what makes the product feel intelligent.
The reading is the part you build
A lot of my agent work now goes into deciding what the model can see, when it should look, and how much it should bring into context. That includes files, memory, tool results, and the current state of the task. These choices make up much of the harness.
Better tool use lets current models find more context on their own, but the product still determines what is reachable and how it is organised. An agent can’t discover a source it has no permission or tool to access.
The writing is not free either
Output still needs controls. A capable agent can take an action you didn’t request, overwrite a file, or run the wrong command. Context improves the quality of its decisions; permissions, approvals, and guardrails limit the damage when those decisions are wrong. Both sides need deliberate design.
The line you cross by building one
After building the first version, I spent far less time worrying about whether the model could generate an answer. Most of the work went into helping it find the right information and limiting what it could do with that information.
That experience changed what I look for in agent products. Fluent output is the visible part. I’m more interested now in what the agent read before producing it, and what the product allows it to do next.