What AI Agents Actually Are

Most people use the word "agent" when they really mean "something with AI inside it." That makes the category sound more confusing than it needs to be.

Here is the practical definition I use:

An AI agent is software that can look at a goal, choose the next step, use tools, observe the result, and keep going until it reaches a stop condition.

That is it. The important part is not personality, chat UI, or how impressive the demo looks. The important part is the loop:

1. Read the goal.
2. Decide the next action.
3. Use a tool or produce an output.
4. Inspect what happened.
5. Decide whether to continue, ask for help, or stop.

If your system does not need that loop, you probably do not need an agent. You may need a prompt, a workflow, a classifier, a retrieval system, or a normal automation with one AI step inside it.

This is the first tutorial in Stanley's AI Systems Lab. After this, read AI Agents vs. Automations vs. Chatbots for a decision guide.

The agent loop in plain English

An agent is useful when the work cannot be completed in one fixed step because the correct next action depends on what happened earlier.

For example, imagine a founder wants a weekly competitor brief. A simple automation could:

• Pull a saved list of competitor URLs.
• Scrape the pages.
• Summarize changes.
• Send an email.

That works if the pages are predictable and the task is always the same.

An agent becomes useful when the workflow needs judgment:

• One competitor launched a new product page.
• Another changed pricing but buried it in FAQ copy.
• A third published a changelog that mentions a feature name without context.
• The system needs to decide what to investigate next.
• The system needs to cite evidence and flag uncertainty.

In that case, the model is not just filling in text. It is deciding which tool to use next and whether the current evidence is enough.

What agents are good at

Agents are best when the task has a clear goal but an uncertain path.

Good use cases include:

• Research that requires following sources, opening pages, and reconciling conflicting information.
• Support triage that needs to inspect customer history, classify urgency, draft a response, and escalate edge cases.
• Data cleanup where the system must inspect messy records, apply rules, and ask for review when confidence is low.
• QA flows that click through a product, gather evidence, and report reproducible issues.
• Internal operating workflows where the next step depends on documents, messages, tickets, or database state.

The pattern is strongest when the agent has a narrow domain, a short tool list, and a clear definition of done.

What agents are bad at

Agents are usually the wrong answer when the workflow is already deterministic.

Do not build an agent when:

• A cron job can do the same job.
• A form submission needs one classification.
• The system should always follow the same steps.
• A mistake would create legal, financial, security, or customer harm without human approval.
• Nobody can review the agent's work.

The mistake I see most often is adding agency before adding structure. The model gets a vague instruction like "handle customer emails" and access to too many tools. Then everyone is surprised when the behavior is inconsistent.

Agents do not remove the need for product design. They increase the need for it.

A simple framework: job, boundary, tools, memory, stop

Before building an agent, write down five things.

1. Job

What exact job should the agent complete?

Bad:

• Help with sales.
• Do research.
• Manage support.

Better:

• Prepare a one-page pre-call brief for a sales meeting using the account notes, company site, and last five support tickets.
• Find pricing changes across five competitor pages and cite the source for every claim.
• Classify new support emails into urgent, billing, product bug, or normal queue, then draft a reply for human review.

If the job cannot be explained in one sentence, the agent will probably be too broad.

2. Boundary

What is the agent allowed to do without asking?

Examples:

• It can read CRM notes but cannot edit the CRM.
• It can draft a customer email but cannot send it.
• It can create a GitHub issue but cannot close one.
• It can recommend a refund but cannot issue the refund.

The boundary should match the risk of the action. Reading is usually lower risk than writing. Drafting is lower risk than sending. Flagging is lower risk than deleting.

3. Tools

What tools does the agent need?

Start with the smallest useful tool belt:

• Search or retrieval for internal knowledge.
• A web fetcher for public pages.
• A database or CRM reader.
• A ticket or document writer.
• A way to ask for human approval.

Every extra tool increases the surface area for failure. If the agent has twelve tools, it needs much stronger routing, permissions, and logging than an agent with three.

4. Memory

What should the agent remember, and for how long?

Most production systems do not need a mysterious long-term memory. They need boring, explicit state:

• The task goal.
• The input documents.
• Actions taken.
• Tool outputs.
• Decisions made.
• Confidence and uncertainty.
• Final result.

This run log is more valuable than a vague memory store because a human can inspect it.

5. Stop

When should the agent stop?

Good stop conditions include:

• It found enough evidence to answer the question.
• It completed the checklist.
• It hit a maximum number of tool calls.
• It reached a confidence threshold.
• It found a risky action that requires approval.
• It encountered missing data and needs a human.

Without a stop condition, an agent can keep spending money, looping through tools, or producing more text without improving the result.

The smallest useful agent design

If I were building a first agent for a founder, I would start with a research assistant for sales calls.

The workflow:

1. Input: company name, domain, meeting date, and optional contact name.
2. Tools: public web search, company website fetch, CRM read-only notes, and internal customer history.
3. Goal: produce a brief with company overview, likely priorities, recent signals, risks, and suggested discovery questions.
4. Boundary: read-only research and draft output only.
5. Stop: after checking required sources or after a maximum number of searches.
6. Human review: founder reads the brief before using it.

This is a good first agent because it has leverage but low downside. If it misses something, the founder can still correct course on the call. If it works, it saves meaningful prep time every week.

A practical agent checklist

Use this before you ship:

• The agent has one job.
• The goal is specific enough to grade.
• The tool list is short.
• Every write action has a permission rule.
• The system records tool calls and observations.
• There is a maximum runtime or tool-call budget.
• There is a human escalation path.
• The output includes sources when it makes factual claims.
• The team has examples of good and bad outputs.
• There is an evaluation set with real tasks.

If you cannot check these boxes, keep the system in prototype mode.

How agents fail

Agents usually fail in predictable ways.

They chase the wrong goal. The prompt says "do research" but the user expects "prepare a decision memo." The model optimizes for volume instead of usefulness.

They use tools too freely. The agent searches when it should read internal context, writes when it should draft, or repeats the same query because it does not know what changed.

They hide uncertainty. The output sounds confident because LLMs are fluent, not because the system has enough evidence.

They lack review points. The agent can take high-stakes actions without a human checkpoint.

They are evaluated by vibes. The demo feels good once, but nobody tracks whether the workflow improves over time.

The fix is not a longer prompt. The fix is tighter product design around the loop.

When to start with something simpler

Before building an agent, ask: could this be one of these simpler systems?

• A prompt template that turns structured inputs into a draft.
• A classifier that routes work into queues.
• A retrieval system that answers questions from approved docs.
• A normal automation with one AI summarization step.
• A checklist app with AI suggestions.

Many useful AI products are not agents. That is a good thing. Simpler systems are easier to debug, cheaper to run, and easier to trust.

If you are unsure, start with the simplest workflow that handles 80 percent of the work. Add agency only where the next action genuinely depends on observations from earlier steps.

The real promise of agents

The promise of agents is not that they replace teams. The promise is that they can turn messy, repeated knowledge work into inspectable workflows.

A good agent feels less like a genius assistant and more like a careful junior operator:

• It follows a defined process.
• It uses approved tools.
• It records what it did.
• It asks for help when the task gets risky.
• It improves because the team can review examples.

That is less flashy than most demos, but it is much closer to what works.

If you want the next step, read AI Agents vs. Automations vs. Chatbots. If you are a founder trying to decide what to build first, start with The Practical AI Stack for Founders.