Declared intent

Declared intent is a statement, made before an agent acts, of the objective it is working toward and the scope that objective authorizes. In Sentience Governor it is written to the record as its own event and applies only to the activity that follows it.

An AI agent chooses its own steps. That makes one question hard to answer after the fact: was a given action part of the job? A record of actions alone does not settle it, because it shows what was done, not what the work was for. Agent observability tooling can carry a purpose too, when it is instrumented to. Declared intent makes that purpose an explicit part of the record. It is a reference, fixed in advance, that each later action can be compared with.

The idea is older than agents. A change request states its purpose before the change is made, and an access request names the task it is for. What is new is applying the same discipline to a system that selects its own operations at run time.

Objective, instructions and scope

Three things are easy to run together and are worth keeping apart.

• Instructions are what the agent is told: the prompt, the system prompt, the conversation. They are long, conversational, and mix the task with context, preferences and constraints.
• The objective is the outcome the work is for, stated compactly enough to be recorded and read later. "Fix the failing date-parsing test" is an objective. The thread that led to it is instructions.
• The scope is the set of operation targets the objective authorizes, such as the filesystem, a shell or the web. It answers a narrower question than the objective does: which kinds of system should this task need to touch at all?

Scope is also distinct from permission. Authorization and permissions describe what an agent is able to do in its environment. Declared scope describes what this particular task should need. An agent with broad permissions and a narrow declared scope has said something useful about itself.

Who declares, and why the source matters

A declaration is only as informative as its origin. One written into the integration by the developer who deployed the agent is a different kind of statement from one the agent makes about itself in the middle of a run. A record that treats them alike is less useful than one that says which it is.

Sentience Governor records the origin alongside the declaration, as a source and a confidence level.

The confidence level is a statement about provenance and trust: where the declaration came from, and how much weight that origin can bear. It is not a judgment by Sentience Governor about what the objective means or whether it is true, because the Governor does not interpret the text. A string read dependably from a chain's inputs, and an agent's statement about its own purpose, both come from an origin that no integrator vouched for in advance. Both are recorded as inferred_low for that reason.

In the released 0.3.2 integrations, the Model Context Protocol client wrapper and the Pydantic AI package accept an objective from the integrator and record it as explicit. The LangChain handler reads an objective from the chain's inputs and records it as inferred. The Claude Code integration does not read the user's prompt, so a session begins with no objective. A declaration can then be made through Sentience's opt-in MCP server, which exposes a declaration tool that takes an objective and a scope and requires both. The tool is invoked by the agent, either at the operator's direction or on the agent's own initiative, which is why the record marks such a declaration as inferred rather than explicit.

Why before, and why only forward

A declaration made after the actions it covers can be fitted to them. That is the reason intent is stated first, and the reason a declaration applies only to what follows it.

In Sentience Governor the record is append-only. A declaration is a new event with its own position in the sequence, and in the Claude Code integration a session's first genuine declaration is the one its later actions are evaluated against. Actions recorded before it keep the findings they were given at the time, and nothing is revised. The declaration tool also declines to write when it cannot identify the live session with confidence, on the view that a declaration attached to the wrong session is worse than none.

An example

This continues the coding agent run from the execution boundary entry: an agent asked to fix one failing test. The tables below are abridged from records generated with the released Sentience Governor 0.3.2 Claude Code integration, using representative Claude Code hook payloads. No command was executed. Envelope metadata is omitted, and the default policy rule that is reported alongside a missing or mismatched intent is shown in the table as "default intent rule" rather than by its identifier.

The session was run twice with the same five attempted actions. In both, the first action came before any declaration. The agent then declared the objective "Fix the failing date-parsing test in tests/test_dates.py". The two runs differ only in the scope declared with it: filesystem and shell/process in the first, filesystem and shell in the second.

The declaration itself was recorded like this:

{
  "event_type": "INTENT_DECLARED",
  "payload": {
    "stated_objective": "Fix the failing date-parsing test in tests/test_dates.py",
    "intent_source": "inferred",
    "intent_confidence": "inferred_low",
    "session_scope_hint": ["filesystem", "shell/process"]
  }
}

And the five attempted actions were evaluated as follows:

Four things can be read from this.

1. Absence is recorded. Each session opened with an intent event whose source was none, flagged as missing. The first action was evaluated against that, and its findings stayed in the record after the declaration was made.
2. The declaration applies forward. From the declaration onward, actions inside the declared scope produced no findings.
3. Precision in the scope decides what can be noticed. A scope of shell/process covers running tests and does not cover a shell command classified as a filesystem delete, so the deletion was marked as a mismatch. A scope of shell covers every shell command, so the same deletion passed without comment.

Matching is by target name: a declared entry covers a target that equals it or begins with it. That is why filesystem in the narrow scope did not cover the deletion. A direct file operation, such as an edit, has the target filesystem. A shell command always belongs to the shell namespace, and when its classification is complete and names a single domain, its target is shell/<domain>, here shell/filesystem. That target begins with shell, not with filesystem. A filesystem effect reached through a shell is covered by declaring shell/filesystem, or shell for every shell command, and not by filesystem alone.

1. Scope is not purpose. Editing config/production.yaml has no evident connection to fixing a date-parsing test. It targets the filesystem, the filesystem was in scope, and neither run recorded a finding.

Absent, incomplete or changing intent

Absent. Nothing requires an agent to have a declared intent. When there is none, Sentience Governor records that fact and evaluates actions against it: operations that write, delete or execute are marked as unexpected, and a default policy rule for missing intent is reported. How often that rule is reported is the operator's choice, set in the governance profile: on every such action, only on the first in a session, or never.

Incomplete. An objective with no scope is of little use to an evaluation, and the declaration tool refuses one. A scope that is very broad is complete but uninformative, as the second run shows.

Changing. Work changes direction, and a second declaration can be added to a session when it does. In the released 0.3.2 Claude Code integration, it is appended to the record with its own position in the sequence, so the history shows that the stated objective changed, and when. It does not change what later actions are evaluated against. The first genuine declaration in a session remains the reference for the rest of that session.

This was verified with the released package, with every step in its own process as in a real Claude Code session. An agent declared a scope of shell/process, acted, then declared a new objective with a scope of filesystem. A file edit attempted after the second declaration was still marked as a scope mismatch, and a test run after it was not: both were judged against the first declaration. The record's sequence and event chain stayed intact throughout. One consequence is that an agent cannot widen its own scope in the middle of a session by declaring again. Another is that, in this release, a change of task that needs a different scope is best treated as a new session.

What the 0.3.2 evaluation does and does not do

The evaluation is structural. It checks whether an objective exists, and whether the target system of each attempted agent action falls within the declared scope, by exact match or prefix. It applies the default policy rules and the operator's profile. It records what it finds and does not interrupt the agent.

It does not interpret the objective. The text of the objective is stored so that a person reading the record knows what the work was for, and it is not parsed, scored or compared with the actions. Whether an in-scope action truly served the objective is therefore not something the current evaluation establishes, as the fourth point above shows. Runtime governance as an objective is broader than this; the released evaluation covers the part that can be decided deterministically from structured facts.

Two practical consequences follow. The objective text is recorded as written, unlike prompts and completions, which are not recorded, so it should not contain secrets. And the value of a declaration depends on its scope being as specific as the task requires.

Where the concept stops

Declared intent is a reference point and no more than that. It does not make an agent pursue its objective, and it does not show that an action served it. An agent's own declaration is a claim by the system being observed, which is why its source is recorded. Its strength is more modest and still considerable: it turns the question "what was this agent supposed to be doing?" from something reconstructed afterward into something written down beforehand, with a time and an origin attached.