AI Engineering Living Glossary #015 — AI Agents: Goal-Directed Systems That Use Tools and Make Decisions

AI ENGINEERING | LIVING GLOSSARY | #015

AI AGENTS

Goal-Directed Systems That Use Tools and Make Decisions

Chapter 3: Connecting AI to Tools, Workflows, and Agents

Lesson 15 of 24

AIYING — Accomplishing with AI

An employee contacts the IT help desk:

"My VPN stopped working after yesterday's software update. Please investigate and help me restore access."

A conventional chatbot can suggest troubleshooting steps. A tool-enabled assistant can retrieve a diagnostic result. A predefined workflow can execute a fixed troubleshooting sequence.

But what if the next diagnostic step depends on what the system discovers?

Perhaps the VPN service is running but authentication is failing. Perhaps the client version is outdated. Perhaps the problem affects multiple employees and requires escalation.

An AI agent can select among permitted diagnostic actions, examine observations, and adapt its next step toward the user's goal.

This is the promise of AI agents—and also the source of important engineering challenges.

Engineering insight: An AI agent combines goal-directed, model-guided decisions with tools and feedback. Its autonomy must be bounded by permissions, policies, budgets, and verifiable stopping conditions.

Contents

1. What Is an AI Agent?
2. Why AI Agents Matter
3. Types and Patterns of Agents
4. The Agent Execution Loop
5. Agents vs Chatbots, Tools, and Workflows
6. Agent Architecture
7. Security, Reliability, and Control
8. Industry Applications
9. Engineering Design Decisions
10. Practical Industry Case: IT Support
11. Hands-On Mini Project
12. Connected Glossary Terms
13. Living Update
14. Key Takeaway
15. References

1. What Is an AI Agent?

An AI agent is a software system that uses an AI model to help select actions toward a goal, often interacting with tools and its environment over multiple steps.

Unlike a single model response, an agent may repeatedly:

• Interpret the current goal.
• Observe relevant information.
• Select an appropriate next action.
• Invoke an available tool.
• Examine the tool result.
• Update its working state.
• Continue, stop, or escalate.

There is no single universally accepted technical definition of an AI agent. Implementations vary in autonomy, planning, memory, tool access, and execution control.

In this lesson, the defining engineering feature is model-guided selection of actions toward a goal, within a host application's control boundaries.

An agent need not be fully autonomous. It may be limited to read-only tools, a fixed number of steps, or a narrowly defined task.

It also need not maintain permanent memory or generate an explicit long-term plan.

↑ Back to contents

2. Why AI Agents Matter

Some tasks cannot be reduced easily to a single response or a fully predetermined sequence.

They involve uncertainty, changing information, and choices that depend on intermediate results.

Examples include:

• Investigating an unfamiliar software error.
• Researching a question across multiple sources.
• Diagnosing a customer support issue.
• Analyzing a repository before proposing code changes.
• Investigating an operational exception.

Agents can provide flexibility when the correct next step cannot be specified completely in advance.

However, flexibility introduces new risks: unexpected tool selection, repeated actions, uncontrolled costs, unreliable conclusions, and unauthorized changes.

Practical principle: Use agentic behavior when adaptive decision-making provides meaningful value. Do not introduce autonomy merely because an agent framework is available.

↑ Back to contents

3. Types and Patterns of AI Agents

A. Tool-using agent

Selects from permitted tools to gather information or perform operations.

B. Research agent

Searches, retrieves, compares, and synthesizes information, potentially through several iterations.

C. Coding agent

Inspects code, proposes changes, runs permitted tests, and evaluates results within an engineering environment.

D. Diagnostic agent

Investigates symptoms, chooses diagnostic checks, interprets observations, and recommends or performs permitted remediation.

E. Human-supervised agent

Can investigate independently but requires human approval for specified actions.

F. Multi-agent system

Coordinates multiple model-driven components, potentially with specialized responsibilities.

These patterns overlap. A coding agent may also be a tool-using, human-supervised agent.

Multi-agent designs introduce additional coordination and evaluation complexity. They are not automatically better than a single agent.

↑ Back to contents

4. The Agent Execution Loop

A common agent design follows a repeated cycle:

       User Goal
           |
           v
   Interpret Current State
           |
           v
   Select Next Action
           |
           v
   Validate and Authorize
           |
           v
   Execute Permitted Tool
           |
           v
   Observe Tool Result
           |
           v
   Evaluate Progress
           |
           v
    Goal Achieved?
      /       \
    Yes        No
     |          |
   Verify     Continue,
   and Stop   Escalate,
              or Stop

The model may choose actions, but the application must control actual execution.

The loop must have explicit termination conditions, such as:

• The task has been verified as complete.
• The maximum number of steps has been reached.
• A time or cost budget has been exhausted.
• An authorization boundary has been reached.
• The task requires human intervention.
• The system detects insufficient evidence or repeated failure.

Important: An agent's claim that a task is complete is not necessarily proof that the task was completed.

↑ Back to contents

5. AI Agents vs Chatbots, Tools, and Workflows

Concept	Primary characteristic	Example
Chatbot	Conversational interaction.	Explains how VPN authentication works.
Tool Calling	Requests an external capability.	Queries VPN client version.
Workflow	Coordinates a designed process.	Runs a fixed set of VPN checks.
AI Agent	Selects actions dynamically toward a goal.	Chooses the next diagnostic based on observed results.

These are not mutually exclusive categories.

An agent may be accessed through a chatbot. It may invoke tools and operate inside a workflow.

The key distinction is the amount of discretion the model has in choosing subsequent actions.

When a process is predictable, a deterministic workflow is often simpler to test and operate.

When the process requires adaptive investigation, a bounded agent may be more appropriate.

↑ Back to contents

6. AI Agent Architecture

A practical agent system may contain the following components.

1. Goal and task specification

Defines what the agent is trying to accomplish and the conditions for success.

2. AI model

Interprets information and proposes next actions.

3. Tool registry

Defines available functions, interfaces, and permitted capabilities.

4. Execution controller

Validates tool requests, enforces permissions, and manages execution.

5. Working state

Tracks the current task, observations, decisions, and relevant intermediate results.

6. Optional memory

Retains selected information across steps or sessions where appropriate and permitted.

7. Policy and approval layer

Restricts sensitive operations and routes designated actions to human reviewers.

8. Evaluation and verification

Checks whether the agent's actions and final results meet defined criteria.

9. Observability

Records tool calls, failures, latency, costs, and relevant execution events.

User / Task
     |
     v
Agent Controller
     |
     +--> AI Model
     |      |
     |      v
     |   Proposed Action
     |      |
     +--> Validation and Policy
     |      |
     +--> Authorized Tool
     |      |
     +--> Observation
     |      |
     +--> State Update
     |
     +--> Continue / Stop / Escalate
     |
     v
Verified Result

Memory and state are related but different. An agent can maintain task state without storing long-term personal information.

↑ Back to contents

7. Security, Reliability, and Control

Agentic systems can make multiple decisions and tool requests, sometimes using information obtained from untrusted sources.

This makes defense-in-depth especially important.

Least-privilege tools

Give the agent only the capabilities needed for its task.

Independent authorization

Check user identity, permissions, and business policy outside the model.

Prompt injection resistance

Treat web pages, retrieved documents, tickets, and tool responses as untrusted data rather than instructions.

Tool argument validation

Validate schemas, identifiers, ranges, and operational constraints.

Human approval

Require approval before specified consequential actions such as changing access rights or deleting resources.

Execution budgets

Limit steps, runtime, tool usage, and expenditure.

Safe stopping behavior

Stop or escalate when evidence is insufficient, authorization fails, or repeated attempts do not make progress.

Idempotency and recovery

Prevent duplicate effects and handle interrupted operations safely.

Result verification

Confirm outcomes through authoritative system evidence rather than trusting a model's summary alone.

Audit and monitoring

Capture appropriate records of tool selection, execution, decisions, and failures while protecting sensitive information.

Security principle: The agent can recommend what to do next. Trusted application components must determine what it is allowed to do.

↑ Back to contents

8. Industry Applications

Domain	Potential agent task	Important control
IT support	Investigate incidents using diagnostic tools.	Restrict system changes and credential access.
Software engineering	Inspect code, propose patches, run tests.	Sandbox execution and require review before deployment.
Customer service	Investigate complex support requests.	Protect customer records and constrain transactions.
Business research	Collect and compare information.	Verify sources and preserve provenance.
Operations	Investigate inventory or process exceptions.	Control operational changes.
Security operations	Assist with alert triage and evidence gathering.	Require authorization for containment actions.
Data analysis	Explore datasets and generate findings.	Limit data access and verify calculations.

The appropriate autonomy level varies with the task's reversibility, uncertainty, potential harm, and regulatory requirements.

↑ Back to contents

9. Engineering Design Decisions

1. What exact goal should the agent pursue?
2. What evidence demonstrates success?
3. Does the task truly require adaptive action selection?
4. Would a deterministic workflow be sufficient?
5. Which tools should the agent access?
6. Which tools are read-only and which change state?
7. How are tool requests validated and authorized?
8. What information may the agent retain?
9. What are the maximum step, time, and cost budgets?
10. When must the agent ask for human approval?
11. How will the system detect loops and lack of progress?
12. How will prompt injection be mitigated?
13. How will tool failures and uncertain results be handled?
14. How will final outcomes be independently verified?
15. How will performance be evaluated before deployment?

Design principle: Choose the minimum autonomy necessary to accomplish the task effectively.

↑ Back to contents

10. Practical Industry Case: The VPN Support Agent

Scenario: An employee reports that VPN access stopped working after a software update.

The organization deploys a fictional AI support agent with access to approved read-only diagnostics and internal troubleshooting documentation.

Available tools

• get_client_version — retrieves the installed VPN client version.
• check_service_status — reports whether the local VPN service is running.
• get_recent_errors — retrieves approved diagnostic error codes.
• search_knowledge_base — searches authorized support documentation.
• create_support_ticket — creates an escalation ticket after required checks.

These are illustrative interfaces, not claims about a particular commercial VPN product.

Illustrative investigation

1. The agent receives the user's goal: restore VPN connectivity.
2. It checks the installed VPN client version.
3. The result indicates an older client version.
4. The agent searches the approved knowledge base for compatibility information.
5. The documentation identifies a relevant compatibility issue.
6. The agent retrieves recent diagnostic errors.
7. The errors are consistent with the documented issue.
8. The agent recommends the organization's approved remediation steps.
9. If the issue remains unresolved, it prepares an escalation ticket with supporting evidence.
10. The application verifies ticket creation before confirming escalation.

What makes this agentic?

The next diagnostic operation depends on observations. The model selects among permitted tools instead of following one fixed sequence for every incident.

What must the agent not do?

• Request or expose the employee's password.
• Disable security controls.
• Modify access permissions without authorization.
• Install software through an unapproved mechanism.
• Claim the VPN is fixed without evidence.
• Continue indefinitely when diagnostics fail.

Possible outcomes

Resolved: The employee follows approved remediation, and a permitted connectivity check confirms restoration.

Escalated: The agent cannot safely resolve the issue and creates a verified support ticket.

Blocked: Required permissions or diagnostic information are unavailable, so the agent stops and explains the limitation.

Industry insight: A useful support agent does not need unrestricted system access. It needs well-defined goals, trustworthy observations, appropriate tools, and controlled escalation.

↑ Back to contents

11. Hands-On Mini Project

Design a Simulated IT Support Agent

Objective: Create a bounded agent that investigates fictional VPN incidents using simulated diagnostic tools.

No real corporate systems, credentials, or administrative permissions are required.

Step 1: Define the goal

Investigate the incident and either identify a supported next step or escalate appropriately.

Step 2: Create fictional incidents

• Outdated VPN client.
• VPN service stopped.
• Authentication failure requiring human support.
• Unknown error code.
• Diagnostic service unavailable.

Step 3: Define tools

Create simulated versions of get_client_version, check_service_status, get_recent_errors, and search_knowledge_base.

Step 4: Define permissions

Allow read-only diagnostics. Prohibit credential access and administrative changes.

Step 5: Implement the agent loop

For each incident, let the model choose a diagnostic tool, inspect the result, and select the next permitted action.

Step 6: Add stopping conditions

Limit the simulation to five tool calls per incident. Stop on verified completion, prohibited actions, repeated failures, or exhausted budget.

Step 7: Test failures

Simulate an invalid tool request, unavailable service, misleading knowledge-base text, and repeated selection of the same unsuccessful action.

Step 8: Evaluate

Metric	Evaluation question
Task success	Did the agent identify an appropriate resolution or escalation?
Tool selection accuracy	Were selected tools relevant to the observed state?
Authorization violations	Did any prohibited operation execute?
Unsupported claims	Did the agent assert results not supported by tool evidence?
Loop termination	Did execution stop within the defined limits?
Escalation quality	Were unresolved cases routed appropriately with evidence?
Tool efficiency	How many calls were needed for a useful outcome?
Failure handling	Did the system recover, stop, or escalate appropriately?

Success criteria

• No unauthorized tool operation executes.
• Every test run terminates within the defined budget.
• Final recommendations are supported by simulated evidence.
• Unresolved incidents are escalated rather than falsely reported as fixed.
• Execution traces explain which tools were selected and why.

Reflection

Where did dynamic action selection help? Which parts could be replaced with a simpler workflow? What additional controls would production deployment require?

↑ Back to contents

12. Connected Glossary Terms

• Tool Calling (#013): Gives agents access to external capabilities.
• Workflows (#014): Can coordinate and constrain agent execution.
• Prompt Engineering (#006): Helps specify goals, instructions, and boundaries.
• RAG (#004): Supplies retrieved evidence for agent decisions.
• Context Window (#005): Constrains how much task history and tool data can be included in a model call.
• Evals (#007): Measures task success, tool selection, and safety behavior.
• Hallucination (#008): Can affect conclusions and tool selection.
• Grounding (#009): Connects agent claims to evidence.
• Guardrails (#010): Restricts prohibited actions and unsafe outputs.
• Observability (#011): Makes agent execution traceable.
• Human-in-the-Loop (#012): Supports approval and escalation.

Previous lesson: #014 — Workflows: Orchestrating Multi-Step AI Processes

Next lesson: #016 — Agent Orchestration: Coordinating Agent Execution and Handoffs.

↑ Back to contents

13. Living Update

Editorial baseline: November 2026

AI agent engineering is evolving across model capabilities, orchestration frameworks, tool integration, and enterprise control systems.

Important areas to monitor include:

• Agent evaluation benchmarks and task-completion measurement.
• Secure tool access and permission enforcement.
• Model Context Protocol and tool interoperability.
• Agent observability and execution tracing.
• Human approval and intervention patterns.
• Durable execution and safe recovery.
• Memory design, privacy, and retention controls.
• Multi-agent coordination and handoffs.
• Cost and latency management.
• Prompt injection and untrusted tool-result handling.

Living Glossary note: Update this entry as agent frameworks, evaluation methods, and security practices mature.

↑ Back to contents

14. Key Takeaway

An AI agent uses model-guided decisions and external capabilities to pursue a goal. Reliable agents require bounded autonomy, independent controls, and verified outcomes.

More autonomy is not automatically better engineering.

The aim is to give the system enough flexibility to accomplish useful work while preserving authorization, accountability, recoverability, and human control.

Think like an AI engineer: What is the minimum freedom this agent needs to complete its task—and how will you know when it should stop?

↑ Back to contents

15. References and Further Reading

• OpenAI — Agents Documentation
• LangGraph — Agent and Workflow Orchestration
• Model Context Protocol — Documentation
• OWASP — Generative AI Security Project
• NIST — AI Risk Management Framework
• OpenTelemetry — Documentation

↑ Back to contents

AI Engineering — Living Glossary

One Term. One Industry Connection. One Practical Insight. One Action.

AIYING — Accomplishing with AI

Chapter 3 | Lesson 15 | AI AGENTS

Understand the Term. Connect the Technology. Apply the Knowledge.

↑ Return to top