Five things called agent

A vendor demo ends with applause. The slide says "autonomous meal planning agent." In the hallway, two engineers compare notes. One built a chat wrapper that remembers last week's suggestions. The other built a loop that critiques plans, patches local weaknesses, and stops when the household accepts the week. Both call the result an agent. Both feel accurate. Both are about to join the same architecture review, and that meeting will go in circles unless someone names which reading of the word is actually on the table.

Helpful context: Why the words we have fail explains why mechanism vocabulary hides boundaries. Acting is not agency separates tool reach from pursuit. What is an agent is the canonical fifth reading.

Why the label alone reveals little

Vendor language treats "agent" as a feature flag. Enable tools, enable memory, enable autonomy, and the product earns the label. That checklist names reach, not architecture. It does not say who owns "done," whether the path may revise, or what must happen before a side effect runs. The word arrives overloaded from marketing, research papers, and framework documentation. It covers incompatible shapes: one tool call, a fixed prompt chain, chat continuity, unsupervised cross-app action, and a goal-owning module with working state, authority, and designed stopping.

Thoughtware uses the word narrowly, for the last shape only. That module owns a goal, runs through working state, delegates open judgments to cognitive units, invokes known work as Skills, and halts under designed stop conditions. The other four readings may be useful products. They are not that category. When a stakeholder says "we need an agent," the response that matters is classification, not enthusiasm. The question is not whether agents are trendy. The question is which shape is actually under discussion.

Five readings, one sentence each

The market uses "agent" for at least five distinct things. Each deserves its own architectural name in a Thoughtware conversation. The first reading is the calendar API demo: a model proposes a dinner and writes an event. Useful, bounded, and still not pursuit. The second is the embed-rank-display chain many teams ship first, a scripted sequence of prompts where steps are ordered but judgments may remain unnamed. The third is persistent chat that feels personal because last Tuesday's pasta suggestion still appears in context, continuity mistaken for architecture. The fourth is the grocery auto-order fantasy: action across apps without purchase approval, allergy enforcement, or escalation design. Only the fifth reading carries the obligations Thoughtware associates with serious agency: goal ownership, working state, authority, and stopping conditions.

Reading	Shape	Thoughtware term
Model plus tool	One tool call	Capability wrapped in a function, not goal ownership
Prompt chain	Scripted sequence	Skill or pipeline, judgments may be unnamed
Chatbot with memory	Conversation continuity	History without contracts is memory, not design
Autonomous workflow	Cross-app action	Capability without proving when to halt or escalate
Thoughtware agent	Goal-owning module	Composes cognitive units, Skills, code, and memory through working state, policies, authority, and stopping conditions

Many products labelled agents are acting Skills or pipelines. Tool use creates reach. Reach does not create an agent. The distinction becomes visible when something goes wrong: the first four readings have no designed answer for "what happens next when critique finds a weakness?" because nothing owns pursuit after the initial output returns.

Classify meal-planning products

Apply the five buckets to common meal-planning descriptions. The exercise takes minutes and prevents months of misfit architecture. A "chat that suggests dinners" falls into the chatbot-with-memory bucket, often missing an agent definition entirely. A "chain that embeds, ranks, and displays" is a prompt chain or pipeline packaged as a Skill. A "copilot that calls a calendar API" is model-plus-tool, capability without goal ownership. "Auto-orders groceries" is an autonomous workflow that needs authority and stop design before anyone should trust it. Only "iterates until plan accepted" matches the fifth reading, the Meal Planning Agent that owns plan acceptance, durable pursuit state, and a minimum sufficient loop deciding when the week is good enough to shop.

Product description	Bucket	Thoughtware term
"Chat that suggests dinners"	Chat with memory	Often missing agent definition
"Chain: embed, rank, display"	Prompt chain or pipeline	Skill or pipeline, not agent
"Copilot calls calendar API"	Model plus tool	Tool use without goal ownership
"Auto-orders groceries"	Autonomous workflow	Needs authority and stop design
"Iterates until plan accepted"	Thoughtware agent	Meal Planning Agent

Walk through the originating household sentence used across this collection: "Plan dinners for four people this week. Tuesday and Thursday are busy. Use the spinach before Wednesday and avoid meals we ate last week." A chat-with-memory product might answer once with seven recipe names. A prompt chain might embed constraints, rank candidates, and format a table. An autonomous workflow might push items to a cart API. A Thoughtware agent interprets the week, composes provisionally, critiques, patches local weaknesses, asks targeted questions when preference is missing, and stops when exact checks pass and further iteration has little expected value. Same user sentence. Five different architectural commitments.

What the fifth reading demands

If the fifth reading is intended, four objects must exist before anyone opens an IDE. The first is a goal: what does "done" mean? For the Meal Companion, that is an accepted weekly dinner plan, not a fluent paragraph about dinners. The second is working state: what must persist across iterations beyond chat history? Interpreted week, plan version, accepted meals, open gaps. The third is authority: what may the module propose versus execute? Purchase requires approval. Allergy overrides are forbidden. The fourth is stop conditions: when does pursuit end successfully, escalate, or ask?

Without those objects, the conversation is capability theatre. The team is debating models and tools while goal ownership still floats in a system prompt. The exercise of demanding them is the fastest way to separate genuine fifth-reading intent from second- or third-reading products wearing the agent label for marketing effect.

Ask which reading is meant before debating implementation.

Introduction to Thoughtware Ch. 19

If the first four readings are sufficient for the product, that clarity is equally valuable. A strong Skill or pipeline beats a mislabelled agent. Pipelines are not agents. When the fixed path is a named capability with a contract, package it as a Skill instead of borrowing agency language.

Common classification mistakes

Teams mislabel products for predictable reasons. Marketing wants the agent word. Demos conflate tool use with autonomy. Memory features inherit the label because persistence feels like pursuit. Four patterns appear repeatedly. A goal that lives in prose only, such as "You are a helpful meal planning assistant," is not goal ownership because goals belong in agent definitions with stop rules attached. A loop without review, where generation repeats without an explicit transition such as accept, patch, fetch, ask, escalate, or stop, is repetition rather than an agent loop. Side effects without grants, where writing to a calendar or cart proves reach but not architecture, means authority is still missing. Judgments without names, where nobody can point to AssessMealPracticality or its equivalent, means the chain still hides decisions inside prompts.

Classification is not pedantry. It determines whether the team designs procedure evaluation, trajectory evaluation, or neither. It also changes staffing: pipeline work needs procedure owners and stage-level suites, Skill work needs capability contracts and seam tests, and agent work needs pursuit policy, working state design, and trajectory evaluation. Teams that skip classification often hire "agent engineers" who spend quarters tuning prompts for shapes that should have been Skills or cognitive units in week two.

What to do next

The bucket pass takes thirty minutes and changes every subsequent sprint. List every "agent" on the roadmap and assign one of the five readings. For anything in the fifth bucket, write the goal, working state, authority ceiling, and stop conditions before selecting a model. For anything in the first four buckets, pick the correct Thoughtware name: Skill, pipeline, cognitive unit, or tool adapter. Open the next review by stating the bucket, not the vendor feature list. Record the classification in the architecture doc so future hires inherit it rather than rediscovering it from demo titles.

See an agent is mostly ordinary code, agents own goals, and pipelines are not agents.

Read next: An agent is mostly ordinary code.