Acting is not agency

Vendor "agents" often mean "can call tools and post results." Teams mirror that test: if it writes to the shopping list, it must be an agent. That confuses perform with pursue and hides whether anyone designed goal ownership, review, or stop conditions.

Tool reach is real architecture. It belongs in authority grants and acting steps. It does not, by itself, turn a skill into an agent or prove that a module owns an open goal.

Helpful context: Decide, perform, pursue separates acting (perform) from agency (pursue). What is an agent owns goals and loops. Five things called agent disambiguates market readings.

Reach is not the boundary

A cognitive unit may stay pure and return structured results without writing. A skill may act under grant as part of a known procedure. An agent may also act under grant while pursuing a goal. Action rights travel with authority in every case.

What distinguishes the agent from an acting skill is whether the component must decide what kind of work to undertake next, revise strategy from evidence, and judge when a goal is complete. The write itself does not settle that question. A module that posts to ten external systems every run may still be a skill if the same ten posts happen in the same order for every case, while a module that writes to one system may be an agent if it must first determine whether writing is appropriate based on evidence gathered during pursuit.

Invoice verification that posts an adjustment is still a skill if the procedure shape was known before the run. The write is a step inside a bounded capability, not proof that the module owns an open goal. Assembling a shopping list from an accepted plan may be deterministic perform work or an acting skill with explicit grants. Deciding whether the plan is ready to shop, and obtaining purchase approval when consequence requires it, belongs to the agent.

Where agency begins

Agency begins when evidence can change the shape of the work. The loop selects capabilities, observes results, updates working state, and chooses accept, patch, fetch, bridge, replan, ask, escalate, or stop. That transition ownership is where the cognitive unit ends and the agent begins.

In the Meal Companion, critique may reveal that Tuesday is impractical while variety is acceptable. An agent chooses local patch versus replan versus ask. An acting skill executes the chosen patch under grant after the agent accepts the transition. A fixed acting chain with no loop remains a pipeline or an acting skill depending on whether it carries a capability contract and procedure evaluation. Calling it an agent because it touches production systems is one of the five things called agent.

This distinction matters because losing it costs both sides. If every write creates an "agent," teams stop designing skills: contracts, procedure suites, seam tests, and recoverable side effects never get named. They also stop designing agents: stop conditions, authority ceilings, and trajectory evaluation never get named. Both objects degrade into capable scripts with marketing labels. Incidents become hard to triage because nobody knows whether failure was wrong judgment, wrong procedure, or wrong pursuit transition. Grants must travel with acting skills, and failure modes at the write boundary are skill-level concerns, distinct from a cognitive unit answering badly. See authority is granted.

In a skill, the answers vary, but the shape of the work largely does not. In an agent, the evidence can change the shape of the work.

Meal Companion and enterprise examples

After the agent accepts the weekly plan, grocery assembly may read endorsed household inventory and accepted meals, then produce a list artifact. That transform may be largely deterministic. If the skill also places orders under grant, procedure evaluation covers idempotency, rollback, and budget ceilings. The agent still owns whether shopping happens now versus after human review. Confusing list generation with plan acceptance is a classic perform-versus-pursue bug. Users receive groceries for a plan they never accepted, or the system never acts despite an accepted plan waiting.

Enterprise domains carry the same structure. Posting ledger adjustments, opening support tickets, or enqueueing fulfillment are acting steps that require grants and seam tests at the skill layer when the procedure is known. Owning SLA resolution for a ticket queue is pursuit, because the module must decide next work from evidence rather than execute a fixed acting sequence on every case.

Operations and grant design

cognitive units often remain sealed: structured answers without direct side effects. Acting writes frequently belong in deterministic code immediately after a cognitive unit returns, or in explicit acting steps declared in a skill procedure. That separation keeps judgment suites clean and makes side effects inspectable. It also prevents "the model posted it" from becoming an excuse for missing grant design. When a cognitive unit must act at level acting, purity is declared explicitly and evaluation binds accordingly.

Operations teams benefit when acting skills and pursuing agents carry different runbooks. Acting skill incidents ask whether grants, idempotency, and seam order held. Agent incidents ask whether transitions, stop rules, and working state were correct. Mixing those runbooks produces either overcautious humans who freeze all writes or undercautious systems that chase tool reach without goal review.

Grants belong beside acting steps the way API docs document scopes. A skill that posts ledger adjustments lists required grant, rollback behaviour, and idempotency keys. Security review then has concrete artifacts instead of vague scope. When grants are documented at the skill boundary, audit teams can verify that each write path has been reviewed without reading the cognitive unit templates inside, because the authority design is explicit in the procedure declaration rather than implicit in model behaviour.

From reach to discipline

Demo scripts that label every tool call an agent action deserve scrutiny. The question is which transitions required pursuit judgment before the write occurred. Procurement checklists that count tools instead of goals, stop rules, and grant design miss the point. When a vendor shows shopping-list writes, the question is who accepted the plan first. When a vendor shows autonomous ordering, the question is where escalation lives when payment terrain is contested.

Perform answers can vary while work shape stays stable. Pursuit answers can change which capabilities run next. Product copy mirrors the architecture distinction when it says the skill updates the list after acceptance and the agent decides acceptance. Users learn what the system owns when language matches boundaries. Incident retros tag acting skill failures separately from pursuit failures, because the remediation paths differ. Mixing them produces fixes that add more tools instead of better stop rules or better grants.

When product marketing asks for "agent" language, the productive negotiation is about which user-visible goal the system owns. If the answer is none, describing perform capabilities honestly ages better than borrowed hype.

What to do next

Acting skills separate from goal-owning agents on diagrams. Grants attach to acting steps, and writes evaluate at the skill level. Pursuit transitions, working state, and stop rules stay in agent definitions. The "it calls tools" test for agency dissolves once reach and ownership are distinguished.

See skill versus capability and an agent is mostly ordinary code.

Read next: Five things called agent.