What an agent is

By the end, you can

• Explain the difference between a workflow and an agent in plain language (LA-1).
• Name the five boundaries that turn capability into controlled authority (LA-1, LA-2).
• Identify, informally, which proposed agent actions likely need a person's sign-off before they run (LA-2).

Before you start

This is Module 1, Lesson 1 of the Local AI Agents course. It assumes you can read plain instructions and have used at least one AI chat or coding assistant — you do not need to have built or configured an agent yet. It does not require a specific operating system, a local model runtime or a development machine; those choices belong to a later module, Safe local setup, once you already have this lesson's vocabulary for boundaries and authority.

Start with the smallest honest definition

An AI agent is not simply a chatbot with a grand name. It is a system that can use a model to manage a task, choose from available tools and act within instructions. A workflow is different: its steps are pre-arranged in code, even if an LLM helps inside one of those steps.

That distinction matters because choice creates both usefulness and risk. A workflow can be predictable because its route is fixed. An agent can adapt when the task is ambiguous, but only within the routes, tools and authority you give it.

• Start with the smallest useful job.
• Write down what must remain outside its authority.
• Stop when evidence says the job is complete or out of scope.

Capability is not authority

A model may be capable of drafting an email, looking up a record or proposing a command. That does not mean it should be authorised to send, change or run it. Authority is a product and governance decision, not a model feature.

A bounded agent has a written operating envelope. The envelope makes it possible to inspect what the agent may do, catch an overreach and stop it before the action becomes a problem.

• Task boundary — the job it is solving, including an explicit stop condition.
• Data boundary — what it may read, what it may retain and what it must never receive.
• Tool boundary — the exact read or action tools available, with narrow parameters.
• Authority boundary — actions it may take automatically, actions needing approval and actions it may never take.
• Time and cost boundary — when it stops, how much work it may attempt and what it must report back.

Use approval for side effects, not as decoration

Guardrails can automatically check inputs, outputs or tool arguments. Human review is different: it pauses a run before a sensitive side effect, such as an edit, cancellation, shell command or protected tool call. That pause is only useful when the reviewer sees enough context to make a real decision.

A useful approval request names the exact proposed action, affected target, expected result, reversible path and reason it was selected. “Approve?” without those details is not oversight; it is an opaque rubber stamp.

A worked boundary: inbox research assistant

Imagine an assistant that prepares a daily summary of a shared inbox. It can read messages from a named mailbox, group them by topic and draft a summary. It cannot send replies, alter records, open attachments from unknown senders or retain message bodies outside the run.

If it finds a message that appears urgent, it flags it with evidence. A person decides whether to reply, escalate or ignore it. The assistant is still valuable: it reduces scanning work while leaving external communication and judgment with the owner.

This is a better first agent than an autonomous inbox manager. It has a concrete job, constrained data, read-only tools and a clear hand-off point.

The boundary test before you build

Before connecting a model to a tool, answer these questions in writing. If you cannot answer one, the agent is not ready to receive that access.

• What evidence tells the agent the task is complete?
• Which tool call would cause harm if its target or parameters were wrong?
• What does the agent do when it is uncertain, blocked or asked to leave scope?
• Who can approve a side effect, and what do they see before deciding?
• How can an operator inspect the result and reverse the change?

Accessibility notes

This lesson is text-first, with no images, audio or video and nothing to download. The practice exercise's model answer sits behind a native disclosure control, which is reachable and operable by keyboard and announced correctly by screen readers without any custom scripting. The knowledge check uses native radio-button inputs with a visible question and options, and its result is posted to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Building effective agents — Anthropic Engineering. Distinguishes predefined workflows from agents that dynamically direct process and tool use; recommends starting with the simplest solution.
2. A practical guide to building agents — OpenAI. Describes models, tools and instructions as core agent components, and stresses clearly defined guardrails.
3. Guardrails and human review — OpenAI API documentation. Explains automatic guardrails and approval pauses for sensitive side effects.
4. Appendix C: AI Risk Management and Human-AI Interaction — NIST AI Resource Center. Calls for clear, differentiated human roles and responsibilities when overseeing operational AI systems.