The Vocabulary of Agent Governance Is Still Being Written
Even the word agent is still finding a shared definition, and the words for governing one are earlier still. We published a 50-entry glossary to state our definitions in public, where they can be checked, disputed and revised.
OpenAI’s developer guide introduces function calling and adds, in a parenthesis, that it is also known as tool calling. Anthropic’s documentation calls the same round trip tool use. One mechanism, three names, and a parenthesis to reassure the reader that they are the same thing.
The word underneath is less settled than it looks. In September 2025, Simon Willison, who had avoided the term for a couple of years, wrote that he thought a definition had become widely enough agreed to be useful, and adopted one: “An LLM agent runs tools in a loop to achieve a goal.” That is one careful practitioner choosing a working definition, not the industry settling the term. And the vendor-neutral schema for agent telemetry, OpenTelemetry’s semantic conventions for generative AI, defines operations for invoking an agent and executing a tool, and still marks them as in development.
If the words for what an agent is and does are still moving, the words for governing one are earlier still. That is the condition we build in. So we have published a working vocabulary for AI agents and runtime governance: 50 entries, nine of them full articles today. This post is about why a small engineering team spent the effort, and what rules the entries had to pass.
A loose word carries a claim
Take the word “action.” A sentence like “the agent deleted the build directory” reads as one fact. It is at least three.
Here is an abridged event from a Sentience Agent Execution Record, for one shell step of a coding agent, taken from the glossary’s entry on the execution boundary. It was generated with the released Sentience Governor 0.3.2 Claude Code integration from representative Claude Code hook payloads. No command was executed. Envelope metadata and the policy findings attached to the event are omitted.
{
"event_type": "SCOPE_ASSERTED",
"pass_through": true,
"payload": {
"tool_id": "Bash",
"operation_type": "EXECUTE",
"asserted_permissions": ["execute"],
"target_system": "shell/filesystem",
"operation_classification": {
"complete": true,
"destructive": true,
"segments": [
{
"executable": "rm",
"effects": [
{ "domain": "filesystem", "action": "delete", "destructive": true }
]
}
]
}
}
}The entry pairs it with a second record, generated the same way from a representative hook payload for a test-suite command. Nothing was executed for that one either. It has the same tool, the same operation type and the same asserted permission. What differs is the part derived from the command: a process execution with an undetermined destructive value in one case, a filesystem deletion marked destructive in the other. We described how that classification works in What Does an Agent Action Actually Mean.
Now look at what the record does not say. It keeps the executable name, rm, and not the arguments, so the directories do not appear. And it was produced from the pre-execution payload alone, which is why it could be generated without running anything. It describes an attempt.
An attempt, a returned result and a confirmed effect are three different facts, and a record of the first is not evidence of the third. The glossary defines an agent action as a single operation an agent attempts, recorded as structured metadata. “Attempts” is the word doing the work. Whoever reads the record during an incident review needs to know which of the three facts they are holding.
The same pressure applies to our own one-line description: Sentience Governor evaluates agent actions against declared governance context and records governance evidence without blocking execution. For that sentence to be checkable, “action,” “declared” and “evidence” each need a definition the software can be held to. A glossary is where those definitions live.
Two kinds of entry, and what the label means
Thirty-four of the entries are industry concepts: AI agent, tool calling, agent observability, guardrails, prompt injection, the Model Context Protocol. We did not originate these, and the entries explain them neutrally, with the general concept first and any mention of our product late and brief.
Sixteen are labeled Sentience concepts. The label is easy to misread. It marks a page that explains a term as Sentience defines or implements it. It is not a claim of authorship. Several of the sixteen are established phrases to which we give a specific operational meaning, such as runtime governance. Some are older governance ideas that the product formalizes, such as declared intent, which in the software is an event written to the record before the activity it applies to. Some are mechanisms. One is product terminology, the Sentience Agent Execution Record. One is the architecture proposed in our white paper, the Governor Model, and its entry will carry the same notice the paper does: it describes architecture and direction, not shipped capability.
Several of these words are also names in our code: an event type, a tool, a field in a record. Implementation is what gave the concepts precise operational meanings. A declared intent has to be an event with a position in a sequence, and a declared scope has to be something an action’s target can be compared with. That precision does not make the words ours. Others are reaching for neighboring words from different directions. A March 2026 paper, Runtime Governance for AI Agents: Policies on Paths, argues that the execution path is the central object for governing agents at run time, and formalizes policies over it. That is a different cut at the problem from a declared objective and scope, and it uses much of the same language.
This is what a forming field looks like. People converge on words before they converge on definitions. We do not expect each definition we have written to be the one that lasts. We do think the field is better served by definitions stated plainly enough to be disputed than by terms everyone uses and nobody pins down.
The rules each entry has to pass
A glossary written by a vendor deserves suspicion, so the entries follow rules that are meant to be checkable from the outside.
Statements about Sentience Governor are checked against the released package, not the roadmap and not our intentions. Each article records the release it was reviewed against. Planned capability is either left out or labeled as planned.
Examples state their provenance before the example. Whether a record is genuine output or an illustration, which integration produced it, whether anything executed, and what was omitted. The excerpt above follows that rule.
Adjacent technology is described in terms its practitioners would accept. Observability makes agent execution inspectable: tool calls, inputs, outputs, timing, errors. Observing an action does not, by itself, establish whether it was consistent with a declared objective, scope or policy. An observability system can be instrumented to carry that context, and one system can support both. The difference is what each is organized around, and no entry argues that a neighboring category has failed at something. The same care applies to guardrails, sandboxes, identity, authorization and evaluation.
Each entry says where it stops. The article on runtime governance states that Sentience Governor observes and flags, and that every call proceeds. The evaluation is deterministic and structural: it compares an action’s tool, operation type and target with what was declared, and it does not read the meaning of the objective. So Sentience Governor 0.3.2 does not flag an action merely because it fails to advance the objective. Other structural findings, from the default policy rules or the operator’s profile, may still apply to the same action. That limitation is written into the entries, because governance evidence is worth more when its gaps and unknowns are recorded than when they are left out.
In editorial review, the words that drew the most corrections were the absolutes: every, only, cannot. Nearly all of them came out. A definition that overreaches is a claim someone else has to clean up later.
What is there today
All 50 entries are on the index with a one- or two-sentence definition. Nine have full articles. The other 41 are marked as coming soon, and they are not links, because a link to a page that says nothing is worse than no link.
The nine were chosen to read in order, from the field’s words into ours: AI agent, tool calling, execution boundary, declared intent, governance evidence, runtime governance. Alongside them are agent action, agent observability, and AI agent governance, which separates governing an agent at run time from the organizational programs that usually carry the word governance.
The rest will follow in batches. Which come next depends on which of the first nine turn out to be useful to people who are not us.
A test for your own vocabulary
Take one sentence from your last agent incident review, or one label from the console you watch agents through: “the agent did X.” Ask which fact your evidence supports. That the agent attempted X, that a tool returned a result for X, or that X took effect in the world.
Then ask where the statement of what the agent was supposed to be doing is written down, who wrote it, and when. If two people on the team answer differently, the gap is in the vocabulary before it is in the tooling.
The glossary’s introduction ends with a sentence we mean literally: as the field evolves, so will these definitions. If one of them is wrong, that is worth knowing now, while the vocabulary is still being written.