What is an AI agent? Start with a real job.
What does an AI agent do? Follow one as it prepares a customer meeting brief, with a clear job, the right access and someone to check the result.
Alongside People · 5 min read ·
You have a customer meeting tomorrow. Before you go, you'd like to know what's happened since you last spoke, which requests are still open and what you promised to follow up. Finding all of that takes a bit of digging.
Now imagine giving that preparation job to an AI agent. It looks through the sources you've allowed it to use, follows up on a detail that needs more context and brings you a brief to check. That's a useful way into the subject. We can look at a job we understand and ask how much of it the software could help with.
This meeting example is hypothetical. It also gives us a practical definition: an AI agent is software that uses an AI model to choose some of its next steps and use connected tools to carry them out.
What makes it an agent?
An ordinary reminder can tell you to prepare. A fixed automation can collect the same three fields from your customer system each time. You can also paste notes into a chatbot and ask for a summary.
An agent could take more of the preparation off your hands. Given suitable tools and access, it might find the customer record, read recent notes and look for open requests. If one request refers to an earlier conversation, it could decide to retrieve that conversation before completing the brief.
Choosing that additional step is the useful distinction here. Anthropic describes agents as directing their own steps and tool use, while workflows follow more predefined paths. Products use the terms differently, so treat this as a working definition. Anthropic's explanation goes into more detail.
You'll also hear “agentic AI” or “agentic workflow”. In a business conversation, we ask the person using those terms to show which steps the software can choose and what it is allowed to do. That makes the proposal much easier to discuss.
Give it a job you can recognise as finished
“Prepare me for the meeting” leaves a lot to guess. A useful brief would name the customer and meeting, the period to look at, the sources to consult and what you want back.
For our example, ask for one page covering recent developments, open requests, previous commitments and questions to raise. Important statements should link to their source. Missing information and disagreements between sources should be easy to spot.
Include a few awkward situations. If two customers share a name, the agent should ask which one you mean. If it can't open a source, it should tell you what it couldn't check. If the notes disagree about a promise, it should show the disagreement for you to resolve.
Those instructions help you judge the result as well as helping the agent prepare it. You'll know what you asked for, what you received and where you still need to look.
Access is part of the job
OpenAI describes the foundations of an agent as a model, tools and instructions. Those tools can read information or take actions in other systems. Its agent guide explains the pieces.
For the meeting brief, reading the relevant customer information may be enough. Sending emails, changing agreements and closing support requests are separate responsibilities. Give the agent the access it needs for this job. If you later want it to send a follow-up, decide when it may send, what it must check and which situations need your attention.
The documents it reads need care too. A customer note might contain a mistake or even instructions aimed at the software. The system should treat that material as information to assess, with permissions enforced separately. A sentence in a document must not grant access or change the job.
Set a time and spending limit for a run, and decide who receives a held or incomplete brief. If identity, access or an important source remains uncertain, it should stop and return that question to a person. These controls need to be built and tested; writing them in a prompt does not guarantee they will work.
Someone needs to look after this setup: the sources, permissions, exceptions and record of what happened. Make sure they can inspect a run and stop the process when something needs attention.
You still need to understand the conversation
The brief can save you a search through several systems. You still need to understand it well enough to talk to the customer, check important claims and recognise a gap.
Paul explores that responsibility in In the loop. A person approving a page hasn't necessarily understood the work. For this meeting, you're the one making commitments and dealing with their consequences. The preparation should help you do that well.
A good review might be quite focused: check the open issue, read the source for an important promise, and resolve the question the agent flagged. Design the brief to make those checks easy.
See whether the extra flexibility helps
If a standard report gives you everything you need, use it. An agent becomes more interesting when finding the answer takes different steps from one customer to the next.
Try a small set of meetings, including ones with conflicting notes or missing information. Keep the existing preparation route available. Compare the time spent preparing and reviewing, the errors you find and how useful the brief is in the meeting. Measure the work around the tool too.
You can start exploring agents with a single job like this. Write down what you need, show an example of a useful result and decide what the software may do. Those three things will make the next conversation much more productive.
If you have a job in mind, tell us about it. We can work out a sensible first version together.