OpenClaw Exposes Tool-Use Blocks to Hooks, Which Is How Agent Supervision Stops Guessing
If your agent supervision layer can only read the final answer, it is not supervising the agent. It is grading the press release the agent wrote about itself. OpenClaw PR #93442 fixes a deceptively important gap by exposing structured tool-use blocks to llm_output and agent_end hooks. That sounds like plumbing because it is. It is also the difference between policy enforcement and wishful transcript analysis.
The PR adds a toolUses field to hook payloads, with each entry carrying the tool name and input. Before this, conversation-access hooks could see assistant text, but not the structured actions the assistant took during the turn. Downstream supervisors trying to enforce tool budgets, capability caps, or audit rules had to infer behavior from prose. That is exactly the wrong abstraction for systems that can send messages, run shell commands, touch files, query APIs, or invoke MCP tools.
Issue #93381, opened June 15, states the failure plainly: hooks omit tool_use blocks even when hooks.allowConversationAccess: true is enabled. The reporter confirmed the absence across all nine bots on their pod and tied it to a downstream supervisor that needs per-turn audit. This is not a theoretical purity complaint. It is an operator saying: the control plane cannot see the actions it is supposed to control.
Final-answer audits miss the crime scene
Agent traces rarely look like a single clean assistant response. A normal tool-using turn may go: assistant tool call, tool result, assistant tool call, tool result, final assistant message. The final message might be perfectly benign: “Done.” If a hook inspects only that last message, it misses the filesystem read, the Slack send attempt, the browser action, the private API query, or the refused tool call that happened earlier in the same turn.
PR #93442 handles that by scanning all current-turn assistant messages, not just the final one. That implementation detail is the whole point. The proof case in the research brief is almost comically direct: the old final-message-only approach found zero tool calls, while the new current-turn scan found two tool calls across OpenClaw-normalized toolCall blocks and provider-native tool_use blocks. Zero versus two is not a small observability delta. It is the difference between “nothing happened” and “the agent acted twice.”
The files touched tell you where the boundary lives: src/plugins/hook-types.ts, src/plugins/hooks.ts, src/agents/embedded-agent-runner/run/attempt.ts, src/agents/cli-runner.ts, and docs/plugins/hooks.md. This is not UI polish. It is runtime telemetry becoming available to plugins and supervisors that sit outside the core agent loop.
For anyone building agents in production, this should land as a checklist item. Do not rely on the model to summarize what it did. Do not rely on final prose. Do not rely on phrase matching like “I sent the email” or “I checked the file.” Policy needs the structured action block: tool name, arguments, timing, result, error state, approval state, and ideally the identity under which the action ran. Anything less is an invitation for drift.
Instruction-only safety is not enough
The agent industry keeps rediscovering the same lesson: instructions are useful, but they are not controls. You can tell a model not to use a tool. You can ask it to ask permission. You can require it to explain itself. Those are behavioral nudges. Controls live in the runtime: what tools are available, what arguments are allowed, what policies gate execution, what logs are captured, and what supervisors can observe.
Structured toolUses in hooks moves OpenClaw closer to that runtime-control model. A supervisor can count how many times a tool was invoked in a turn. It can detect a forbidden tool name. It can inspect arguments for policy violations. It can maintain per-tool budgets. It can flag suspicious sequences: web search followed by shell, credential lookup followed by message send, filesystem read followed by external post. These are not things you want inferred from a natural-language recap after the fact.
This also matters for agentic software development workflows. If an agent edits code, runs tests, opens PRs, or comments on issues, tool-call telemetry is the substrate for quality gates. Did it run the test it claimed to run? Did it call the GitHub API? Did it invoke the formatter? Did it skip the build? Did it attempt an elevated shell command? Without structured tool traces, “agentic SDLC” becomes a very expensive honor system.
The limitation is worth stating. The new toolUses entries carry name and input. The issue’s ideal version also wants matched tool results and error state. That next step matters. Knowing an agent attempted to send an email is useful; knowing whether the send succeeded, failed, was refused, or returned a specific message ID is what closes the audit loop. Action without outcome is still an incomplete trace. But action visibility is the first necessary fix.
Practitioners should act now rather than waiting for the perfect telemetry shape. If you use OpenClaw hooks for supervision, update your hook consumers to read toolUses when the PR lands. Build policies around structured tool names and arguments. Add regression tests for the sequences you care about: prohibited tools, high-risk arguments, tool-budget exhaustion, and tools that must require approval. If your current supervisor only reads assistant text, treat that as a known gap, not a design choice.
This PR is also a useful comparison point for other agent platforms. Ask whether their extension system exposes actual tool calls to policy layers. Ask whether it includes intermediate assistant messages, not just final replies. Ask whether provider-native tool formats and normalized runtime formats both appear. A platform that hides tool calls behind prose may be friendly for demos, but it is hostile to audit.
The editorial take: agent supervision cannot be instruction-only and it cannot be final-answer-only. OpenClaw exposing tool_use blocks to hooks is the move from trusting the model’s story to auditing the runtime’s facts. That is the direction the whole category needs to go.
Sources: OpenClaw PR #93442, OpenClaw issue #93381