Every company that has tried AI agents has a demo it's proud of and a pilot it stopped talking about. The difference between the two usually isn't the model. It's which job the agent was given, and how carefully that job was designed.

This is a guide to getting your first agent into real, daily use inside your company. It is deliberately unglamorous. The fastest way to build confidence in agents across an organization is to start with work so ordinary that nobody would put it in a keynote.

First, what we mean by an agent

A chatbot answers questions. An agent does work. The practical difference is that an agent can take actions through tools: read an inbox, look up a record, fill in a form, update a ticket, draft a document, send something for approval. It works in a loop. It looks at the situation, decides on a next step, takes it, checks the result, and continues until the job is done or it needs a human.

That loop is what makes agents useful, and it's also what makes them risky. A chatbot that gets something wrong gives you a bad answer. An agent that gets something wrong can take a bad action. So the design question is never just "can the AI do this?" It's "what is this agent allowed to do, and what happens when it's unsure?"

Why most first agents stall

When agent pilots fail, they tend to fail in a few predictable ways.

  • The use case was chosen to impress, not to run. A board-friendly demo, like an agent that "handles customer escalations end to end," touches too many systems and too many judgment calls to ever leave the lab.
  • Nobody owns it. IT built it, the business was consulted, and when it made its first mistake, no one had the authority or the interest to fix the process around it.
  • The process was never written down. The agent was asked to automate how the team works, but how the team works lived in three people's heads and differed between them.
  • Permissions were an afterthought. Either the agent could do too much, and security shut it down, or it could do so little that it saved no one any time.
  • There was no baseline. Without knowing how long the task took before, nobody could prove the agent helped, so the project lost its budget at the next review.

Every one of these is a design problem, not a technology problem. That's good news, because design problems can be solved before you write a line of code.

The boring-first rule

Your first agent should do a job your team finds tedious, does often, and could explain to a new hire in ten minutes.

We use a simple four-question filter for picking a first agent. A good candidate says yes to all four.

  1. Is it frequent? A task done dozens of times a week gives the agent enough repetitions to be worth building, and gives you enough examples to judge it quickly.
  2. Is it mostly rules? The best early tasks follow a pattern with a handful of known exceptions. If the work depends on reading a room or negotiating, save it for later.
  3. Is the blast radius small? If the agent makes a mistake, how bad is it, and how quickly would you catch it? A misfiled document is recoverable. A wrong payment is not.
  4. Can you measure it? You should be able to say how long it takes today, how often it's redone, and what "done correctly" looks like.

Tasks that tend to pass this filter include sorting and routing incoming requests, extracting fields from documents into a system of record, preparing first drafts of routine correspondence, reconciling two lists that should match and flagging the ones that don't, and turning meeting notes into tasks in your project tool. None of these are exciting. All of them eat hours.

Write the agent a job description

Before anyone builds anything, write down the agent's job the way you would for a new employee. It forces the clarity that most failed pilots skipped. A useful job description for an agent covers six things.

The agent job description

  • Purpose: the one outcome this agent is responsible for, in a sentence.
  • Inputs: where work arrives from, and what it looks like when it arrives.
  • Tools: the systems it can read from and write to, listed explicitly.
  • Authority: what it can do on its own, what needs approval, and what it must never do.
  • Escalation: the conditions under which it stops and hands the work to a named person.
  • Definition of done: how you'll know a single task was completed correctly.

The authority section deserves the most care. We find it helps to think in four levels. At the first, the agent can only read: it gathers information and summarizes it. At the second, it can draft: it prepares the action, and a person reviews and sends it. At the third, it can act with approval: it does the work, but an approval step sits in front of anything consequential. At the fourth, it can act, with a person reviewing a sample after the fact.

Nearly every first agent should start at level two. Drafting gets you most of the time savings, because preparing the work is usually the slow part, while keeping a human hand on every outcome. Agents earn their way up the levels with evidence, not enthusiasm.

Design the handoffs, not just the agent

An agent doesn't replace a process. It becomes a participant in one. That means the most important design work happens at the edges: where work reaches the agent, and where it leaves.

Ask where the agent's drafts will appear, and whether that's somewhere your team already looks. An agent that produces excellent work into a folder nobody opens will be abandoned in a month. Ask how a person will tell the agent it got something wrong, and whether that correction will actually improve its instructions. Ask what happens to the work the agent escalates: does it land in a queue with an owner, or in a void?

The companies that get lasting value from agents treat these questions as part of the build. The ones that don't end up with a clever system and an unchanged workday.

A worked example: invoice intake

Consider a finance team that receives vendor invoices by email, in every format imaginable. Today, a team member opens each one, finds the vendor, checks it against the purchase order, keys the details into the accounting system, and flags anything that doesn't match.

Run it through the filter. It's frequent. It's mostly rules: match the vendor, match the PO, check the amounts. The blast radius is manageable if nothing gets paid without a human. And it's measurable: time per invoice and the rate of corrections are easy to track.

The job description might read: the agent reads the invoices inbox; extracts vendor, invoice number, date, line items, and total; looks up the matching purchase order; and prepares an entry in the accounting system as a draft. If everything matches within tolerance, it marks the draft ready for approval. If anything doesn't match, or the vendor is new, or the document is unreadable, it routes the invoice to the accounts payable lead with a short note explaining why. It never approves or pays anything.

Notice what that design does. The agent takes on the tedious part, which is reading, finding, and keying. The judgment stays with the person who already owns it. And every exception teaches you something about the process you can fix upstream, like a vendor who always omits PO numbers.

Roll it out in three stages

We recommend moving every new agent through three stages, with a clear bar for leaving each one.

Shadow

The agent runs alongside the team on real work, but its output goes nowhere. You compare what it would have done with what people actually did. This is where you find the gaps in your instructions and the exceptions no one mentioned. Leave shadow mode when the agent's output matches your team's on the large majority of routine cases and its misses are ones you understand.

Supervised

The agent's drafts go into the real workflow, and a person reviews every one before it takes effect. Track how often reviewers accept drafts unchanged, edit them, or reject them. Leave this stage when reviewers are mostly clicking accept and the edits they do make are small.

Audited

For the categories of work where the agent has proven itself, let it act, and review a sample after the fact. Keep approval gates on anything consequential. Keep watching the escalation rate: if it suddenly rises, something upstream has changed.

What to measure

Measure the process, not the model. Before the agent starts, capture a baseline for four things: time spent per task, the rate at which work has to be redone, how long work waits between steps, and how often exceptions occur. Then measure the same four things at each stage.

Waiting time is the one most teams forget. In many processes the work itself takes minutes, but it sits in someone's queue for days. An agent that picks work up the moment it arrives can shorten the whole cycle even when it saves only a little effort per task.

The agent is the easy part

The technology for building capable agents is widely available now. What isn't available off the shelf is a clear understanding of how your work actually flows, where it gets stuck, and who should decide what. That's the real work of deploying agents, and it's why the first one matters so much.

Get one boring agent into daily use, with an owner, a baseline, and a clear set of permissions, and you'll have something more valuable than a demo. You'll have a pattern your company can repeat.