Agent action

An agent action is a single operation an agent attempts at the execution boundary, recorded as structured metadata: the tool used, the type of operation (read, write, delete or execute) and the system it targets. The record describes the attempt, not the content of prompts or completions.

An agent action is not merely a tool call. A tool call is the mechanism. The action is what that call represents: a particular operation, requested through a particular tool, with some potential effect on some system, at some point in a longer run. Its operational meaning comes from all four. For an autonomous system this matters because the tool name, which is the easiest thing to record, is often the least informative thing about what is happening.

The anatomy of an action

Five elements are present whenever an AI agent takes a step. They differ sharply in how much an outside observer can know about them.

Two consequences follow. An observed request establishes that a particular operation was attempted. It does not reveal the reasoning behind it. And whether the operation was relevant to the task is not a property of the request at all. It requires a separate evaluation, against a declared purpose and the context of the run.

Tool identity is not operational meaning

The examples in this entry are abridged from a record generated with the released Sentience Governor 0.3.2 Claude Code integration, using representative Claude Code hook payloads. No command was executed. An objective was declared, with a scope of filesystem and shell, after the first command and before the rest. git status therefore preceded the declaration and was not evaluated under that scope. Identifiers, timestamps and findings are omitted.

A coding agent uses one shell tool for very different work. Five attempted actions, all through the same tool:

The tool and the operation type are identical in every row. Inspecting repository status and deleting a directory are the same tool and the same operation type. Everything that distinguishes them comes from reading the command. The classifier marks sed as a destructive modification only when its in-place flag is present, because that flag overwrites the file; without it, sed is classified as a read.

The reverse also holds: different tools can be aimed at similar effects. The run contains two attempted modifications to the same file, one through a file-edit tool and one through the shell. No command was executed, so neither is a confirmed modification.

The intended effect on the file is of the same kind. The two records have nothing in common except the word filesystem, and even that sits in different namespaces, which is why a declared scope of filesystem covers the first and not the second. A governance system that treats the tool's name as a complete description of the action will see two unrelated events here, and five equivalent ones in the table above. Both readings are wrong.

Classification is not prediction

Understanding an attempted action includes reasoning about what it may do. It is important to be exact about how far that reasoning goes.

In the released product, semantic action classification reads the syntax of a shell command with deterministic rules. It does not execute the command, consult the state of the system, or call a model. It is not a general predictor of what will happen after the operation, and it says nothing about consequences further downstream. What it produces falls into four cases.

• A known effect. git status reads version control state.
• Several effects. curl -o report.json https://example.com/report both reads from the network and modifies the filesystem. Collapsing it to one label would discard one of them.
• An unknown effect. ./scripts/cleanup.sh runs a script whose contents the classifier does not read. The effect is recorded as unknown.
• An incomplete classification. A compound command can contain both. The last action in the example run was curl -o report.json https://example.com/report && ./scripts/publish.sh:

{
  "complete": false,
  "destructive": null,
  "segments": [
    { "executable": "curl",
      "effects": [
        { "domain": "network", "action": "read", "destructive": false },
        { "domain": "filesystem", "action": "modify", "destructive": null }
      ] },
    { "executable": "./scripts/publish.sh",
      "effects": [ { "domain": "unknown", "action": "unknown", "destructive": null } ] }
  ]
}

Consider the alternatives. Forced into one confident label, this command is either "a network read", which hides a script that may publish something, or "unknown", which throws away two effects that were correctly identified. Keeping each effect with its own certainty, and marking the whole as incomplete, preserves exactly what is known and no more. The destructive value has three states for the same reason: true, false, and null for cases the syntax does not settle, such as whether writing report.json overwrites something.

A classified effect is a potential effect. It describes what the command is written to do, not what happened.

An action belongs to a sequence

The single action is the unit of analysis. Autonomy, though, unfolds across many of them, and an action's significance often depends on its neighbors. The example run, in the order recorded:

Read one at a time, each of these is unremarkable. Read together they invite questions that no single event raises. The first four look like a repair loop. The fifth is a plausible cleanup. The last two are harder to connect to fixing a test. A person reviewing the run can see that shape because the governance evidence preserves it: every event carries a sequence number and the identifier of the event before it, and the events around a single call share an identifier that joins the attempt to what returned.

Recording a sequence and understanding it are distinct capabilities. Sentience Governor 0.3.2 does the first. It evaluates each action against the declared reference as it arrives, and it uses a small amount of session state, such as a configured task-boundary signal or whether an objective has been declared yet. It does not reason over the run as a whole, and it does not judge whether a series of individually in-scope actions adds up to the declared objective. That reading is left to the person, or the system, that reviews the record.

From action meaning to governance

The governing question about an action is not simply whether the tool was permitted. It is: what operation was attempted, against which system, under which declared objective, scope and policy, and what could the evaluation establish?

Three cases show why the simpler question is not enough.

• An action can use an authorized tool and be unrelated to the task. The shell was in the declared scope for every action that followed the declaration, including the publish script.
• An action can be inside the declared scope and have effects the classification does not determine. The two script invocations are both in scope and both unknown.
• An action can be classified as destructive and be entirely legitimate. Deleting a build directory is destructive by any reasonable rule and is routine during a repair.

Classification is not authorization, and authorization is not proof of appropriateness. A classification describes a potential effect. Authorization says the agent may do it. Whether it should have, in this run and for this task, is a third question, answered by evaluating the action against a declared intent and, where the structured facts run out, by a person.

How Sentience Governor 0.3.2 represents an action

The concept above is general. What Sentience Governor holds is narrower: a representation of one observed, attempted operation, written at the execution boundary before the call runs.

How the operation type and target are obtained differs by integration, and the differences matter when reading a record.

The empty permissions list in the Pydantic AI case is a marker for a person reading the record, distinguishing the fallback from a declared read, which carries a read permission. It is not a mechanism. Nothing in the released evaluation interprets it as unknown, and such an action is evaluated as a read.

The limits are part of the representation and should be read with it.

• It holds no independent knowledge of the agent's private reasoning. The intended next step is not observed.
• It performs no general semantic evaluation of whether an action was relevant to the objective.
• It does not confirm that a classified effect occurred. It records the attempt.
• It does not observe operations that do not pass through an instrumented integration.
• It does not stop or alter actions. In the released product every event is marked as passed through, and there is no blocking or enforcement.

Where the concept stops

An agent action is the smallest thing worth governing, and it is smaller than the thing people usually care about, which is whether the work was done properly. An action record can say what was attempted, against what, in what order, and with what potential effect as far as that can be determined. It cannot say why, and it cannot say whether the sum of the actions achieved the purpose. Those answers need the declared reference, the sequence, evidence from the systems acted on, and judgment. Keeping the action record honest about what it does not know is what makes it usable by all of them.