What is Tool-Call Record?

Why It Matters

A model call returns text. A tool call writes a file, sends a request, modifies a database, spends money. The tool-call record is where the agent’s reasoning meets consequences, and it is the layer application logs miss most often, because framework-level executions land outside the app’s span tree.

Governance runs on these records. The OWASP Top 10 for LLM Applications lists excessive agency as a distinct risk, and the practical control is tool-call logging: if you cannot see which tools ran, with what arguments, in what order, you cannot detect excessive agency or govern it.

What It Captures

The request. Which function the model asked for and the exact arguments it supplied.

The policy decision. Whether the call was allowed, denied, modified, or escalated, and which check made that call.

The result. What the tool returned, since a poisoned or malformed response propagates into every later step.

Cost and latency. What the invocation took in time and dollars, feeding cost attribution upstream.

Where It Breaks

Capturing the call but not the decision is the common gap: the log shows a tool ran, while the denied and escalated calls, the ones that explain what the agent tried to do, never get recorded. Partial capture produces a record that proves less than it appears to.

The second break is recording arguments without results. The request side shows intent; without the response you cannot tell whether the tool did what the agent believed it did.

How Flytebit Handles It

Every invocation in our builds lands in the trajectory as a complete record: request, policy decision, result, latency, cost. Because the tool boundary is also where runtime governance enforces policy, the record captures the enforcement outcome alongside the call itself. The governance case for first-class tool-call records is in Observability for Agentic AI Governance.