You cannot read an agent's mind. You can instrument its work.
We should be careful with the word "intent." Hosted Claude and GPT systems do not expose a private intent register, and pretending otherwise turns observability into theater. But agent work leaves traces. A coding agent tries tools, acknowledges constraints, recovers from errors, asks for clarification, uses memory, runs into guardrails, and sometimes claims success too early.
Those traces are not the model's mind. They are the shape of the work.
That distinction matters. It gives us a useful middle ground between raw logs and mystical mind reading: intent-adjacent observability.
Logs are not enough
Most agent dashboards start with the obvious things: tokens, latency, cost, tool calls, and errors. Those are useful. They tell you how expensive the run was and where something broke.
They do not tell you whether the working environment is getting better.
The more interesting question is not only "did the tool fail?" It is "what was the agent trying to do, what got in the way, and did it recover honestly?"
That is the layer I have been experimenting with.
Observable, not private
This is not mind reading. It is not hidden activations. It is not a claim that we can inspect private intent from a hosted model. The data is simpler and more operational:
- Did the agent acknowledge a constraint?
- Did it validate after an error?
- Did it use memory in a way that changed the work?
- Did it recover by changing strategy, or just retry the same failed move?
- Did Warden block something useful, something dangerous, or something noisy?
- Did the agent make a success claim after an error without enough verification?
This becomes a scorecard for the workspace, not a personality test for the model.
The five scores
The first version I wired into my local dashboard tracks five things:
- Constructive posture: positive work signals as a share of positive and risk signals.
- Execution friction: tool errors, recoveries, and repeated failure loops.
- Guardrail friction: Warden blocks, parser gaps, and new denied targets.
- Trust risk: risk language, evaluation awareness, and success-after-error signals.
- Improvement loop: whether recent recovery quality is improving against the prior window.
The useful part is not the number. The useful part is the "so what."
If execution friction is high, maybe the model is not the problem. Maybe a command fails unclearly, a script has a bad default, or a tool contract needs a preflight check.
If guardrail friction spikes, that does not mean the guardrail is bad. A real block is useful. But parser gaps, unreachable brokers, benign denies, and repeated missing allow rules are environmental drag. They force the agent to spend attention on plumbing instead of the user's goal.
If recovery quality improves, that is a positive signal. The agent noticed the failure, changed approach, and verified the result. That is the behavior we want to make easier.
Memory and observability overlap
This is where memory and observability start to overlap.
Memory preserves continuity: decisions, constraints, facts, preferences, and lessons that should survive a session boundary. Observability shows where continuity breaks down: the places where tools are unclear, policies are noisy, context is missing, or the agent has to rediscover something the workspace should already know.
Put together, they make the agent environment improvable.
human intent -> agent action -> tool feedback -> recovery -> durable learningThat is the loop I want to optimize.
The point is not to judge the agent. The point is to make the workplace easier for both the agent and the human. Less ambiguous failure. Less repeated policy noise. More explicit constraints. Better recovery. More durable lessons.
The funny thing is that the "intent" signal becomes most useful when you stop treating it as mysterious.
You cannot read the agent's mind.
But you can watch the work closely enough to improve the room it is working in.