What Should a Business Team Learn Before Using AI Agents?

Most teams begin with the agent. They compare vendors, watch demos, and ask what the model can do.

That is backwards. Before an AI agent receives real work, the team needs a shared understanding of the work itself: what the goal is, which decisions can be delegated, what evidence shows progress, what the agent must never do, and who owns the result. Without that understanding, the team is not adopting a system. It is handing a moving target to a system that can act.

This guide is for a business team preparing to use an agent in an actual workflow. It is not a build tutorial, a release gate, or a substitute for legal or security review. The useful outcome is simpler: after reading it, the team should be able to describe one bounded pilot in plain language and identify what it still does not know.

What is an AI agent, in practical terms?

An AI agent uses a model to manage part of a workflow, choose among available tools, and act toward a goal with some independence. A single-turn chatbot, classifier, or drafting assistant may use an LLM without being an agent if the model does not control the workflow’s execution. OpenAI makes this distinction in its practical guide to agents.

Anthropic uses a related distinction: a workflow follows paths defined in code, while an agent lets the model direct its process and tool use. Its guide also notes that agents need feedback from the environment, checkpoints, and stopping conditions to remain oriented toward the task.

That difference matters to a business team because “the AI writes a draft” and “the AI decides what to check next, calls systems, and changes a record” are not the same delegation. They need different training, permissions, review, and ownership.

Use these three levels in your first conversation:

Level	What the system does	What the team must understand
Advice	Suggests an answer, classification, or next step	A person remains the decision-maker and checks the suggestion
Preparation	Produces a draft, gathers context, or prepares a proposed action	The team checks both the output and the supporting evidence
Action	Calls tools, changes records, sends messages, or starts downstream work	The team defines authority, boundaries, stop conditions, and accountability

The levels are not a judgment about whether the technology is good. They describe how much responsibility the business is delegating. A team that cannot agree which level it wants has not yet defined a use case.

The five things a business team should learn

I use five forms of literacy for this conversation. “Literacy” does not mean that everyone needs to become an engineer. It means that everyone involved can recognize the important decision in front of them and knows when to ask for help.

1. Learn the process before you learn the product

The first lesson is process literacy: describe the work as it happens now, including exceptions, handoffs, missing information, and the moment someone decides that the job is finished.

Do not begin with “we want an agent for customer support.” Begin with a sentence such as:

When a customer asks about an order, the support team checks identity, looks up the order, compares its status with the promised date, decides whether the case is ordinary or exceptional, and either replies or escalates it.

That sentence is already more useful than a product demo. It gives the team something to inspect.

Ask five process questions:

• What starts the work?
• What information must be available before someone can act?
• Which decisions are routine, and which require judgment?
• What happens when a required fact is missing or two systems disagree?
• What observable event means the work is complete?

OpenAI recommends using existing operating procedures and policy documents to create clearer agent instructions, while also capturing incomplete inputs and edge cases. The practical lesson is that your current process documentation is not background material. It is part of the agent’s operating environment. See the tool and instruction guidance in OpenAI’s agent guide.

NIST makes a similar point at the governance level. Its AI Risk Management Framework asks organizations to map the context, purpose, tasks, people, and possible impacts before they measure or manage risk. NIST says this context work also informs an initial decision about whether an AI solution is appropriate. The NIST AI RMF Core explains the relationship.

If the team cannot describe the current process, an agent will not clarify it for free. It will encode the ambiguity and make it harder to see.

2. Learn the difference between assistance and delegation

The second lesson is delegation literacy. People need to know what they are asking the system to do on their behalf.

Have the team label every proposed agent behavior as one of these:

Behavior	The agent may	The agent may not assume
Interpret	Extract meaning, classify a request, or summarize context	That its interpretation is the final business decision
Recommend	Suggest a route, answer, or next check	That a plausible suggestion is verified
Prepare	Draft a reply, fill a proposed change, or assemble a case	That the draft is safe to send or commit
Execute	Call an approved tool or make an allowed change	That a tool being available means every use is authorized

This language helps a team avoid a common category error. “The agent can do it” describes capability. “The agent is allowed to do it” describes authority. “The business is willing to accept the consequence if it goes wrong” describes accountability. Those are three separate questions.

OpenAI groups agent tools into data tools, action tools, and orchestration tools. A tool that reads a CRM record and a tool that sends an external message do not carry the same consequence, even if both appear in the same tool list. The guide’s tool section names these categories.

This is also where role clarity starts. The person who uses the agent is not automatically the person who owns the workflow. The person who maintains the integration is not automatically the person who decides whether a customer should receive a refund. NIST recommends documenting and differentiating human roles in AI configurations and training the people responsible for those roles. The NIST Core lists those governance outcomes.

3. Learn what counts as evidence

The third lesson is evidence literacy. An agent should not be judged only by whether its final sentence sounds convincing.

The team needs to name the evidence that shows three different things:

1. The agent understood the task. This might be the correct customer, order, document, or case type.
2. The agent made meaningful progress. This might be a current record returned from a system, a successful query, or a status change.
3. The business outcome is correct. This might be a reconciled record, a policy-compliant decision, or a response that a responsible person can approve.

Anthropic describes environmental feedback as “ground truth” and says agents need it at each step to assess progress. It also recommends checkpoints and maximum iterations to maintain control. That distinction appears in Anthropic’s explanation of agents.

This gives the team a useful rule:

A model’s confidence is not evidence that the business outcome happened.

If an agent says “the customer has been notified,” what would prove it? A returned message ID? A delivery status? A record in the support system? If it says “the invoice matches the purchase order,” which fields were compared, and where did they come from?

The team does not need a sophisticated measurement system on day one. It does need to answer those questions before it calls the pilot successful. Otherwise, every disagreement becomes a debate about whether the output “looks right.”

Keep this separate from the question of how to build a full evaluation suite. The point here is to teach non-specialists what evidence is and why it matters. Once the team has that vocabulary, it can work with an engineer on the appropriate tests.

4. Learn where the boundaries are

The fourth lesson is boundary literacy. An agent’s risk is shaped by the data it can see, the identities it can use, the tools it can call, and the actions it can take.

Ask the team to mark four boundaries on the process map:

• Data boundary: which records may the agent read, and which must remain out of scope?
• Tool boundary: which systems may it query or write to?
• Decision boundary: which choices may it recommend, and which choices require a person?
• Failure boundary: when must it stop, ask for help, or return the case to the existing process?

Do not rely on a sentence in the prompt to create these boundaries. OpenAI recommends pairing guardrails with authentication, authorization, access controls, and standard software security. It also suggests rating tools by read versus write access, reversibility, required permissions, and financial impact. Those safeguards are described in OpenAI’s guide.

Anthropic’s warning is useful here: agent autonomy can bring higher cost and the possibility of compounding errors, which is why it recommends sandbox testing and appropriate guardrails. Read the qualification in the agents section.

The team should also learn the difference between privacy, security, and business risk. A document may be allowed to enter a model but still be too sensitive for a particular workflow. A technically secure integration may still be authorized to make a business decision that the company has not agreed to delegate. A reversible action may still damage trust if it sends the wrong message to a customer.

This is not a reason to freeze. It is a reason to start with a smaller authority boundary than the demo suggests.

5. Learn how the system will improve

The fifth lesson is improvement literacy. The first version will meet cases the team did not anticipate. The team needs a way to learn from those cases without turning every exception into an undocumented prompt edit.

Teach people to record:

• the input or situation that caused confusion;
• the action the agent proposed or took;
• the evidence it used;
• the expected action or outcome;
• the rule, document, tool, or boundary that needs to change;
• who owns that change and how it will be checked.

NIST describes AI risk management as a continuous lifecycle, with governance infused across mapping, measuring, and managing. It also calls for practices that enable testing, incident identification, information sharing, and feedback from relevant actors. The AI RMF Core lays out those lifecycle expectations.

ISO/IEC 42001 uses a management-system framing for similar reasons. Its official description treats responsible AI use as organizational policies, objectives, and processes that are maintained and continually improved, not as a one-time technical purchase. ISO’s overview of ISO/IEC 42001 is a useful reference for leaders who need to connect an agent pilot to the wider operating model.

The practical rule is simple: every pilot needs an owner for the next improvement. If everyone can report a problem but nobody can change the process, the team is collecting frustration, not learning.

A 5P Agent Brief for the first pilot

The following is an original synthesis for team preparation. It is not an industry standard, benchmark, or legal checklist. Complete it before choosing a vendor or granting the agent access.

PURPOSE
What business outcome should improve?
Who benefits, and who could be affected?
What is the current baseline: volume, delay, effort, or rework?

PROCESS
What starts the work?
What are the normal steps and important exceptions?
Which systems and documents contain the needed context?
What event proves that the work is complete?

PROOF
What evidence shows that the agent understood the case?
What evidence shows meaningful progress?
What evidence confirms the business outcome?
What must a person inspect before accepting the result?

PERMISSIONS
What data may the agent read?
What tools may it call?
Which actions are draft-only, approval-required, or forbidden?
What makes it stop and return control to a person?

PEOPLE
Who owns the workflow?
Who operates the agent day to day?
Who owns the technical integration and access?
Who handles exceptions and incidents?
Who decides whether the pilot continues, changes, or stops?

The brief is useful because it forces the team to name missing information. A blank answer is not a paperwork failure. It is a discovery result.

For example, a hypothetical operations team might propose an agent that reads incoming supplier emails, finds the related purchase order, prepares an exception summary, and drafts a reply. The 5P Brief could reveal that the team agrees on the purpose but not on what counts as a matching purchase order, which supplier data may be sent to the model, or who can approve a reply that changes a delivery commitment.

That is progress. The team has found the work that must be clarified before an agent can safely help.

Run a 90-minute learning workshop

You do not need a large AI curriculum to begin. You need the right people in the same room with one real workflow.

Minutes 0-15: agree on the vocabulary

Define “agent,” “assistant,” “tool,” “approval,” “evidence,” and “owner.” Ask each participant to describe the proposed system in one sentence. If the descriptions differ, resolve the difference before discussing technology.

Minutes 15-35: map the current process

Use a real but low-risk workflow. Draw the trigger, normal path, exceptions, systems, handoffs, and completion event. Ask the person who does the work to correct the map. A process map created only by leadership is usually a plan, not a description.

Minutes 35-50: mark delegation levels

Label each proposed agent behavior as advice, preparation, or action. Circle every action that affects a customer, a financial record, an employee, an external message, or a hard-to-reverse state.

Minutes 50-65: define proof and stopping points

For each important step, write the evidence the agent should receive and the evidence a person should inspect. Add a stop condition for missing context, conflicting records, repeated failure, or an out-of-scope request.

Minutes 65-80: complete the boundaries and roles

Fill in the data, tool, decision, and failure boundaries. Name the workflow owner, operator, technical owner, exception owner, and decision-maker. If one person has all five roles, write that down too. Small teams can combine roles, but they should not leave them implicit.

Minutes 80-90: choose the next safe experiment

Choose one of three outcomes:

• Ready for discovery: the team agrees on the workflow and can test an assistant or fixed workflow without granting consequential authority.
• Ready for a supervised pilot: the team has a measurable purpose, available evidence, named boundaries, and an owner for exceptions.
• Not ready: the process, data, authority, or completion signal is still unclear. Improve that foundation first.

This is not a score that turns risk into a number. It is a conversation that turns vague enthusiasm into a decision with reasons.

What each role needs to learn

Different people need different depth. A business team does not become ready because everyone completes the same generic course.

Role	Must be able to answer	Common gap
Executive sponsor	Why this workflow matters, what risk is acceptable, and who is accountable	Treating an agent as a software purchase without an operating owner
Process owner	What good work, exceptions, and completion look like	Assuming the agent can discover unwritten policy
Daily operator	When to trust, question, correct, or escalate a result	Accepting fluent output without checking evidence
Technical owner	Which tools, identities, data paths, logs, and rollback controls exist	Treating prompts as a substitute for authorization
Security, legal, or compliance partner	Which obligations and impact categories apply to the context	Reviewing the model in isolation from the workflow and affected people

NIST’s guidance supports this role-specific approach. Its Playbook asks organizations to define proficiency for operators and practitioners and develop training about system performance, limitations, and negative impacts. See the NIST Map guidance.

If your organization is subject to the EU AI Act, Article 4 says providers and deployers must take measures toward sufficient AI literacy for staff and others operating or using AI systems on their behalf. The required level depends on the people’s technical knowledge, experience, education, training, the context of use, and the people affected. Read the text on EUR-Lex. This is a legal requirement with scope and interpretation questions, not a universal course outline. Get qualified advice for your situation.

What should the team not learn first?

Do not make model internals, prompt tricks, or a particular orchestration framework the first lesson. Those topics can matter later, but they are downstream of the business questions.

The team should also resist three seductive shortcuts:

1. Starting with a broad role. “Run customer operations” is too vague to teach, contain, or own. Start with one workflow and one outcome.
2. Confusing access with competence. A connected agent is not a trained team. People still need to understand the process and the system’s limits.
3. Using fluency as proof. A polished answer can be useful, but it does not show that the right record was read, the right policy was applied, or the intended action happened.

The goal is not to make the team suspicious of every output. It is to make checking normal and specific.

Use the checklist before access is granted

Treat each line as a conversation prompt, not a compliance score.

• [ ] We can describe the current workflow without mentioning a vendor.
• [ ] We have named the business outcome and current baseline.
• [ ] We know which parts are advice, preparation, and action.
• [ ] We know what evidence proves progress and completion.
• [ ] We have identified important exceptions and missing-context cases.
• [ ] We have named the data, tool, decision, and failure boundaries.
• [ ] We know which actions are forbidden and which need approval.
• [ ] We have named a workflow owner and an exception owner.
• [ ] We have a way to record failures and assign improvements.
• [ ] We can run the first experiment without affecting the live outcome.

If the last box is impossible, reduce the authority of the experiment. A read-only or draft-only version can still teach the team where the process is unclear.

Once the team has completed the brief, you can move into the next question: whether the workflow needs an agent at all, how to evaluate a proposed system, and how to operate it responsibly. Those are separate decisions. The decision guide for choosing an agent versus simpler automation is the next useful read; the AI learning page is a better next step if your team needs a tailored lesson plan.

The best first lesson is not “how to make an agent autonomous.” It is how to make responsibility visible. When the team can explain the work, the delegation, the proof, the boundaries, and the owners, it has learned enough to begin a small, supervised experiment. When it cannot, the honest next step is to learn the process first.