FAQs

Software that uses a model to repeatedly decide among actions (often tools), apply them, observe results, and continue until a goal or bound is reached.

A chatbot optimizes for conversational replies. An agent optimizes for goal completion through actions. A chatbot may call a tool once under user direction; an agent may take many internal steps before answering.

No. ReAct is one popular loop style (reason, act, observe). Plan-and-execute, tool-calling loops without free-text reasoning, and multi-agent handoffs are also agentic when they preserve decide-act feedback.

No. Short tasks can run entirely from the current context window. Memory becomes important when work spans sessions, users, or long horizons that exceed a single context budget.

Classical agents can be fully rule-based. In today's product language, "AI agent" usually implies an LLM (or similar model) in the decision seat. Rules alone are automation, not an LLM agent.

Retrieval is often a tool inside the loop. Plain retrieve-then-generate with no branching is a pipeline. When the model decides whether to retrieve, reformulate, or answer, the system becomes agentic RAG.

At minimum: tool schemas, a loop that feeds observations back, and a hard stop (max turns or budget). Without those three, you have a demo completion with side effects.

Marketing stretches the term to any AI feature. Engineering needs a narrower meaning tied to action selection and loops. Prefer describing autonomy level and tool rights over arguing labels.

Function calling is the structured interface for actions. Agency appears when the system can call tools across multiple turns based on prior results, not merely emit one structured payload.

If you can write a reliable flowchart of every step, a script or workflow engine will usually be cheaper, faster, and easier to test than a free-form agent.

Anything the tools can read or change: files, browsers, APIs, databases, tickets, calendars, or chat platforms. The environment is defined by tool permissions, not by a physical world.

They scale it. Each agent still perceives, decides, and acts. The new problems are handoff protocols, shared state, and who owns the final answer.

Higher autonomy expands the set of actions the system can take without asking. Risk scales with irreversibility and blast radius of those actions, not with model size alone.

Task success under varied paths, average tool calls per success, cost and latency distributions, rate of stop-condition hits, and human intervention rate - not only final answer quality.

Prefer the term that sets correct expectations for autonomy and side effects. If users must approve every write, "copilot" or "assistant" is often more honest than "autonomous agent."

Yes. Share tools and models, then vary the outer control loop and UX: single-shot reply, suggestion-with-accept, or multi-turn tool loop with budgets.

Product modes differ. Plain chat is chatbot/assistant behavior. Features that run multi-step tool use under a goal behave agentically. Classify the mode, not the brand.

Usually marketing for higher-autonomy agents with business tools (CRM, email, docs). Engineer them as agents with strong identity, audit, and approval design.

Usually no. Retrieve-then-answer without action selection is a grounded chatbot/assistant. It becomes agentic if the model decides among tools and multi-step strategies.

They want labor reduction (agent narrative) but risk controls (copilot reality). Ship supervised autonomy first; expand write rights as eval proves out.

Often yes for sub-tasks (run tests, fetch docs). The defining trait is that the human remains responsible for applying outcomes in the main workflow.

Describe capabilities: "multi-turn tool-using agent with human approval on payments," not only "AI assistant." Precision helps ops and security reviews.

Chatbots: resolution/deflection and satisfaction. Copilots: accept/edit rates. Agents: end-to-end task success and cost per success under stop conditions.

Voice is a modality. The same four control patterns apply; latency and confirmation UX are stricter because speech errors and ambient context are common.

When it routinely performs multi-step decide-act-observe cycles toward a goal with tools, rather than only answering or drafting in a single response.

Yes when tool rights and data access differ. A drafting copilot and a refund-issuing agent need different audit trails, access reviews, and incident playbooks.

Often it means a workflow engine with some LLM-chosen branches. That can be partially agentic without being a free-form autonomous agent.

Copilot-style: strong suggestions, human apply, read-mostly tools. Add agent loops where multi-step recovery clearly beats a script.

In practice, agentic describes behavior or architecture (loops, tools, initiative). Agent names the system role. People use them loosely; define primitives in writing.

Academic agent definitions are older. The 2025-2026 wave is specifically LLM-centered tool loops productized at scale.

Classic automation follows predetermined rules. Agentic systems choose among actions under uncertainty using model judgment inside constraints.

Not by default. Retrieve-then-generate is a pipeline. It becomes agentic when the model decides whether and how to retrieve, retry, or switch tools.

No. A small loop with tools and max turns is agentic. Frameworks help with state, streaming, and multi-actor patterns as complexity grows.

Demand a diagram of tools, autonomy level, stop conditions, eval plan, and data flows. Reject pure adjective claims.

Reliable structured tool interfaces removed fragile "parse the model's free text for actions" hacks and made multi-step loops operable in production.

No. Single-agent loops are agentic. Multi-agent is an organizational pattern on top.

MCP standardizes how hosts discover and call tools/context sources. It supports agentic systems but does not by itself make a product an agent.

Concrete answers on action space, observability, budgets, and human gates - not only model names.

Maybe as a fashion term. The underlying loop-and-tools pattern will remain even if vocabulary shifts again.

Add a definition to your eng glossary and require autonomy level + tool list on any ticket titled "agentic."

No. Master agent loop, tool call, observation, stopping condition, context window, and trace first.

Mostly naming. Function calling is the common API phrase; tool use is the broader product phrase. Same idea.

State is whatever the runtime tracks for the current run. Memory often implies durable or retrieved knowledge beyond the raw transcript.

RAG is one grounding method. Tools (SQL, calculators, browsers) also ground actions in non-parametric evidence.

Rarely. Without action selection over an environment, you usually have chained generation, not an agent.

Turn index, model id, prompts or prompt hashes, tool name/args, observation summary, latency, token counts, stop reason.

Plan-and-execute drafts a multi-step plan up front; ReAct chooses the next action after each observation.

It is the set of real-world powers the agent has. Shrink it before you scale autonomy.

No. Tokens also bound how much history, tool output, and retrieved text fit in context.

This page plus a single traced demo run. Terms stick when tied to a real trajectory.

Make a one-page glossary in your repo: vendor name → term above → your implementation class/module.

Prompt is text to the model. Policy includes prompts plus hard runtime rules the model cannot override (tool denials, budgets).

Treat 1, 8, and 10 as mandatory. If 2 is true (path fully known), stop and build a workflow instead of forcing an agent.

You can spike, but do not call it production-ready. Habit 10 is the launch gate, not a research nice-to-have.

Ship a supervised, narrow slice that meets the checklist. Rename marketing later if needed; do not expand write tools to match the press release.

It may be the right product. Call it tool-augmented completion or Level 1 autonomy so ops expectations stay honest.

Apply them per agent and to the orchestrator. Multi-agent multiplies cost and failure modes; it does not relax stop conditions or evals.

A one-page ADR or design brief: goal, autonomy level, tools, budgets, eval set, escalation owner.

After incidents, tool changes, and quarterly reviews. Autonomy should be able to decrease.

They change implementation speed, not fitness. A framework without habits 8-10 still yields fragile agents.

A chatbot with extra marketing and one brittle integration, no traces, and no success metric beyond "feels smart."

Multi-step work with stable tools, automatic or cheap verification, acceptable latency, and a team willing to operate traces and budgets.

No. Pair PM + eng + security for write tools. Habit 7 especially needs shared ownership.

Loops, architectures, and model choice assume you already passed problem fit. Skipping this list is the root cause of many later "runaway agent" fires.