This summer, for me, is running under one very specific flag: the war against agent hallucinations.
Not in the abstract sense of "models sometimes lie." Everyone already knows that. In the practical, engineering sense: how do you make an agentic system reliably carry out a task without drifting into fantasy, forgetting the rules, ignoring the PRD, closing the task too early, or pretending the work is done?
In Datarim, inside the Arcanada ecosystem of agentic systems, I keep arriving at one simple idea: agents need motivation.
It sounds strange. An agent has no personality, no emotions, no ambitions, no human desire to do well. But by "motivation" I mean something different: the agent needs to be told, very clearly, what is expected of it.
Not just "do the task." Not just "implement the feature." Not just "fix the bug."
But to paint it a clear picture of the result.
What should come out of this. Which items must be closed. What the correct solution looks like. Which test cases must pass. By what signs the operator, the review agent, or the system will understand that the work is genuinely done.
This works best not as abstract text, but as a checklist. Because a checklist turns an expectation into a contract.
If every item is closed, the task can be considered done. If even one item is not closed, the task is not done. If an item is closed "on paper" but there is no proof, the task is not done. If the review agent found a comment, the task goes back for revision. And it goes back as many times as needed.
Even if the loop turns out to be endless. Because the alternative is worse: the agent cheerfully reports that everything is ready when in fact it simply lost part of the conditions, invented the missing details, and closed the task inside its own head.
The key question for the agent
The simplest and most useful question I now ask an agent before every implementation step:
"Show me how you will do it?"
It seems trivial. The agent will just go and list a plan. Write which files it will look at. Which rules and skills it will rely on. Which related tasks it will re-read. Which tests it will run. Which constraints it will account for.
But it is precisely at this moment that something important happens: the agent stops fantasizing and starts orienting itself.
It re-reads the PRD. Pulls up previous similar tasks. Looks at the project rules. Compares the current task with existing solutions. And only then begins to act.
When this step is missing, the model starts hallucinating far too easily. This shows up especially in Claude's "dumb" mode: when the context is already crammed, when, in my experience, the window crosses 20%, when the task is long, when the plan has many items, when the model begins to conserve attention or slips into a weaker reasoning mode.
Sometimes it looks as if, instead of normal Claude, the task is being solved by some weaker model. A notional Haiku that seems to be trying but no longer holds the whole picture.
And here is the interesting part: even a weak model starts working noticeably better if there is a clear picture of the result in front of it and if you force it to talk through the plan. Not just "do it." But first: "show me how you will do it."
Why this reduces hallucinations
An agent's hallucination often begins not where it writes code. It begins earlier — at the moment it misunderstood the task but did not show this to the operator.
It did not re-read the PRD. Did not check the old implementation. Did not find the related pattern. Did not verify against the project rules. Did not understand which test cases are mandatory. But it already started acting.
In ordinary development, a human can make the same mistake. But a human at least sometimes stops and asks: "Wait, do we actually do it this way?" An agent, on its own, often does not stop. It has to be taught to stop.
So the question "show me how you will do it" works as a forced pause before action. This is not just planning. It is a check of understanding.
If the agent shows the wrong plan, I see the problem immediately and say: "Re-read the conditions again. In the previous task we did it differently."
And then the useful magic kicks in: the agent returns to the context, finds the old task, re-reads the rules, and often shows the correct plan itself. That is, the mistake is caught before implementation, not after broken code.
The checklist matters more than the feeling that it is done
In Datarim I increasingly bake in exactly this principle: a task is not considered done until the checklist of test cases is closed. And closed not "by feel," but with proof.
For each item it must be clear:
- what exactly was checked;
- where it was checked;
- by what result it is confirmed;
- what remained disputed or unverified;
- whether the review agent has comments.
If an item is not closed, the task goes back. If there is no proof, the task goes back. If the review agent found a problem, the task goes back. If the agent "thinks" everything is ready but cannot show why, the task goes back.
Yes, this can create long loops. Yes, sometimes it is annoying. Yes, sometimes it feels like the agent is stuck. But it is still better than automation that confidently produces garbage.
Autonomy without verification is not autonomy. It is a generator of technical debt.
The problem of the final stage
There is one more important point. Agents often forget to do reflection before closing or archiving a task.
Even if the self-learning skill is already written. Even if the rules graph has been rewritten a hundred times. Even if the system explicitly states that after a task you must extract lessons and save them into project memory. The agent can still skip this step.
So I have to remind it manually:
"Do a compliance check and show the extracted lessons and mistakes that need to go into project memory."
This is a separate part of the fight. Because an agentic system should not merely complete a task. It should become a little better after completing it.
If the agent made a mistake — that should go into memory. If the agent found a new pattern — that should go into the rules. If the PRD was ambiguous — that should be recorded. If a test case turned out to be important — it should become part of future checks. If the review agent caught a typical problem — that should strengthen the next cycle.
Otherwise we are not building a system. We are just talking, every time, to a forgetful contractor.
What I am now changing in Datarim
Right now I am teaching the orchestrator to run these re-checks automatically.
Before every stage of a task, the agent must show:
- How it understood the task.
- Which PRDs, rules, skills, and previous tasks it relies on.
- Which implementation plan it proposes.
- Which test cases will prove completion.
- Which risks and ambiguities it sees.
After the stage, it must show:
- What exactly was done.
- Which checklist items are closed.
- By what it is proven.
- What is not verified.
- What comments the review agent has.
- Which lessons need to be saved into project memory.
This turns the agent from a "generator of actions" into a participant in a managed process. It no longer just does something. It has to explain why it is doing it this way. Prove that it did it. And hand the system new experience.
The war against hallucinations
Agent hallucinations cannot be defeated by a single magic instruction. You cannot just write "do not hallucinate" in the system prompt. That does not work.
You need architecture. You need PRDs. You need checklists. You need test cases. You need review agents. You need return loops. You need project memory. You need reflection after completion. And you need one simple, human question before the work begins:
"Show me how you will do it?"
This question seems small. But it changes the agent's mode of operation. It forces the model to stop. Re-read the conditions. Find its anchors. Assemble a plan. Show its assumptions before they turn into code.
And this is exactly where the line runs between chaotic agentic automation and a real engineering system.
Arcanada, for me, is not about agents simply "doing something." It is about an ecosystem in which agents work, check each other, learn from mistakes, and gradually become more reliable. Datarim is one of the tools of this ecosystem.
And my main fight this summer is to make sure the agent does not just complete a task, but can honestly answer, every time:
"Here is how I understood it. Here is how I will do it. Here is what I rely on. Here is how I will prove the task is done."
Until the agent can show this — it is too early to trust it with autonomy.