An AI feature, an AI agent and an agentic system are not the same thing

“Agent” has become a convenient product word. It is also a poor basis for architecture or governance. A drafting assistant, an automated refund workflow and a collection of cooperating services may all be sold as agents, yet they create very different obligations.

The useful distinction is not how intelligent the interface appears. It is what happens between a request and an effect. An AI feature produces a bounded output within a workflow controlled elsewhere. An AI agent pursues a delegated goal through multiple decisions or actions. An agentic system is the whole operating arrangement around one or more agents: models, context, tools, permissions, state, verification, people and operational controls.

That classification should change the release question. A feature needs evidence that its output is fit for its intended use. An agent also needs evidence about action selection and stopping. An agentic system needs evidence that the end-to-end arrangement remains controlled when components fail, change or disagree.

Start with what can change in the world

The OECD definition of an AI system is deliberately technology-neutral: a machine-based system infers how to generate outputs that can influence physical or virtual environments, with varying levels of autonomy and adaptiveness. That definition is broad enough to include a scoring model, a content generator and a tool-using agent. It does not make them operationally equivalent.

A practical classification begins with the effect boundary:

Class	Typical effect	Who sequences the work?	Central assurance question
AI feature	Generates, classifies or recommends	User or conventional application	Is the output suitable and correctly presented?
AI agent	Chooses steps or tools to pursue a goal	Model-driven runtime within set limits	Does it choose, act, stop and escalate appropriately?
Agentic system	Coordinates agents, tools, state and people across a workflow	Distributed runtime and operating model	Is the whole action path controlled, observable and recoverable?

A feature can still be consequential. A diagnosis suggestion or credit-risk score can influence a high-impact decision without calling a tool. Conversely, a tightly bounded agent may perform low-consequence work. Classification is not a risk score. It tells the team what kind of system it is evaluating; consequence and exposure determine how much evidence is needed.

An AI feature stays inside someone else’s workflow

An AI feature has a defined input-output contract. It might summarise a case, extract fields from an invoice, rank search results or draft a response. The user or surrounding application decides when it runs, what happens next and whether its output becomes authoritative.

For a feature, the evidence should focus on the output and its use context:

• the intended task and excluded uses;
• representative input conditions and known edge cases;
• quality, error distribution and uncertainty;
• how the interface communicates that uncertainty;
• the human or rule that accepts, rejects or transforms the output; and
• changes in model, prompt, data or policy that require retesting.

Calling the feature an “assistant” does not add agency. If a person must press “send,” the system does not have messaging authority. But the human control is meaningful only if the person can inspect the proposed message, has time and competence to intervene, and is not being asked to approve hundreds of outputs reflexively.

An agent owns part of the sequence

An agent receives an objective and determines at least part of the path towards it. It may decompose work, select tools, interpret results, revise a plan, retry or ask for help. NIST describes today’s leading agent pattern as a general-purpose model embedded in software scaffolding that lets it manipulate tools and take actions beyond text output (NIST’s tool-use taxonomy).

The shift is not merely “more turns.” It is delegated discretion. Consider three support experiences:

1. A feature drafts a reply from the current ticket.
2. An agent retrieves order history, checks policy, proposes a remedy and asks an operator to approve it.
3. An agent selects and issues a refund, updates the account and sends the message within a delegated limit.

The second and third examples require evaluation of the trajectory, not only the final prose. Did the agent retrieve the correct record? Did it treat customer text as data rather than instruction? Did it use the right policy version? Did approval bind to the exact remedy? Did a retry duplicate the refund? A good-looking response cannot answer those questions.

An agent release therefore needs an action inventory: every operation the runtime can request, the permission it uses, the preconditions for execution, the expected postcondition and the safe response to an unknown result.

An agentic system includes everything that makes agency real

The model and its loop are not the whole product. A production system also contains identity, retrieval, credentials, tool adapters, durable state, queues, policy checks, logs, monitors, human review and incident procedures. Research on foundation-model agent architecture options similarly separates functional capabilities from design-time and runtime concerns; architecture choices affect qualities such as reliability, security and scalability.

Treating the agentic system as the unit of review prevents four common omissions:

• Authority disappears into the prompt. A model is told what it may do, but the tool endpoint does not enforce the boundary.
• Conversation is mistaken for state. The transcript says an action succeeded, while the business system shows it is pending or duplicated.
• Component tests substitute for workflow evidence. The model passes a benchmark and the API passes contract tests, but their combined failure modes remain untested.
• Operations arrive after release. Nobody owns a kill condition, degraded mode, rollback or investigation record.

The system boundary should extend to the authoritative external state that confirms an effect. If an agent submits a payment, the evidence path ends at the payment system’s durable status—not at the agent’s “done” message.

Classify each action path, not the whole brand

One product can contain all three classes. A procurement platform may offer a feature that summarises bids, an agent that assembles a comparison, and an agentic workflow that contacts approved suppliers and updates the sourcing system. Assigning one label to the platform hides where delegated authority begins.

Map each user-visible outcome through five questions:

1. What objective enters the system, and who sets it?
2. Which steps can the model choose or revise?
3. Which operations can read or change external state?
4. Which principal authorises each operation, under what limits?
5. What independent evidence confirms completion?

Then mark where a person makes a substantive decision. A person choosing among clear alternatives is different from a person clicking through a plan they cannot inspect. Human involvement changes the action path only when it changes the outcome or constrains authority.

The classification sets the minimum release evidence

The NIST Generative AI Profile treats risk management as a lifecycle activity spanning governance, mapping, measurement and management. Applied to this classification, the minimum evidence expands as discretion and system coupling expand.

For a feature, retain representative test cases, error analysis, interface review and change triggers. For an agent, add trajectory-level tests, tool-use policy checks, authorisation evidence, stopping and escalation tests, duplicate-effect protection and adversarial inputs. For an agentic system, add end-to-end state reconciliation, dependency failure tests, version manifests, operational thresholds, incident exercises and accountable owners.

This is not a maturity ladder in which every feature should become an agent. A bounded feature can be the better design when the next action is consequential, the workflow changes frequently, or success cannot be verified automatically. The label should describe the chosen delegation, not signal product ambition.

Make the release decision in system language

Before approving production use, replace “we are launching an agent” with a statement that can be tested:

The system may read these sources, propose these actions and execute these specific operations for this principal, within these limits. It must stop under these conditions, obtain approval for these effects and retain this evidence of what changed.

If the team cannot complete that sentence, it does not yet have a stable release scope. Narrow the system to recommendation or draft mode until the action boundary is enforceable and observable.

The durable distinction is simple. A feature contributes an output. An agent contributes decisions and actions. An agentic system is the socio-technical machinery that turns those decisions into controlled effects. Govern the last one, even when the product page talks only about the first two.