Thoughtware

Agents

A goal-oriented module with working state, loop, authority, and stopping conditions, narrower than common usage.

9 min read

Cover for Agents

Someone must receive the household request, decide which judgments are needed, preserve what has already been learned during the run, respond when critique exposes a gap, and determine when the plan is good enough to shop. That responsibility belongs to an agent, not a longer prompt, not a larger skill, and not a marketing label for any model that can call tools.

Vendor demos collapse every tool-using model into "agents." Thoughtware uses the word narrowly: a goal-oriented module with working state, loop policy, authority, and stopping conditions. An agent is ordinary software that pursues a declared outcome through explicit transitions, not an artificial person with preferences.

Helpful context: Five things called agent disambiguates market language. Decide, perform, pursue places agents in the pursue role. What is a skill performs known procedures the agent invokes. This page is the canonical agent definition.

Goal, loop, delegation

Three parts define an agent in specs.

Goal ownership declares what "done" means until completion or escalation. In the Meal Companion the goal is an accepted weekly dinner plan through the minimum sufficient loop. The goal sentence is stable across runs even when the path varies.

The loop plans, acts, observes, reviews, and revises with explicit transitions. See the agent loop. Each material step ends in a named transition, not another generation pass. Accept, patch, replan, ask, escalate, and stop are design vocabulary, not emergent behaviour.

Delegation keeps open judgments in cognitive units, known procedures in skills, and exact work in deterministic code. The agent orchestrates. It does not absorb every judgment into its loop body.

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

Thoughtware White Paper · Pr. 5

Read more: Agents own goals, not every judgment.

The agent is ordinary code

An agent is mostly ordinary code: state machine, policies, budgets, gates, with cognition as bounded dependencies. The loop is designed to be boring. The judgments are designed to be pointable. See an agent is mostly ordinary code. Fluency is not architecture. A readable transcript does not prove goal ownership. Tool access does not prove review design. The implementation test is whether working state can be inspected, the current pursuit phase named, and the stop rule that fired pointed to.

A fixed sequence with no stop decision is a pipeline, not an agent. When that sequence is a named capability, it belongs in a skill. Promotion to an agent happens when case shape requires discovery, revision, and designed stopping.

This distinction also separates the agent definition from a running instance. The agent definition holds goals, imports, authority ceilings, and stop rules. It does not hold one run's transient guesses or working artifacts. Instance working state holds current pursuit progress: accepted partial results, open gaps, last critique outcome, and budget consumed. It is ephemeral by design. The transcript records what was said, but it is not what currently matters for the goal. Mixing these layers lets a temporary correction rewrite permanent behaviour, or stores working state as though it were endorsed knowledge. Agents read endorsed knowledge. They do not treat every intermediate guess as belief. The practical consequence of this layering is that two runs of the same agent definition may follow entirely different trajectories while sharing the same goal, stop rules, and authority ceiling, because working state varies with household context while the definition remains stable across deployments.

Meal Planning Agent, one iteration

Working state holds the interpreted week, provisional plan, accepted meals, and open gaps. One iteration might proceed as follows.

The agent calls the Compose Weekly Plan skill to perform provisional assembly. It invokes JudgeWeekdayPracticality from the judge library so a named cognitive units decides practical fit across the schedule. Critique returns structured weaknesses. The agent chooses among transitions. On PATCH, it calls RecommendMealSubstitution and lets deterministic code validate and apply the patch. On ASK, it surfaces a targeted question when authority or terrain requires human leadership.

CritiquePlan returns weaknesses. That is a cognitive unit result. The agent decides patch versus replan versus ask. That boundary is where the cognitive unit ends and the agent begins. The iteration ends when the minimum sufficient loop is met, or when stop rules require escalation.

PlanActObserveReviewRevise

Each material step ends in an explicit transition, not another generation pass.

Stop conditions and authority

Serious agents halt when the goal is met, budget is spent, confidence is too low for the consequence, policy is violated, or escalation is required. Continuing because more generation feels safer than stopping is immaturity. See stop conditions as design. Stop design belongs in the agent definition alongside the goal sentence. Operators recognize why a run ended without reading the full transcript. Evaluators score trajectories and downstream consequence alongside leaf cognitive unit scores.

Authority ceilings belong in the agent definition next to the goal. An agent that can recommend meals but cannot purchase without grant encodes that separation in loop transitions, not in prompt pleading. The ESCALATE path deserves explicit design. Many agent designs assume happy paths until production discovers contested terrain. Escalation is a success outcome when grant and consequence require human leadership.

Agents read endorsed knowledge and write working state. Transcript fluency is not belief update. A household correction during one run belongs in working state until review accepts it for endorsement. Working state fields like accepted_meals, open_gaps, and last_critique_outcome belong in specs. Operators debugging pursuit need state snapshots, not chat scrollback.

What agents do not own

Agents do not own every open judgment inline. Judgments that recur across products belong in cognitive units and libraries. Agents do not re-implement known procedures that already deserve skill names. Rediscovery on every run hides procedure evidence and duplicates seam logic. Reach is not agency: writing to the shopping list may be perform work inside an acting skill after the agent has accepted the plan. See acting is not agency.

Agents may be private to one product or shared as patterns across a portfolio. What remains consistent is the separation of goal ownership from perform work. Two meal planners can share skills and cognitive units while pursuing different stop rules under different authority regimes. A household product may stop after one critique pass while a catering service product loops through multiple rounds because commercial consequence is higher. Agents also connect to trust posture. An agent that cannot escalate, abstain, or ask targeted questions is pretending certainty the terrain does not support. See recovery is part of trust.

Agent definitions that list stop conditions before launch prevent infinite loops from being discovered first in household support queues. Stop conditions belong in the definition document, not in post-incident runbooks alone. The same stop list should appear in eval scenarios for the agent trajectory.

What to do next

An agent definition starts with the goal sentence in one line, stop conditions with named triggers, skills the agent may call for perform work, and cognitive units by name for decide work. Working state fields distinguish accepted partial results from open gaps. Trajectory evaluation separates from leaf scores, because a run can execute excellent cognitive units and still fail the goal when the loop never patches a known weakness.

See evaluation and the Thoughtware system.

Read next: A skill may contain cognition.