Tool

In plain language: The word is plain. A Tool extends what an Agent can sense, model, or affect.

Definition

A Tool is an entity that an Agent uses to extend one or more of its Boundaries. It is the contrastive category to Agent: an entity that does not itself have all three Boundaries in any meaningful sense, but that extends the reach of an Agent that does. A telescope extends what the Agent can see. A map extends what the Agent can model. A gun extends what the Agent can do. Each is a Tool because each extends a Boundary without being an Agent in its own right.

Tools operate in three directions, classified by the function the Tool performs for the Agent — not by the physical mechanism through which the Agent interacts with it:

  • Computational Tools extend the Computational Boundary by adding or amplifying channels. A telescope, a microphone, a satellite dish, an API connection to an external data source — each delivers information the Agent would not otherwise receive from outside itself.
  • Cognitive Tools extend the Cognitive Boundary by reorganizing information the Agent or its Composition already has, making it available for modeling. A map, a written report, a CRM, a dashboard, an analyst’s framework — each is an internal artifact that extends what the Agent can understand. A Cognitive Tool does not create new external input; it extends modeling.
  • Causal Tools extend the Causal Boundary by amplifying or redirecting the Agent’s effects. A gun, a lever, a broadcast antenna, a provisioned shell command — each lets the Agent affect things it could not otherwise reach.

The classification is by function, not mechanics. The delivery mechanism of any Tool is always Computational in a trivial sense — you need senses or channels to perceive anything. A VP reads a CRM with his eyes; an AI agent receives a knowledge-base query through its input context. But the photons and the tokens are delivery mechanisms, not the Tool’s function. The CRM’s function is to extend modeling (Cognitive). The weather API’s function is to deliver new external data (Computational). The shell command’s function is to extend reach (Causal). Classifying by delivery mechanism instead of function collapses every Tool into Computational, which makes the distinction useless.

A Tool the Agent has on hand — provisioned, available, within reach at the moment of analysis — extends the relevant Boundary at Capacity whether or not the Agent is aware of it. The Agent’s Frame determines which Tools the Agent actually uses — not which Tools extend the Boundary at Capacity. An employee with a CRM feature he doesn’t know about has that feature at Capacity (the modeling extension exists) but not at Realization (he never accesses it because his Frame doesn’t include it). An AI agent with a provisioned tool not described in its instructions has access to the tool (Capacity) but doesn’t know it’s available, so Realization of that tool remains zero. In both cases, the intervention is the same: move the Tool inside the Agent’s Frame (training, documentation, a colleague’s mention) and Realization catches up to Capacity without any change to the underlying Boundary.

Whether a Tool extends Intrinsic or Positional reach depends on whether the Agent has access to the Tool independently or only through its position in a Topology. A personally owned firearm extends Intrinsic Causal reach. A corporate broadcast channel the Agent uses only as the company’s spokesperson extends Positional Causal reach — the access stays with the role when the Agent leaves.

What a Tool is not:

  • Not an Agent. An Agent has all three Boundaries; a Tool does not. At the low end of the gradient, entities with extremely minimal modeling (a spell-checker, a thermostat) technically pass the three-property test but calling them Agents adds nothing to any analysis. The framework acknowledges this gradient rather than drawing a bright line — categorize at the resolution that serves the question you are asking.
  • Not a Protocol. A Tool is an instrument the Agent uses. A Protocol is a rule governing how Agents interact — signing authority, approval thresholds, meeting cadences, escalation policies. Both can shape Boundaries, but they are different categories. A CRM is a Tool. A contract-approval threshold is a Protocol.

Relations

Tool is the contrastive category to Agent in the framework’s vocabulary. Every Boundary definition references Tools as the mechanism by which Agents extend their reach. The tri-directional classification (Computational / Cognitive / Causal) mirrors the three Boundaries and is the reason the framework names three directions rather than treating Tools as a single category.

Frame determines Tool usage across all three directions. Frame is itself a Cognitive function — the Agent’s self-model of its own Boundaries — which means the Cognitive Boundary is the bottleneck for Tool usage everywhere, even for Tools that extend non-Cognitive Boundaries. An Agent with a narrow Cognitive Boundary has a narrow Frame, which means it under-uses Tools across all directions.

Protocol and Topology are the other two structural elements of a Composition alongside Tools. Topology is the arrangement of Agents. Protocols are the rules governing their interaction. Tools are the instruments they use. All three shape Boundaries; each is a different kind of thing.

Example — CEO

A sales VP inherits a team that uses three tools daily: a CRM that tracks every customer interaction and flags accounts at risk of churn, a competitive intelligence dashboard that aggregates publicly available data on competitor pricing and product launches, and a corporate email system.

The CRM is a Cognitive Tool — it reorganizes information the organization has already gathered (sales calls, support tickets, contract history) into a form that extends the VP’s ability to model his accounts. It does not deliver new external information; it makes internal information usable. The competitive intelligence dashboard is also a Cognitive Tool — it aggregates and presents data that entered the organization through other channels. Both extend the VP’s Cognitive Boundary at Capacity whether or not he knows every feature they offer.

The email system is harder to classify, and this is where function matters. When the VP receives an email from a customer — new information from outside the organization crossing his perimeter — the email system is functioning as a Computational Tool. When the VP reads an internal strategy memo forwarded by his CTO — an internal artifact reorganizing information the organization already has — the email system is functioning as a Cognitive Tool. The same system performs different functions at different moments. Classify by what the Tool is doing for the Agent in the specific case, not by what the system is in general.

The VP discovers that the CRM has a feature he never knew about: a predictive model that scores accounts by likelihood of expansion. The feature has been available since his first day — it was on hand, extending his Cognitive Boundary at Capacity. But his Frame didn’t include it, so his use of the CRM was narrower than its Capacity. A colleague mentions the feature in passing. Now the VP’s Frame includes it, and his Cognitive Boundary at Realization expands immediately — same Tool, same Capacity, wider Realization.

Example — Research

An AI agent — a language model plus its operational harness — is deployed as an autonomous research assistant. Its deployment provisions three categories of Tools:

Computational Tools deliver new information from outside the agent. An API connection to an academic paper database lets the agent search for and retrieve papers it has never seen — new external data crossing the agent’s perimeter. An API connection to a live news feed delivers current information the agent’s training data does not contain. Each adds a channel the agent would not otherwise have.

Cognitive Tools extend the agent’s modeling without delivering new external information. A retrieval-augmented knowledge base containing the organization’s prior research reports is an internal artifact — the information was gathered and written by other Agents in the same Composition, and the knowledge base reorganizes it into a form the agent can query. The agent’s system prompt, which describes its role and provides analytical frameworks, is also a Cognitive Tool — it extends the agent’s modeling by structuring how it reasons about what it receives.

Causal Tools extend the agent’s reach. A provisioned file-write command lets the agent create documents. An API call to a project management system lets the agent create tasks and assign them to human team members. Each lets the agent affect systems it could not otherwise touch.

The agent has a provisioned Causal Tool — access to a code execution sandbox — that is not mentioned in its system prompt. The Tool is on hand: the API is provisioned, the permissions exist. The agent’s Causal Boundary at Capacity includes the ability to execute code. But the agent’s Frame does not include the sandbox — it doesn’t know it’s available — so it never uses it. A configuration update adds the sandbox to the system prompt. The agent now knows the Tool exists, begins using it, and its Causal output expands to match the Capacity that was always there.

The classification-by-function principle applies to the AI case with particular clarity. Every interaction an AI agent has with any Tool passes through its input context (tokens in) and its output generation (tokens out). If you classify by mechanism, every Tool is Computational on the input side and Causal on the output side — and the distinction collapses. The distinction holds only when you ask: what is the function of this Tool for this Agent? The paper-database API delivers new external information (Computational). The knowledge base reorganizes internal information (Cognitive). The file-write command extends reach (Causal). Same mechanical pattern — tokens in, tokens out — three different functions.