A language model that answers questions is not necessarily an AI agent.

An agent goes further. It can understand a goal, inspect the current state, choose an action, call a tool, inspect the result and repeat the process until the task is complete.

A useful mental model is:

Goal → Observe → Decide → Act → Evaluate → Repeat

This repeated process is the foundation of many modern agent systems.

What Is an AI Agent?

An AI agent is a system that attempts to achieve a goal by repeatedly observing its environment, selecting an appropriate next action and evaluating the outcome.

Unlike a conventional chatbot, an agent may perform several actions before producing a final answer.

For example, given:

Analyze Acme's current customer status.

an agent may:

1. search the CRM,
2. retrieve the account,
3. inspect open opportunities,
4. inspect support cases,
5. analyze the information,
6. return a summary.

A chatbot primarily generates responses. An agent can execute a workflow.

Agentic AI

Agentic AI refers more broadly to systems designed with some degree of autonomy and action-oriented behavior.

Such systems may be able to:

• decompose goals,
• select tools,
• gather information,
• revise plans,
• maintain state,
• use memory,
• recover from failures,
• escalate important decisions to humans.

Autonomy is therefore not binary. Different agents can operate at different autonomy levels.

Agent Loop

The agent loop is the core execution cycle.

A simplified form is:

while not finished:
    observe()
    decide()
    act()
    inspect_result()

For example, consider:

Find customers likely to repurchase and prepare follow-up email drafts.

An agent may first retrieve customers, then retrieve purchase history, rank the customers, generate drafts and finally determine whether the requested task has been completed.

Stop Conditions

Agents must know when to stop.

Typical stop conditions include:

• the goal has been completed,
• essential information is missing,
• user clarification is required,
• human approval is required,
• a maximum number of steps has been reached,
• a tool repeatedly fails,
• a cost or time budget is exceeded.

Without explicit stopping rules, agents can enter unnecessary or infinite loops.

Planning

Planning is the process of deciding what steps are required to reach a goal.

For example:

Prepare a sales report for last quarter.

may become:

1. retrieve sales data,
2. remove cancelled orders,
3. calculate revenue,
4. identify top customers,
5. compare with the previous quarter,
6. produce a summary.

This is known as task decomposition.

Static and Dynamic Planning

In static planning, the agent generates a complete plan before execution.

In dynamic planning, it chooses the next step after observing the result of the previous step.

Dynamic planning is often better when the environment is unpredictable.

Many production agents use a hybrid approach.

Planner-Executor Architecture

A common design separates planning from execution.

The Planner decomposes the task.

The Executor performs each step.

For example:

Planner:
1. Search customer
2. Load opportunities
3. Load support history
4. Assess risk
5. Generate report

The executor then performs these steps one at a time.

Reasoning in Agents

Reasoning in an agent is the process of selecting an appropriate action given the available evidence and constraints.

Suppose the user asks:

Send a follow-up email to the customer.

The agent may need to determine:

• whether the customer has an email address,
• whether communication is permitted,
• whether another email was sent recently,
• whether the user has permission to send it.

The resulting decision might be:

ACT

ASK

ABSTAIN

or

ESCALATE

Production systems should prefer structured and auditable decisions rather than relying on long internal reasoning traces.

For example:

{
  "action": "ASK_USER",
  "reasonCode": "MISSING_EMAIL"
}

Tool Calling

Agents interact with real systems through tools.

Examples include:

get_customer(customerId)
get_opportunities(accountId)
create_task(data)
send_email(data)

The language model may choose the tool, but the application should control execution.

Tool inputs should be validated and permissions checked outside the model.

Tool Descriptions

Tool descriptions strongly affect agent behavior.

A tool named:

search()

is ambiguous.

A tool named:

search_crm_accounts_by_name(name)

communicates its purpose much more clearly.

A strong tool definition explains:

• what the tool does,
• what arguments it accepts,
• when it should be used,
• when it should not be used,
• what result it returns.

Multi-Step Tasks

Agents become especially valuable when a task requires several dependent operations.

For example:

Find the three customers with the highest churn risk and create follow-up tasks for their account managers.

The workflow may require:

1. loading customers,
2. retrieving usage,
3. retrieving support tickets,
4. checking payment history,
5. calculating risk,
6. ranking customers,
7. finding account managers,
8. creating tasks,
9. generating a summary.

The agent must coordinate these steps while preserving task state.

State

State represents what has happened during the current task.

For example:

{
  "goal": "Find churn-risk customers",
  "step": 4,
  "customersLoaded": true,
  "supportLoaded": true,
  "paymentLoaded": false
}

State allows the system to know what has already happened and what remains to be done.

Memory

Memory is information stored so that an agent can use it again later.

Memory is not the same as the context window.

The context window contains what the model can currently see.

Memory is stored externally and retrieved when needed.

Useful categories include:

• Working Memory — current task information
• Conversation Memory — relevant conversation history
• Long-term Memory — persistent preferences or facts
• Episodic Memory — previous agent experiences
• Semantic Memory — organizational knowledge and documents

Memory should be selective. Storing everything creates cost, privacy and staleness problems.

ReAct

ReAct is a well-known agent pattern based on alternating between reasoning and action.

A simplified form is:

Observe → Decide → Act → Observe → Decide → Act

For example, if a user asks:

Check order 5421 and create a ticket if delivery is late.

an agent can retrieve order status, compare the delivery date, create a support ticket if necessary and then report the outcome.

Reflection and Verification

Reflection allows an agent to inspect whether its previous output is sufficient.

Verification can independently check important results.

A useful architecture is:

Generator → Verifier → Action

For deterministic rules, however, verification should usually be implemented in code rather than delegated to another language model.

Error Handling

Tools can fail.

For example:

503 Service Unavailable

A reliable system may retry, choose an alternative, ask the user, escalate, or stop.

Retries must be bounded.

For example:

MAX_RETRIES = 3

Unlimited retries can create loops, cost increases and service overload.

Human in the Loop

Not every action should be autonomous.

Sensitive actions such as refunds, contract changes, deletion or high-value discounts may require human approval.

A common flow is:

Agent proposes → Human approves → Backend executes

Act, Ask, Abstain and Escalate

A trustworthy agent should not always act.

It should be able to choose among:

• ACT — proceed with an allowed action
• ASK — request missing information
• ABSTAIN — refuse to act because conditions are not appropriate
• ESCALATE — request human review

This decision model is fundamental to reliable agent design.

Agent Autonomy Levels

Different systems can operate at different levels of autonomy.

Level 0: Suggest only

Level 1: Produce drafts

Level 2: Prepare actions but require confirmation

Level 3: Execute low-risk actions autonomously

Level 4: Execute broad workflows autonomously

In production, autonomy should usually increase only when risk is sufficiently low.

Agent Architecture

A practical architecture is:

User
 ↓
Agent Controller
 ↓
LLM
 ↓
Decision
 ↓
Tool Router
 ↓
Tools / APIs / Database
 ↓
Result
 ↓
Agent Controller
 ↓
LLM

The controller should manage:

• loop execution,
• step limits,
• context construction,
• state,
• permissions,
• retries,
• timeouts,
• logging,
• cost limits,
• human approvals,
• stop conditions.

These responsibilities should not be delegated entirely to the LLM.

Simplified Agent Pseudocode

state = initialize(user_request)

for step in range(MAX_STEPS):

    context = build_context(state)
    decision = llm.decide(context)

    if decision.type == "FINISH":
        return decision.response

    if decision.type == "ASK":
        return ask_user(decision.question)

    if decision.type == "ESCALATE":
        return human_review(decision)

    if decision.type == "TOOL_CALL":
        validate(decision)
        result = execute(decision.tool)
        state.add(result)

return stop_due_to_step_limit()

Example: Agentic CRM

Suppose the user asks:

Find customers with high churn risk, select the three most important ones and create follow-up tasks for their account managers.

The agent may plan:

1. Load active accounts
2. Load usage metrics
3. Load support tickets
4. Load payment history
5. Estimate churn risk
6. Rank accounts
7. Select top 3
8. Find managers
9. Create tasks
10. Report results

It may then call tools such as:

get_active_accounts()
get_usage_metrics(accountIds)
get_support_history(accountIds)

A structured decision could look like:

{
  "accountId": "A-192",
  "riskLevel": "HIGH",
  "signals": [
    "USAGE_DROP",
    "OPEN_SUPPORT_CASES",
    "PAYMENT_DELAY"
  ],
  "recommendedAction": "CREATE_FOLLOW_UP_TASK"
}

Before creating the task, the backend should check permissions, validate the account manager and prevent duplicate tasks.

If the account manager cannot be found, the agent should not invent one. It should escalate or ask for clarification.

Observability

Agents are difficult to debug without detailed logs.

Useful telemetry includes:

• user request,
• task goal,
• plan,
• step number,
• tool calls,
• arguments,
• tool results,
• errors,
• retries,
• latency,
• cost,
• final status.

Agent Evaluation

An agent should not be evaluated only by the quality of its final prose.

Important metrics include:

• Task Success Rate
• Tool Selection Accuracy
• Argument Accuracy
• Number of Steps
• Cost per Task
• Latency
• Recovery Rate
• Hallucination Rate
• Escalation Rate
• Unsafe Action Rate

Common Failure Modes

Common problems include:

• infinite loops,
• wrong tool selection,
• invalid arguments,
• hallucinated state,
• premature completion,
• excessive autonomy.

Typical protections include step limits, schema validation, explicit completion criteria and strict permission policies.

Agent Security

Agents have a larger attack surface than ordinary chatbots because they interact with external systems.

Important risks include:

• prompt injection,
• indirect prompt injection,
• tool abuse,
• unauthorized actions,
• data leakage,
• malicious tool output.

Information retrieved from websites, email, documents or tools must not automatically be treated as trusted system instructions.

LLM Decisions vs Deterministic Code

Use LLMs for:

• language understanding,
• planning,
• classification,
• flexible decision making,
• tool selection,
• summarization.

Use deterministic code for:

• authentication,
• authorization,
• financial calculations,
• hard limits,
• validation,
• database transactions,
• security rules.

Not every part of a workflow should be agentic.

Single Agent vs Multi-Agent

Many applications only need one well-designed agent.

Multi-agent systems become useful when distinct roles genuinely need separate responsibilities.

For example:

Research Agent → Analysis Agent → Verification Agent → Execution Agent

However, multi-agent systems introduce more latency, cost and coordination complexity.

A useful principle is:

Do not build a multi-agent system when a single agent is sufficient.

Production Checklist

Before deploying an agent, verify that:

• the goal is explicit,
• completion criteria exist,
• maximum steps are bounded,
• tools are limited and clearly defined,
• arguments are validated,
• permissions are checked outside the LLM,
• state is trustworthy,
• memory is controlled,
• retry limits exist,
• timeouts exist,
• sensitive actions require approval,
• the agent can ask questions,
• the agent can abstain,
• the agent can escalate,
• logs are complete,
• cost limits exist,
• failure recovery is tested.

Final Mental Model

A useful summary is:

Goal
 ↓
Plan
 ↓
Observe
 ↓
Decide
 ↓
Use Tool
 ↓
Observe Result
 ↓
Update State / Memory
 ↓
Evaluate Progress
 ↓
Continue / Ask / Abstain / Escalate / Finish

An AI agent is therefore much more than an LLM connected to a few APIs.

A reliable agent requires state management, controlled tools, permissions, validation, failure handling, stop conditions, observability, risk controls and human oversight when necessary.

Once these foundations are clear, the natural next topic is Agent Architecture, including ReAct, Planner-Executor, Reflection, Verification and Orchestration.