Agents own goals, not every judgment

A product spec opens with a system prompt: "You are a helpful meal planning assistant. Be proactive. Use tools wisely." Six pages later, buried in a tool list, someone mentions "accepted plan." Nobody owns "done" as an architectural object. Judgments scatter across prompts and adapters. When critique finds a weakness, nobody can say whether the module should patch, replan, or ask the household. That spec smell is common. Teams borrow agent language while leaving goal ownership in prose.

Helpful context: What is an agent defines goal ownership and loops. What is a skill performs known capabilities. Decide, perform, pursue names the three responsibilities.

Three levels, one household

Thoughtware assigns goals to agents, procedures to Skills, judgments to cognitive units. The three-level stack organizes reviews and shows where new work belongs. Take the Weekly Meal Companion. The household wants a practical week, not a chat about recipes.

Layer	Owns	Must not silently absorb
Agent	Goal, loop, stop, delegation	Individual field judgments
Skill	Known capability	Goal pursuit across changing strategy
cognitive unit	One open decision	Neighbouring judgments for convenience

The agent owns producing an accepted weekly dinner plan through the minimum sufficient loop. The Compose Weekly Plan Skill performs known composition work. JudgeWeekdayPracticality owns one judgment: whether a candidate fits a busy evening. Each layer answers a different failure question. Agent failure asks whether the goal was achieved through an acceptable trajectory. Skill failure asks whether the capability ran correctly. cognitive unit failure asks whether one decision met its contract. Those three failure questions also determine who gets paged during an incident: a cognitive unit failure pages the judgment owner, a skill failure pages the procedure owner, and an agent failure pages the product team responsible for pursuit policy.

Agents own goals. Skills own responsibilities. cognitive units own single judgments.

Thoughtware White Paper Pr. 5

Meal Companion decomposition

Walk the originating sentence: "Plan dinners for four people this week. Tuesday and Thursday are busy. Use the spinach before Wednesday and avoid meals we ate last week." The goal at agent level is to produce an accepted weekly dinner plan under household authority and exact checks. Skill responsibilities include interpreting the request into a week representation, composing a provisional plan, and running a critique pass when the procedure shape is known before execution. cognitive unit judgments cover weekday practicality, weekly variety, household fit, and local repair quality.

CritiquePlan identifies weaknesses. Only the agent chooses patch versus replan versus ask. That transition is pursuit. Critique performed its judgment. Pursuit policy lives elsewhere by design. See where the cognitive unit ends and the agent begins. Deterministic code sits beside all three levels: schema validation, allergy enforcement, portion math, transactional patching, purchase approval. Code neither owns open judgment nor substitutes for goal declaration.

Why goals must not float in prompts

Prompt-only goals feel fast in week one. They degrade quickly. Prompts grow. Tool lists expand. New engineers cannot find "done." Evaluation attaches to fluency because nothing else has an address. An explicit goal object changes design conversations. You can ask whether the plan is useful, whether exact checks passed, whether authority was respected, and whether another iteration has expected value. Those are stop questions. They belong to pursuit, not to any single cognitive unit inside the loop. The degradation is observable in practice: after three months of prompt edits, the original goal sentence has been buried under tool descriptions and style instructions, and nobody remembers whether acceptance was ever formally defined or merely assumed from the first demo.

Invoice intake parallels the meal case at scale. Field cognitive units decide interpretations. An extraction Skill performs retrieve, validate, persist. Only a goal-owning module pursues clearing a queue with review and escalation when cases diverge. The Skill does not substitute for queue clearance as a goal. When goals float in prompts, teams default to fluency review. That misses the most important failures: wrong stop, missing escalation, silent authority breach. Explicit goals give evaluation a spine.

From spec document to agent definition

The translation from product language to implementable objects matters for every team that takes the fifth reading of "agent" seriously. A spec might say "help households plan dinners." The agent definition should say: goal is accepted weekly dinner plan, boundary excludes medical diagnosis and unsanctioned purchase, stop when minimum sufficient loop checks pass, escalate when unfamiliar medical restrictions appear. That translation belongs in the same document as Skill imports and cognitive unit dependencies.

When product and engineering share the goal object, debates about model choice stay inside bounded calls instead of absorbing pursuit policy. Goals without boundaries invite scope creep. The Meal Companion plans household dinners. It does not diagnose conditions, override allergies, or purchase without approval. Boundaries make refusals testable during evaluation instead of debatable after an incident. A boundary like "does not provide medical nutrition guidance" turns an ambiguous policy question into a concrete test case: does the system escalate or refuse when a request implies clinical dietary assessment?

Common mistakes

The most damaging pattern is a mega-prompt as agent: one call decides the whole week, hiding several judgments inside a fake cognitive unit. See not a composite cognitive units. A close second is a Skill with smuggled pursuit, a procedure that silently decides when the queue is "good enough" and has absorbed agent work. Package pursuit explicitly or shrink the Skill boundary. Third, an agent that rediscovers settled work each lap should invoke a Skill instead. Agents spend loops on uncertainty, not on re-deriving known procedures. Finally, a goal without boundary such as "help with meals" invites scope creep into medical diet advice. Pair goals with boundaries the product will refuse.

Evaluation follows the stack

Goal ownership also determines what you evaluate. Agent evaluation asks whether pursuit reached an acceptable outcome through a defensible trajectory. Skill evaluation asks whether the procedure ran correctly across seams. cognitive unit evaluation asks whether one judgment met its contract under suite coverage. When goals float in prompts, teams default to fluency review and miss the structural failures.

The connection between goal ownership and evaluation is the line between perform and pursue. Skills may act on the world under grant. Agents decide what work should happen next when evidence changes. Acting is not agency when a write tempts the team to skip this distinction. Pipelines are not agents because fixed paths do not own goals. They end when the procedure ends. Agents stop when outcome, checks, authority, and sufficiency say so. The evaluation implication is direct: if the system has no declared goal, evaluators cannot measure trajectory quality because there is no target against which to assess whether the pursuit was defensible or wasteful.

A goal sentence that fits on one line forces the team to say what success means before naming tools.

What to do next

The three-level stack becomes actionable once the goal is a sentence a product manager and an engineer would interpret the same way. List every judgment in the flow and assign each to a cognitive unit or admit it is still unnamed debt. Move known procedures into Skills the agent calls. Attach stop conditions to the goal, then read stop conditions as design for the design vocabulary around stopping. Ask each week: can every engineer point to the goal object in code? If not, goal ownership still lives in prose, and features built on floating goals inherit silent scope creep.

See the ten principles, an agent is mostly ordinary code, and what is an agent.

Read next: Pipelines are not agents.