Where the cognitive unit ends and the agent begins

Integration arguments usually land on one question: should this be a cognitive unit, a Skill, or the agent? Marketing labels and demo convenience give wrong answers. A vendor "agent" button tempts teams to put pursuit inside a prompt. An impressive single call tempts teams to stretch a cognitive unit into a compound. Thoughtware derives the boundary from responsibility: who owns the judgment, who owns the procedure, and who decides what happens next when evidence arrives.

Helpful context: This page assumes familiarity with what is a cognitive unit, what is a skill, and what is an agent. It extends them with cognitive orchestration, the choreography that connects the three objects toward a goal.

Two questions on every step

Two questions resolve most boundary disputes. The first is "who owns this judgment?" which assigns a cognitive unit. The second is "who decides what happens next?" which assigns the agent. Skills sit between. They perform known work the agent invokes. They do not own the goal. They do not choose patch versus replan versus ask after critique returns. When both questions point to the same box, the boundary has collapsed. That collapse is the most common architectural defect in agent projects. The collapse manifests as a single callable that both answers a point question and determines the shape of subsequent work, making it impossible to evaluate judgment quality independently from pursuit quality.

Meal Companion walkthrough

CritiquePlan returns structured weaknesses. That is cognitive unit work. The judgment is complete when the result returns. The agent then decides: PATCH via RecommendMealSubstitution when one weakness is local, REPLAN when the week representation fails, ASK when household preference is missing, or STOP when the minimum sufficient loop is satisfied. The cognitive unit does not choose patch versus replan. That transition is pursuit. Blurring the line creates compounds that cannot be evaluated or substituted cleanly.

Follow one more beat. RecommendMealSubstitution proposes a local repair. Deterministic code validates schema and reapplies allergy checks. JudgeLocalRepairQuality may assess whether the patch resolves the weakness while preserving accepted work. The agent still owns whether to accept the patch, fetch more knowledge, or escalate when terrain exceeds authority. The pattern is consistent: cognitive units return bounded results, the deterministic shell enforces exact constraints, and the agent holds pursuit policy.

Why the middle layer matters

Without Skills, teams stretch cognitive units into compounds or stretch agents into rediscovery machines. A multi-judgment procedure with a known shape is not a larger cognitive unit. See not a composite cognitive units. A settled path is not a loop that must keep discovering itself. The Compose Weekly Plan Skill might call GenerateCandidates, invoke ComposeWeek, and run deterministic validators in a known order. Answers vary by household and week. The procedure shape largely does not. That is perform work the agent invokes, not pursuit the Skill smuggles.

Without agents, nobody owns stop conditions, escalation, or strategy revision when critique fails. Skills return capability outputs. Agents decide whether the goal is sufficiently met to shop, ask, or escalate. The same pattern appears in the invoice domain. Field cognitive units decide interpretations. An extraction Skill performs retrieve, validate, persist. The goal-owning module pursues queue clearance with review when cases diverge. The same two questions resolve arguments: who owns the field judgment, who decides the next step after verification returns.

Pipeline confusion at the boundary

A fixed sequence with no stop decision may still be only a pipeline. When that work is a named capability with procedure evaluation, package it as a Skill. Promote to an agent when case shape requires discovery, revision, and designed stopping. Acting is not agency when side effects tempt the team to label a Skill as an agent. Writes prove reach. Pursuit requires goal ownership and review policy.

Decision tree for reviews

When someone proposes a new box, walking the tree resolves the argument. If it owns one open judgment, assign a cognitive unit. If the procedure shape is known before run, assign a Skill, possibly with acting steps. If it owns the goal and loop policy, assign an agent. If none of these fit, the work is still hidden inside a prompt and naming it is progress. This tree rarely takes more than twenty minutes in a review session. It prevents compound debt that surfaces only in production.

Common boundary mistakes

Critique plus strategy in one call is the first mistake. Critique returns weaknesses. Strategy chooses among patch, replan, and ask. They belong in separate responsibilities. An agent that re-derives composition every lap should invoke the Compose Weekly Plan Skill when the path is settled. A Skill that silently decides acceptance has absorbed pursuit work and belongs in the agent instead. A cognitive unit that posts purchases conflates acting with judging. Acting may belong in a Skill under grant. Goal-level purchase approval still belongs to agent policy and human authority.

Enterprise conversations say "capability" loosely. Skill versus capability maps informal claims to architectural packages. This page maps those packages to pursuit versus judgment versus procedure. The boundary discussion is also incomplete without the deterministic shell. Allergy enforcement, schema validation, portion math, and purchase approval live in code that orchestration invokes at defined points. cognitive units propose. Code permits or denies world effects. When integration arguments stall, drawing the shell as a lane beside the agent loop clarifies which steps require exact enforcement before review may continue. That drawing exercise typically resolves disputes within minutes because the shell lane makes visible which steps are non-negotiable gates and which steps are open judgment, removing the ambiguity that fuels prolonged design meetings.

Escalation as a boundary outcome

Escalation is a valid loop outcome. When terrain exceeds authority or consequence, the agent stops pursuing autonomously and records why. Treating escalation as failure encourages silent guessing. Treating it as architecture preserves trust. Meal planning escalates when medical interpretation would be required. Invoice intake escalates when materiality exceeds automated approval. The pattern repeats across domains.

Pair boundary reviews with contract reviews. Every cognitive unit box should link to a contract and suite reference. Every Skill box should link to procedure evaluation. Every agent box should link to goal, stop rules, and working state schema. Missing links signal unnamed work. The pairing prevents "we agreed on the diagram" meetings that never produce testable artifacts. When the team maintains both the boundary diagram and the linked contracts as living documents, new features integrate cleanly because the design vocabulary already exists for naming where the new work belongs and which existing boundaries it touches.

The boundary review pairs a cognitive unit owner with an agent owner so neither side assumes the other absorbed silent judgments.

What to do next

Take one flow from the roadmap and label every step with cognitive unit, Skill, agent, or code. Split any box that answers both the judgment and the next-step questions. Move settled paths into Skills the agent calls. Update diagrams when splits occur, because outdated diagrams recreate the same integration arguments every quarter. Revisit disputed boxes whenever a feature adds a new side effect or memory write, since side effects are the fastest way compounds return.

See two different boundaries, decide, perform, pursue, and five things called agent.

Read next: Skill versus capability.