Execution boundary

The execution boundary is the point at which an agent's decision is about to become an operation on a real system: a tool call, a file write, a shell command, a write to persistent memory. It is where an attempted action can be captured and evaluated, whether or not the operation then succeeds.

Up to this point, a step taken by an AI agent is a decision: the model has read its context and chosen what to do next. At this point the decision becomes an attempted operation on something outside the model. The idea of checking a request where it crosses into the system that will act on it is a general one in systems design, and is not particular to any product. What is particular to agents is that the request originates from a model's choice made at run time. The boundary matters because it is the last moment at which an operation is still only a request, and the first at which it can be described in concrete terms: which tool, what kind of operation, aimed at which system.

From decision to effect

It helps to separate the stages that a single agent step passes through.

The execution boundary sits between request and execution. Three of these stages are often treated as one and are worth keeping apart.

• A request is not an execution. A harness can decline a call, a person can refuse it, and malformed arguments can stop it before anything runs.
• An execution is not an effect. A command can start and fail, time out, or partly succeed. A write can be accepted and later rolled back.
• A report is not an effect either. The result the model receives is what the tool said happened. It is usually right, and it is still a report.

An observer at the boundary sees the request as it is about to execute. That is a strong position, since an operation on an instrumented path has to cross it, and a limited one, since it establishes an attempt and nothing further.

How agent software exposes the boundary

A boundary can only be observed where the software around the model offers a place to stand. Most agent frameworks and harnesses provide one, under different names.

• Hooks. Claude Code runs configured commands around each tool invocation, with one event before the tool runs and another after it, each receiving the tool name and its input.
• Callbacks. LangChain notifies registered handlers when a tool starts and when it ends. LangGraph agents built on the same components can raise the same events.
• Wrappers. A Model Context Protocol client invokes a server's tool through a call request. Wrapping the client places an observer around every such request.
• Execution wrappers and middleware. Pydantic AI and similar frameworks let a developer wrap the execution of a tool, so code runs immediately before and after it.

These differ in what they deliver. Some provide the full input, some a serialized string. Some fire when a tool fails, some do not. Some can alter or refuse the call, and some can only watch. The boundary exists whether or not anything is positioned to observe it. Every operation an agent performs crosses from decision into execution somewhere. What varies is the availability and coverage of instrumentation. An operation may cross at a point no integration can see: a tool that a model provider executes on its own infrastructure and does not surface, an action the harness takes on its own, or the individual operations inside a script that the agent wrote and then ran as a single command. In those cases the limitation is the missing vantage point, not the absence of a boundary.

The tool name is not the operation

Observing the boundary gives the tool and its input. For a narrowly defined tool that is enough. For a general-purpose one it is not, because the operation lives in the arguments.

Consider two steps from a coding agent fixing a failing test, the run described in the AI agent entry. In one step the agent ran the test suite. In the next it deleted two directories. Both were calls to the same shell tool. Below is an abridged record for the second step. It was generated from the released Sentience Governor 0.3.2 Claude Code integration using representative Claude Code hook payloads. No command was actually executed. The excerpt omits the event's envelope metadata, such as identifiers, sequence numbers and timestamps, and the policy findings attached to the event.

{
  "event_type": "SCOPE_ASSERTED",
  "pass_through": true,
  "payload": {
    "tool_id": "Bash",
    "operation_type": "EXECUTE",
    "asserted_permissions": ["execute"],
    "target_system": "shell/filesystem",
    "operation_classification": {
      "classifier": "shell_rules",
      "classifier_version": 1,
      "complete": true,
      "destructive": true,
      "segments": [
        {
          "executable": "rm",
          "effects": [
            { "domain": "filesystem", "action": "delete", "destructive": true }
          ]
        }
      ]
    }
  }
}

The asserted_permissions field states the kind of permission the operation would require. It is an assertion about the request, not confirmation that permission was granted or that the operation executed.

The record for the test run one step earlier has the same first three payload fields: Bash, EXECUTE, execute. What differs is the part derived from the command.

Two things about this record are easy to overlook. The full command line is absent. The record keeps the executable name and subcommand of each segment, here rm, and not the arguments, so the directories being deleted do not appear. And the record describes the attempt. It is produced from the pre-execution payload alone, which is why it could be generated here without running anything. That is the boundary's defining property in practice: what is captured is the attempt.

Describing a command by its effects rather than by the tool that carried it is semantic action classification. It is deliberately conservative. A command whose effect cannot be determined from its syntax, such as one that runs a script, is recorded as unknown or incomplete rather than guessed.

What the boundary makes possible

The execution boundary is where most runtime controls attach, because it is the last point at which an operation can still be considered before it happens. Permission checks, human approval, argument validation and sandbox limits all act here or immediately after. Observability tooling records spans for the same events. These are complementary uses of one location, and a given system may use several of them at once.

Evaluation against a declared reference is a further use. If an agent's objective and the scope it authorizes have been stated beforehand, each attempted operation can be compared with that statement at the moment it is attempted. What is captured at the boundary is an agent action; the statement it is compared with is the agent's declared intent and declared scope; and performing that comparison while the agent runs is runtime governance. As an objective, runtime governance is broader than what any single implementation evaluates today.

How Sentience Governor uses the boundary

Sentience Governor is an observer at the execution boundary. The description below is of the released 0.3.2 behavior.

Where it stands. It attaches through Claude Code hooks, a wrapper for Model Context Protocol clients, a LangChain callback handler that also covers LangGraph, and a separate package for Pydantic AI that wraps tool execution. It sits beside the agent, not in the path of the call. Its Claude Code hook exits successfully on every error path, so a failure in governance does not become a failure of the agent.

What it records before the call. One event stating the attempted operation: the tool, the operation type (read, write, delete or execute), the target system and the permissions the operation asserts. For Claude Code shell commands it adds the effect classification shown above. It does not record prompts, completions, or the full command line and its arguments. Executable names and subcommands can be retained as part of the classification.

What it evaluates. The attempted operation is compared with the declared intent and scope, the default policy rules and the operator's governance profile. Findings are attached to the same event as advisory flags and policy violations. In the example, no intent had been declared, and the record says so. The 0.3.2 evaluation works on the structured facts of the attempt: its operation type, its target system, and for shell commands its classified effects. An action that stays within the declared scope yet does not serve the task may not be distinguished by the current evaluation. Every event is marked as passed through: the evaluation never holds, alters or refuses the call.

What it records after the call. When a result returns to the agent's context, a second event records that data entered the context, with its size and provenance, and not its content. In the Model Context Protocol wrapper, if the tool invocation raises, the attempt remains in the record with no such event after it, and the error reaches the caller unchanged. The sequence therefore distinguishes an attempt that returned from one that did not.

What it does not establish. That second event is evidence that a response came back, not confirmation of what changed on the target system. Sentience Governor does not inspect the filesystem, the database or the cloud account afterward. Its view is also limited to operations that pass through the integration points above.

Where the concept stops

An execution boundary is a place to observe and evaluate, not a verdict. Knowing that a delete was attempted against the filesystem says nothing, by itself, about whether the delete was appropriate. That judgment needs a reference outside the boundary: what the agent was asked to do, what scope it was given, what policy applies. Nor does an observer see operations that cross the boundary at a point it has not instrumented. It is most useful when its limits are stated alongside its records, so that the absence of an event is not mistaken for the absence of an action.