What Is Agentic AI?

Agentic AI is not simply a chatbot with a longer prompt. An agentic system gives a model control over at least part of a task’s sequence. The model can observe the current state, select an allowed action, inspect the result, and choose what happens next.

That distinction matters more than whether the interface looks conversational. A fixed application that always classifies a request, retrieves three documents, and drafts a reply is a model-powered workflow. A system that decides whether retrieval is needed, changes its query after weak evidence, chooses between tools, and stops when a defined condition is satisfied contains agentic behavior.

Autonomy is therefore not binary. One system may choose search queries while requiring approval for every write. Another may autonomously update reversible labels but only draft customer messages. Describe autonomy per capability, action, and environment rather than labeling the entire product “an agent.”

A production agent is a control loop surrounded by ordinary software. The model interprets goals and proposes next actions. The application remains responsible for identity, authorization, schemas, budgets, retries, state transitions, audit records, and irreversible-action checks.

Six components determine behavior:

1. Goal and task contract. The system needs a bounded job, supported inputs, excluded cases, and observable completion condition.
2. Model. The model interprets ambiguous information and selects among allowed actions. Its output is a proposal, not authority.
3. Tools. Narrow domain functions provide data or perform actions. Tool execution happens outside the model.
4. State. Confirmed facts, open questions, previous actions, approvals, and remaining limits must survive across steps.
5. Control plane. Deterministic code validates arguments, permissions, budgets, destinations, and postconditions.
6. Evaluation and operations. Teams need representative tests, traces, alerts, escalation, recovery, and change review.

Completion must be external to the model’s confidence. A coding agent completes when relevant checks pass and a reviewable change exists. A support agent completes when the answer is supported by current account and policy evidence. A model saying “done” is only another claim to verify.

Good agent use cases combine four properties.

The path varies. Current evidence changes what should happen next. Research, investigation, exception handling, and maintenance often have this shape. If every branch can be enumerated economically, a deterministic workflow is easier to test and operate.

The systems are accessible. The agent needs authoritative data and narrow tools. A compelling model cannot compensate for missing identity, unreliable records, or a legacy system that exposes only broad administrator access.

The outcome is verifiable. Strong tasks finish with tests, record state, source-backed claims, policy checks, or structured human confirmation. Purely subjective outcomes are harder to improve because success cannot be distinguished from persuasion.

The downside is bounded. Early capabilities should be read-only, assistive, reversible, approval-gated, or constrained by amount, recipient, data class, and environment. More authority should follow evidence from the exact task—not general confidence in the product.

Do not use an agent for exact arithmetic, simple lookups, known routing, access control, or an irreversible high-stakes decision with weak feedback. Ordinary code, search, a form, or a model-powered workflow may be the better product.

Consider a support agent investigating a delayed order. It receives an authenticated customer and order identifier. It reads the commerce system, checks the carrier, sees contradictory scans, retrieves the controlling delivery policy, and prepares the remedies available for that account state.

The variable investigation path is a reasonable place for agent judgment. The evidence is inspectable, and read calls are low consequence. Issuing a large refund is different: it changes financial state and may be difficult to reverse. The system can prepare an exact proposal, but a person or trusted policy service must authorize execution.

Useful terminal states might be:

• completed: the current status and remedies are supported by account, carrier, and policy evidence.
• needs_input: a stable order identifier or required customer confirmation is missing.
• needs_approval: a specific refund proposal is ready for an authorized reviewer.
• denied: the authenticated actor lacks access to the order or requested action.
• exhausted: the investigation reached its retry, time, or cost limit.
• failed: a required system is unavailable and no safe resolution is possible.

This vocabulary prevents escalation from looking like failure and prevents a fluent explanation from being mistaken for a completed external action.