What Do People Mean When They Say “AI Agent” or “Agentic”?

The word “agent” is becoming one of those terms that gets used before people have agreed on what it means.

That is not necessarily a problem. New categories often start with loose language. The issue is that “AI agent” can refer to several different things at once: a chatbot with tools, a workflow automation, a planner, a software process that runs on a schedule, a multi-step reasoning loop, a system that can take actions, or a collection of specialized AI roles working together.

Those are not the same thing.

The reason I’m putting this here is that I want better language for the conversation. When someone says they want to build something “agentic,” or that a product has “AI agents,” I want to get to the useful part of the conversation faster.

The useful question is usually not:

Is this an agent?

The better question is:

Which parts of agent-like behavior are we actually talking about?

This page is my attempt to decompose the term into separate axes. The goal is to make the structure visible so that a vague conversation can turn into a practical one.

If someone sends me a product, proposal, architecture, or idea and describes it as “agentic,” these are the dimensions I want to clarify.

A Practical Framework for Understanding AI Agents

An “AI agent” is usually not one thing. It is usually a bundle of design choices across several separate dimensions.

Some systems are agentic because they run in a loop. Some are agentic because they use tools. Some are agentic because they act without a person clicking every button. Some are agentic because they maintain memory over time. Some are agentic because they can plan, evaluate progress, and change direction.

Those are different mechanisms.

The point is not to create a perfect academic definition. The point is to separate the parts well enough that we can talk clearly about what a system can actually do.

1. The Invocation Model: One Response or Ongoing Loop

This axis describes whether the system responds once or keeps operating through multiple steps.

Possible names for this axis

• Invocation Model
• Control Loop Model
• Run Pattern
• Execution Loop
• One-Shot vs. Iterative Behavior

What this means

At the simplest level, an AI system receives input and produces output.

That may be enough. A user asks a question, the model answers, and the interaction ends.

But many things called “agents” do more than that. They run a loop. They observe the current state, decide what to do next, take an action, inspect the result, and continue.

A simple version looks like this:

Observe state
Decide next step
Take action
Read result
Update state
Repeat until done

Clarifying question

When you say “agent,” do you mean a one-time AI response, or a system that keeps running through a loop until some condition is met?

Examples

Less agentic

User asks: “Summarize this document.”
AI returns one summary.
Process ends.

More agentic

AI reads a Confluence space.
Finds pages with missing structure.
Suggests updates.
Applies approved changes.
Checks for broken links.
Creates follow-up tasks.
Repeats next week.

The second system is more agentic because it has an operating loop.

2. The Action Model: Text Generator or Tool-Using System

This axis describes whether the system only produces language or can take action through tools.

Possible names for this axis

• Action Model
• Tool Use Capability
• Actuation Layer
• External Action Capability
• Read/Write Interface

What this means

A language model by itself generates text.

An agentic system often connects that model to tools, APIs, databases, files, browsers, calendars, email systems, CRMs, Jira, Confluence, Slack, code execution environments, or other systems.

This distinction matters because tool access changes the nature of the system.

A model that says:

You should create a Jira ticket

is different from a system that can actually create the Jira ticket.

A model that says:

This Confluence page should be reorganized

is different from a system that can read the page, draft an update, submit it for approval, and then write the approved version back.

Clarifying question

When you say the agent can “do” something, does it generate instructions for a person, or does it have permission to call tools and change systems?

Examples

Text-only

Drafts a plan for updating a website.

Tool-using

Reads brand documentation.
Creates GitHub issues.
Opens pull requests.
Updates project status.
Drafts release notes.

Tool-using with real-world consequences

Sends emails.
Changes production configuration.
Purchases ads.
Deploys software.
Moves money.

The risk profile changes significantly as the action layer becomes more powerful.

3. The Planning Horizon: Next Step or Long-Running Goal

This axis describes how far ahead the system can reason and organize work.

Possible names for this axis

• Planning Horizon
• Goal Depth
• Reasoning Span
• Task Decomposition Depth
• Short-Range vs. Long-Range Planning

What this means

Some systems are reactive. They decide the next best action based on the immediate prompt.

Other systems break a goal into steps, track progress, revise the plan, and continue operating across a longer span of work.

This is one of the places where marketing language often gets ahead of reality. A system may look like it is pursuing a long-term goal when it is really just generating a plausible next step.

The distinction matters.

Clarifying question

Does the agent only decide the next step, or does it maintain a larger plan and track progress against that plan?

Examples

Reactive

The user asks a question.
The AI answers.

Short-horizon planning

The AI creates a five-step plan.
It executes each step in order.
It stops when the sequence is complete.

Long-horizon goal pursuit

The AI has a standing objective:
“Improve this Confluence space so it is clearer for humans and LLMs.”

It reviews pages weekly.
Identifies gaps.
Prioritizes changes.
Drafts updates.
Tracks unresolved issues.
Revises its approach as the space changes.

Most production systems today are closer to short-horizon planning than true long-horizon autonomy.

4. The Memory Model: No Memory, Session State, or Persistent Context

This axis describes what the system remembers and where that memory lives.

Possible names for this axis

• Memory Model
• State Persistence
• Context Retention
• Knowledge Continuity
• Working Memory vs. Long-Term Memory

What this means

An AI system can only act intelligently relative to the context it has available.

Some systems only know what is in the current prompt. Others maintain state during a session. More advanced systems can retrieve information from databases, vector stores, documents, logs, prior conversations, or structured records.

This is where people often blur several things together.

“Memory” might mean:

• the current context window
• a saved chat history
• retrieved documents from a vector database
• structured state in Postgres
• previous actions and observations
• user preferences
• project history
• a fine-tuned model

Those are different.

Clarifying question

When you say the agent has memory, what exactly is stored, where is it stored, and how is it retrieved?

Examples

No durable memory

The model only knows what is in the current prompt.

Session memory

The model remembers what happened earlier in the current workflow run.

Retrieved memory

The system searches Confluence, Google Drive, Slack, or a vector database before answering.

Structured operational memory

The system stores task status, prior decisions, approvals, errors, owner assignments, and next actions in a database.

For real agentic systems, structured state is often more important than vague “memory.”

5. The Autonomy Model: Assistant, Copilot, or Delegated Operator

This axis describes how much the system can do without human intervention.

Possible names for this axis

• Autonomy Model
• Human Control Model
• Delegation Level
• Approval Boundary
• Human-in-the-Loop Structure

What this means

Autonomy is not binary.

A system might draft work but require approval before anything is sent. It might run automatically but only make low-risk changes. It might be allowed to take some actions directly while escalating others.

This is one of the most important axes because it determines trust, risk, and operational design.

Clarifying question

Where does the human have to approve, and what can the system do without asking?

Examples

Human-directed assistant

The user asks for every action.
The AI responds.
The user decides what to do.

Human-in-the-loop copilot

The AI drafts an email.
A person reviews it.
The person clicks send.

Human-on-the-loop operator

The AI runs every day.
It performs approved categories of work.
A person monitors exceptions.

Fully delegated operator

The AI receives a goal and acts independently until it finishes or fails.

Most serious business systems should not jump directly to full autonomy. The better pattern is usually to define approval boundaries by risk.

6. The Workflow Model: Fixed Chain, State Machine, or Dynamic Graph

This axis describes how the system’s steps are organized.

Possible names for this axis

• Workflow Model
• Orchestration Model
• Execution Architecture
• Process Shape
• Chain vs. Graph vs. Dynamic Controller

What this means

Some AI workflows are fixed chains. Step 1 always leads to step 2, then step 3.

Other systems are graphs or state machines. The next step depends on the current state.

More dynamic systems allow the model to decide which action to take next from a set of available options.

This distinction matters because “agentic” is often used to describe what is really just workflow orchestration with an LLM inside it.

Clarifying question

Is the path predefined, or does the AI decide which path to take based on the situation?

Examples

Fixed chain

Ingest document → summarize → classify → store result

Conditional workflow

Ingest document
If it is a proposal, extract deal terms
If it is a meeting note, extract action items
If it is a strategy doc, identify open questions

Dynamic graph

The AI evaluates the current state.
It chooses among search, summarize, ask human, update page, create task, or stop.
The path changes based on what it finds.

A lot of practical agentic software is best understood as graph-based workflow orchestration.

7. The Role Model: One Generalist or Multiple Specialized Participants

This axis describes whether the system has one AI role or multiple coordinated roles.

Possible names for this axis

• Role Model
• Agent Multiplicity
• Specialization Structure
• Single-Agent vs. Multi-Agent Design
• Division of Cognitive Labor

What this means

Some systems use one model playing one role.

Others split the work into multiple roles:

• planner
• researcher
• writer
• reviewer
• critic
• executor
• compliance checker
• tool specialist
• project manager

This can be useful, but it can also become theater. Calling something “multi-agent” does not automatically make it better. Sometimes it is just a complicated prompt chain with role names.

The useful question is whether the separation of roles improves reliability, clarity, reviewability, or execution.

Clarifying question

Are there actually multiple specialized processes with separate responsibilities, or is one model being prompted to act like different people?

Examples

Single-agent

One model reviews a document and suggests edits.

Multi-role workflow

Researcher finds relevant source material.
Planner creates the update structure.
Writer drafts the page.
Reviewer checks for accuracy and tone.
Executor submits the approved update.

Multi-agent system

Separate agents run with separate goals, state, permissions, tools, and evaluation loops.

The last version is meaningfully different from just asking one model to “think like a researcher, editor, and reviewer.”

8. The World Model: Prompt Context or Structured Understanding of the Environment

This axis describes how the system represents the environment it is acting within.

Possible names for this axis

• World Model
• Environment Representation
• Operational State Model
• System Awareness Layer
• Context Structure

What this means

A real agent needs some understanding of the world it is operating in.

For business software, “world” might mean:

• users
• projects
• customers
• documents
• permissions
• tasks
• systems
• deadlines
• dependencies
• risks
• prior decisions

In many LLM systems, this “world” is just described in the prompt. That can work for small tasks, but it breaks down as complexity increases.

A stronger system externalizes the world model into structured state: databases, schemas, knowledge graphs, task records, project objects, document maps, system inventories, or explicit dependency models.

Clarifying question

Does the agent understand the operating environment as structured state, or is the environment only described in text each time?

Examples

Prompt-only world model

“You are helping with the VSA project. Here is some background...”

Retrieved world model

The system searches the relevant Confluence pages and Jira issues before acting.

Structured world model

The system knows:
- projects
- owners
- dependencies
- document status
- task status
- source systems
- approval rules
- open questions

The more serious the agent, the more important this layer becomes.

9. The Reliability Model: Best Effort or Verified Execution

This axis describes how the system checks its work.

Possible names for this axis

• Reliability Model
• Validation Layer
• Quality Control Structure
• Execution Safety Model
• Trust and Verification Mechanism

What this means

LLMs are probabilistic. They can be useful and still wrong.

So an agentic system needs a reliability model. That might include schema validation, tests, deterministic rules, external checks, retries, human approval, logs, diffs, simulations, or rollback procedures.

Without this layer, an agent is just an unreliable loop with tool access.

Clarifying question

How does the system know whether its action was correct, safe, complete, and aligned with the goal?

Examples

Weak reliability

The AI says the work is done.

Better reliability

The system checks:
- Did the API call succeed?
- Did the output match the required schema?
- Did the tests pass?
- Did a human approve the change?
- Was the change logged?

Stronger reliability

The system creates a proposed change.
Shows a diff.
Runs validation.
Requests approval.
Applies the change.
Verifies the result.
Stores the decision and outcome.

For production use, this axis is not optional.

10. The Trigger Model: User-Initiated, Event-Driven, Scheduled, or Continuous

This axis describes how the system starts.

Possible names for this axis

• Trigger Model
• Activation Pattern
• Start Condition
• Runtime Initiation
• Event and Schedule Model

What this means

Some AI systems only run when a person asks.

Others run when something happens:

• an email arrives
• a file is uploaded
• a Jira issue changes
• a Confluence page is created
• a Slack message is posted
• a webhook fires

Others run on a schedule:

• every morning
• every Friday
• at the end of each sprint
• once per month

Others are closer to continuous monitors.

Clarifying question

What causes the agent to start, and when should it stop?

Examples

User-initiated

“Review this page and suggest improvements.”

Event-driven

When a new Confluence page is created, classify it and suggest metadata.

Scheduled

Every Friday, review stale Jira issues and draft a status report.

Continuous

Monitor incoming support tickets and route urgent issues as they arrive.

Triggering is a major part of agent design because it defines how the system enters real operations.

11. The Permission Model: What the Agent Is Allowed to See and Change

This axis describes boundaries.

Possible names for this axis

• Permission Model
• Access Boundary
• Authority Scope
• Read/Write Control Layer
• Operational Permission Envelope

What this means

Agentic systems need explicit permissions.

It is not enough to say the system can “access Confluence” or “work with Jira.” You need to know what it can read, what it can write, what it can delete, what it can send, what it can approve, and what requires escalation.

This becomes especially important when connecting AI to business systems.

Clarifying question

What systems can the agent access, and what actions is it authorized to perform in each one?

Examples

Read-only

Can read Confluence pages and summarize them.
Cannot modify pages.

Draft-only

Can draft page updates.
Cannot publish without approval.

Controlled write

Can update labels, create comments, and draft issues.
Cannot delete records or change project configuration.

High-authority

Can send messages, update production systems, change records, or trigger workflows.

The more permission an agent has, the more important validation, logging, and human approval become.

12. The Ownership Model: Who Is Responsible for the Outcome

This axis describes accountability.

Possible names for this axis

• Ownership Model
• Accountability Model
• Responsibility Boundary
• Operational Ownership
• Failure Ownership Structure

What this means

This is often left out of agent discussions, but it matters in real work.

If an agent drafts something wrong, who catches it? If it sends the wrong email, who owns the result? If it changes the wrong Jira issue, who fixes it? If it misses an important escalation, who is responsible?

The system may be automated, but accountability still belongs somewhere.

Clarifying question

Who owns the result when the agent acts, and who is responsible for reviewing failures?

Examples

Personal assistant model

The user owns all outcomes.
The AI only helps prepare work.

Team copilot model

The team owns the workflow.
The AI assists within defined boundaries.

System owner model

A named operator owns the agent’s behavior, monitoring, approvals, logs, and failure recovery.

This is one of the practical differences between a demo and a production system.

A More Useful Way to Describe an Agent

Instead of saying:

We are building an AI agent.

It is more useful to say something like:

We are building an event-driven, tool-using AI workflow that reads Confluence and Jira, maintains structured state in a database, drafts proposed updates, requires human approval before writing changes, and runs once per week.

That description is longer, but it is much more useful.

It tells us:

• how it starts
• what it can access
• what it can do
• how much autonomy it has
• where state lives
• what approval boundary exists
• how it fits into operations

That is the level of language that makes a real implementation possible.

A Short Clarification Checklist

When someone says “agentic,” I want to clarify:

1. Invocation Model — Is it one-shot or loop-based?
2. Action Model — Does it generate text or use tools?
3. Planning Horizon — Does it react, plan short-term, or pursue longer goals?
4. Memory Model — What does it remember, and where is that stored?
5. Autonomy Model — What can it do without approval?
6. Workflow Model — Is it a fixed chain, conditional graph, or dynamic controller?
7. Role Model — Is it one generalist or multiple specialized roles?
8. World Model — Is the operating context prompt-based, retrieved, or structured?
9. Reliability Model — How does it validate work and recover from errors?
10. Trigger Model — What starts it?
11. Permission Model — What can it read, write, send, change, or delete?
12. Ownership Model — Who is accountable for the result?

The Practical Point

The term “AI agent” is not useless. It is just too compressed.

It compresses too many design choices into one word.

That compression can be fine for casual conversation, but it is not good enough for architecture, buying software, assigning responsibility, estimating risk, or deciding what should be built.

So when I ask someone what they mean by “agentic,” I am not trying to be difficult. I am trying to move from a buzzword to an operating model.

The point is to get to useful clarity faster:

What starts the system?
What does it know?
What can it access?
What can it change?
How does it decide?
How does it verify?
When does it ask for help?
Who owns the outcome?

Once those questions are answered, the conversation becomes much more practical.