How to build AI agents business teams want
Decide if the job needs an agent. Interview the people who do it. Prototype from their answers. Hand your AI team a buildable spec. Start version one on the work nobody wants.
The kickoff meeting for your first business-team agent has a shape you’ll recognize. On one side of the table sits the support team lead. She heard “AI agent” three weeks ago, and she’s been quietly updating her CV since. On the other side sits your data scientist, laptop open, asking the question he always asks: “So, what should the agent actually do? Send me the requirements and I’ll start building.” And in the middle sits you, the product person, holding a mandate from leadership that says agentify support and not much else. Nobody in that room has the spec, and everybody expects you to produce it.
Here’s the thing nobody tells you about that meeting. The spec already exists. It just isn’t written anywhere: it lives in the heads of the people who do the job today, stored in a language no data scientist speaks. What the team’s best performer would tell a new hire on day one? That’s your system prompt. The tabs she keeps open while she works? Those are your tools. The things she’d never let a new hire do alone? Those are your guardrails. Your job isn’t to write the spec. It’s to run the interviews that surface it.
In the previous post I wrote about how to pick the AI agents worth building: point the next one at your team’s real constraint instead of sprinkling agents everywhere. This is what comes after you’ve picked the spot. The whole method fits in one sentence: every component of an agent is the answer to a plain-language question, and version one should only do the work the team would happily give away. The rest is knowing which questions to ask, and in what order.
The whole method runs through one worked example, a customer support team, picked to make every step tangible: swap in finance, sales ops, or HR and the moves stay the same. Here’s the path at a glance.
The gate. I’ll give you the five questions that tell you whether a job needs an agent, a simple script, or nothing at all.
The interviews. Three conversations with a support team, with the exact questions to ask and what each answer is for.
The translation. Every answer becomes a spec component, and you’ll prototype the agent yourself before anyone commits a sprint.
The landing. You’ll see how to scope version one so a team that fears the project ends up asking the agent to do more.
By the end you’ll have the full interview script and the translation table between business answers and agent components. You walk into your next discovery meeting with questions the team can actually answer, and you walk out with a spec your AI team can actually build. There’s no platform to pick: the method works with whatever agent stack your company already chose (Amazon Bedrock AgentCore, Databricks, or something your AI team built themselves), and an AI workspace like Claude Cowork or Claude Code covers the prototype step.
Grab your notebook.
Decide if the job needs an agent
The oldest failure mode in innovation has a name: a solution in search of a problem. A technology shows up, it’s impressive, and whole organizations start asking “where could we use this?” The question is backwards, and the people who build things for a living have been saying so for years. Uri Levine, who co-founded Waze, put the fix on the cover of his book: fall in love with the problem, not the solution. Problems are constant; solutions are just the current best way to serve them. Nobody in your company needs an agent. They need the backlog to stop growing, the customer answered today, the notes written without staying late.
AI mandates invert this by design. “Agentify support” hands you a solution with the problem line left blank, and your own excitement pulls the same direction, because agents are genuinely fun to build. I’ve caught myself doing it: tool first, problem later, demo nobody asked for. So the first discipline of this job is to flip the sentence back. Start from the work, find the problem worth solving, then ask whether an agent is even the right shape of solution. Your job isn’t to bring agents to the business. It’s to bring the business a problem worth solving, with whatever technology fits.
The “right shape” question has a sharp edge to it. Anthropic’s Building Effective Agents draws the line I use in every scoping conversation. A workflow follows a path you script in advance: cheaper, faster, predictable. An agent decides its own path as it goes, and Anthropic reserves that for problems where “it’s difficult or impossible to predict the required number of steps.” In plain terms: if you can draw the flowchart, script the flowchart. An agent earns its complexity only when every case bends the flowchart.
I run every candidate job through five questions before committing to anything. The team can answer all five without a single technical term.
Does the work arrive different every time? If every item looks the same, a script handles it. Variety is the first hint you’re in agent territory.
Does handling it take judgment calls, or rules? If the team can write the rules on a whiteboard in an hour, write the rules into code instead.
What does a wrong answer cost, and can a human catch it in time? High stakes plus no review point means you’re not ready for an agent here, whatever the mandate says.
Does it happen often enough to matter? A judgment-heavy task that shows up twice a quarter never pays back the build.
Can an agent even reach the work? If the job lives in phone calls, hallway conversations, and a cheat-sheet in someone’s drawer, no spec survives contact.
OpenAI’s practical guide to building agents puts it bluntly: validate the use case first, “otherwise, a deterministic solution may suffice.”
Two contrasting tickets show the gate at work.
A password reset arrives identical every time, follows three rules, and costs nothing when retried: script it, done in two weeks.
A refund dispute arrives wrapped in order history, customer tone, and policy exceptions: that’s judgment, that’s volume, that’s agent territory.
The refund example isn’t even mine: OpenAI’s guide names “refund approval in customer service workflows” as its canonical case of agent-worthy work, the kind full of “nuanced judgment, exceptions, or context-sensitive decisions.”
And sometimes the gate says no. Telling a team “you don’t need an agent, you need a script, and it’ll be done in two weeks” feels like walking away from the mandate. It’s the opposite. Saying “no agent needed” when it’s true is the cheapest trust you’ll ever buy, and it’s the reason the next team opens their door when you knock.
For the team you’re about to meet, the gate says yes. Time to walk in.
Run the three interviews
The use case: a support team under a mandate
Time to run the method on something concrete, with you in the driver’s seat. Picture a mid-size B2B software company. A nine-person customer operations team handles order issues, refund disputes, and account changes: roughly sixty cases a day, forty minutes of handling time on an average case, a backlog that grows a little every month, and a hiring freeze. Leadership looks at those numbers and hands you the mandate: “bring AI to support.”
The team lead, call her Claire, runs a team that’s proud of its judgment. They talk customers out of churning every single week. What Claire hears in “agentify support” is a project aimed at her team’s future, and she’s not wrong to hear it that way: plenty of these projects get pitched exactly like that. The fear is rational. Pretending the fear isn’t in the room poisons every interview that follows, so name it in the first meeting and don’t argue it away. You can’t logic someone out of a fear the headlines keep feeding. You can only design the project so the fear doesn’t come true, and let the design speak.
The posture you take matters as much as anything you say. You’re not the expert arriving to optimize anyone. You’re the apprentice, and they’re the master craftsman: you’re there to learn the job well enough to describe it faithfully. An apprentice studies the master’s craft; the master stays the master. That single stance changes what people tell you. Experts perform for auditors. They teach apprentices.
One more reframe before the first interview, this time for leadership. “AI in support” is not a deliverable. A deliverable is a number: minutes back per case, backlog age, first-response time, with quality held steady on the numbers the team already reports, like satisfaction scores and escalation rate. Commit to measuring before and after. An agent without a number attached is a demo, not a delivery.
So you ask Claire for three slots on her team’s calendar, spread over one week: an hour with her at a whiteboard, ninety minutes with her two best people, and half a day sitting behind someone while they work. Plus ten recent cases: good, bad, and ugly.
The interview format descends from contextual inquiry, a research method Hugh Beyer and Karen Holtzblatt developed at Digital Equipment Corporation in the late 1980s. Its core instruction: study the work as it happens, not the process as documented, in the posture of an apprentice learning a craft. Every team has a standard operating procedure, the SOP: the official document that says how the work is supposed to run. It describes the happy path, and the job lives in the exceptions. Never ask a business team “what are your requirements?” Nobody who does real work can answer that question. Ask about last Tuesday instead.
Three conversations, three different jobs. Here’s the map.
Interview 1: map the job
One hour with Claire and a whiteboard. The goal is the map, not the details. Five questions do the work:
”Walk me through what happens between a case landing and a case closing. Whiteboard-level.”
”Where does the time actually go? Not where the process doc says. Where it really goes.”
”Which cases does your team dread? Which ones do people fight over because they’re interesting?”
”What work would your team happily never do again?”
”What numbers do you already report on?”
One hour of those questions produces something like this on the whiteboard.
Each answer has a destination:
The walkthrough becomes the workflow skeleton.
The where-does-time-go answer becomes your pain heatmap.
The dread-versus-fight-over answer tells you what the team wants to keep, which matters more than what they want to lose.
The last question hands you a value baseline without building a single new dashboard.
And the “happily never again” question is the one to listen hardest to, because its answer becomes version one. For Claire’s team the answer is unanimous: the case wrap-up notes. Every closed case needs a summary in the CRM, the customer database where every interaction gets logged. Everyone writes them badly at 6pm. Nobody reads them until they desperately need them. Hold that thought.
Interview 2: learn the craft
Ninety minutes with the two people Claire names as her best: Marco, eight years on the team, and Ana, three. Screens open, real cases on them. This is where the agent’s actual behavior gets specified, one plain question at a time:
”Show me the last case that took you over an hour. Click through it exactly as you did.”
”What would you tell a new hire on day one that isn’t written anywhere?”
”What’s open on your screen while you work a case?”
”What do you find yourself re-explaining or re-looking-up, case after case?”
”When do you stop and pull in Claire or another team? What’s the trigger?”
”What would you never let a new hire do alone in their first month?”
The answers are the spec, verbatim. Marco’s day-one rule: “if the customer mentions a deadline, handle it today, even if the queue says otherwise.” That sentence goes straight into the agent’s instructions. His open tabs: the CRM, the order database, and the refund policy wiki page, which is outdated, and everyone knows exactly which parts to ignore. Write down which parts they ignore. That’s institutional knowledge no document holds. Then Ana pulls a laminated cheat-sheet out of her desk drawer, and that’s when you know the interview is working. Every team has one. It’s never in the wiki. And the never-alone list arrives without hesitation: refunds above a threshold, anything that smells legal, and any promise about delivery dates.
Interview 3: shadow the work
Half a day sitting behind Marco and Ana while they work real cases. No questions this time. You’re watching for the gap between the process document and the craft: the case that needs an actual phone call to the warehouse, the customer Ana recognizes as burned-twice-before from memory because the CRM has no field for it, the moment Marco overrides the policy page because he knows it’s stale. None of that appears in any SOP, and all of it decides whether an agent succeeds or embarrasses you.
You leave the shadow session with ten annotated real cases: the input, what the human did, and what “good” looked like. Those ten cases are the most valuable artifact of the entire discovery, because they become the test set your AI team grades the agent against. One honesty note: your three interviews will surface completely different specifics than these. The questions transfer. The answers won’t. That’s the point of asking.
Three conversations, one notebook full of plain-language answers. Now comes the translation.
Turn the answers into a buildable spec
Write the seven components
An agent spec has seven components. Here’s the part that surprises people: the team just answered all seven, and nobody in the room had to learn a single AI term. Five components come straight from interview answers, and the remaining two get derived from those five.
Instructions: the agent’s system prompt. This is the day-one advice, the rules of thumb, the tone. It comes from ”what would you tell a new hire that isn’t written anywhere?” Marco’s deadline rule goes into the prompt word for word. Collect the rules as the team says them, not translated into corporate language, because the best performer’s voice is the spec. Your data scientist will thank you: half of prompt writing is knowing what the expert actually does.
Tools: what the agent can look at and what it can do. Every tab open during the walkthrough is a read-tool candidate. Every action taken is a write-tool candidate. The split matters because it maps directly to risk: letting the agent read the order database is cheap to grant, letting it issue a refund is not. Version one gets read access to the CRM, the order database, and the policy wiki, and exactly zero write actions.
Memory: what the agent keeps between cases. This comes from ”what do you keep re-explaining?” and from Ana’s burned-twice customer. Three plain kinds cover most teams: facts about repeat customers, resolutions that worked before, and this-week context like a known shipping outage. The spec says what to remember in the team’s words, and the AI team picks how to store it. Skip the vector-database vocabulary entirely; it has no place in a spec meeting.
Workflow: the path a case takes, where the agent sits, and what wakes it up. Interview 1’s whiteboard map plus the walkthrough give you the steps. Now mark each step with one of three labels: script it, agent judgment, or human only. The gate from earlier applies per-step here, not per-project, and most “agent” projects turn out to be a workflow with two or three genuinely agentic steps inside. Then name the trigger, because it’s the first thing your AI team will ask: what invokes this thing, an event, a schedule, or a person? Version one’s trigger is one line: the agent wakes when the human closes the case.
Model: the brain you rent. The business chooses a model without ever hearing a model name, by answering three questions: how much judgment does a case take, how fast does the answer need to come back, and what’s a case worth in money? Capability, latency, cost. Your AI team maps those three answers to an actual model tier, and your job is keeping the trade-off honest when someone wants the premium model for wrap-up notes.
Guardrails and escalation: what it must never do alone, and who it calls. The never-alone list transfers verbatim: refunds above the threshold, legal-adjacent language, delivery-date promises, always a human. Escalation deserves the same respect: the trigger points from ”when do you pull in Claire?” become the agent’s own escalation rules. An agent that says “this one’s for you, here’s the file so far” earns trust faster than one that guesses, so spec escalation as a feature, not a failure state. Add one more spec line to this bucket: every agent action gets logged and is reviewable. The weekly review you’re about to set up depends on those logs existing, and legal will ask for the trail before anything launches.
Evals: how everyone knows it works. The ten annotated cases from the shadow session plus the metrics Claire already reports. The launch bar is simple: the agent drafts wrap-up notes for the ten golden cases, and Claire grades them blind against the human-written ones. Hamel Husain, whose evals guide is the one practitioners pass around, puts the stakes plainly: “Unsuccessful products almost always share a common root cause: a failure to create robust evaluation systems.” The evals aren’t the homework at the end of the project. They’re the first thing your AI team builds.
Now notice what just happened. The team wrote the spec. Nobody said “prompt engineering.” Nobody explained embeddings. Your entire contribution was asking questions about last Tuesday, sorting the answers into seven buckets, and reading them back until Claire said “yes, that’s the job.”
A spec in plain language, ready for builders. Almost. There’s one move left before the hand-off, and it’s the one that separates today’s product work from requirements-era product work.
Prototype the agent yourself
Here’s the gap in everything so far: three interviews captured what the team says about the work, and the shadow session caught some of what they do. Neither tells you how they’ll behave with the agent itself. Will Marco trust the draft, edit it, or quietly go back to writing notes his way? No document answers that, and a longer spec answers it least of all. In classic product work you already know the move: you don’t write a requirements document for a website and send it to developers. You click together a prototype in Figma or a no-code tool, put it in front of five users, and watch. Agents just got the same unlock: with AI coding tools, prototyping the agent is now cheaper than the meeting about the spec. Here’s the loop.
So before handing anything to the AI team, build the smallest thing that behaves like the agent. In Claude Cowork or Claude Code, it’s an afternoon of work. Write the instructions component into a skill, with Marco’s rules verbatim. Drop the ten golden cases in as files. Ask it to draft the wrap-up note for each one. No connectors, no permissions, no access requests: copy-paste stands in for every tool the real agent will get. What comes out reads like the future agent’s output, and the output is the only part the team can judge anyway.
Then test it like a product prototype, not like a demo. Run the sessions on the five-act interview the structure Google Ventures uses to test design sprint prototypes: a friendly welcome, a few context questions, introduce the prototype (”it’s cardboard, you won’t hurt my feelings”), real tasks, then a short debrief. Hand Ana a fresh case, let her work it, show the prototype’s note next to hers, and watch. The watching surfaces what three interviews didn’t: every note the team actually trusts ends with a who-to-call line, and nobody thought to say it out loud. The spec gains its most important line from twenty minutes of watching, not from any question you asked. There’s always a gap between what people tell you and what they do, and it closes only in front of something real.
The prototype doesn’t replace the spec, it hardens it. The spec still tells your AI team what to build. The prototype proves the team will use it, catches misreadings while they’re an afternoon cheap, and hands your data scientist a tested first draft of the prompt instead of a blank page. And the fearful room from the kickoff has now touched the thing, shaped it, and seen it stay a drafting assistant. The hand-off package just gained its most convincing item.
Hand it to your AI team
The hand-off package is six things, and none of them is a forty-page document. One page per spec component, in the team’s own words plus the derived decisions. The ten golden cases with the human answers attached. The prototype with its feedback log: what the team reacted to and what changed. The access list: which systems, read or write, granted to whom. The value baseline from Interview 1. And the escalation contacts with their triggers. That package answers most of the questions a AI team otherwise burns weeks discovering one standup at a time.
Each role picks up a different end of it. The data scientist starts from component seven: the golden cases become a test harness before anyone writes a prompt, which is exactly the order Husain’s evals-first practice prescribes, and the prototype’s skill file gives them a first prompt draft that already survived contact with the team. The data engineer starts from component two: connectors, permissions, logging. And you stay in the loop as the translator, running one ritual that outweighs everything else: a weekly transcript review, with someone from the support team in the room. Marco reading the agent’s attempts catches misreadings in days. Without the business in the review loop, misreadings surface at launch, in front of customers, with the team’s name on the queue.
Somewhere in that first planning meeting, you’ll get the pushback. It usually sounds like this: “Why all this ceremony? The process is documented. We can spec from the SOPs and ship this quarter.” Take it seriously, because it’s half right: the SOP is real and useful. It’s also only the happy path. The value and the risk both live in the exceptions only the team can name: the stale policy page, the burned-twice customer, the warehouse phone call. An agent spec’d from documentation automates the part that was never the problem, and breaks publicly on the part that is. And it breaks in front of a team that was never asked, who now has every reason to let it fail. That’s not a hypothetical. MIT’s Project NANDA studied hundreds of enterprise GenAI initiatives in 2025 and found most fail from “brittle workflows, lack of contextual learning, and misalignment with day-to-day operations”: the documentation-spec’d agent, described in one sentence. One week of light discovery, against a quarter of rebuilding. That’s the whole trade.
One last thing about the spec itself: it’s a living contract, not a document you sign once and file away. When the AI team hits an ambiguity, and they will (”what exactly counts as legal-adjacent?”), the answer is another fifteen minutes with Marco, not a guess hidden inside a sprint. The interviews don’t end at discovery. They just get shorter.
The build is underway. Now the part most agent projects skip until it’s too late: getting a team that fears the thing to want the thing.
Start with the work nobody wants
Go back to Claire’s face in that kickoff meeting. You don’t fix that with a slide about how AI augments people. Nobody who’s afraid has ever been reassured by a slide. You fix the fear with scope.
The move: version one does only the work the team would happily give away. Remember the unanimous answer from Interview 1: the wrap-up notes. So version one drafts the case summary after the human closes the case. It talks to no customer. It makes no decision. It sends nothing. Every person on the team keeps every bit of their judgment, and everyone loses their least favorite chore the same week. The French have a name for this kind of maneuver: cheval de Troie, the Trojan horse. Except this horse gets welcomed for what it visibly removes, not for what it hides. There’s no deception in it. The full ladder is printed on the side.
Be honest about version one’s number, because it’s small on purpose. Five minutes of note-writing per case, sixty cases a day: call it five team-hours back daily, plus CRM notes that people can finally use. That’s real, and it’s nowhere near the handle-time and backlog numbers from the value conversation with leadership. Say so plainly. The small number is the design: a small verified win buys the trust, and the patience, for the versions that move the big metrics. A demo impresses for a week. A chore that stays gone convinces forever.
There’s a principled version of “work nobody wants,” and it comes from Google’s site reliability engineering book, in a chapter by Vivek Rau. He calls it toil: work that’s “manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” Read that list back against the wrap-up notes and every box ticks. The scales-linearly attribute even loops back to the volume question in the gate: toil grows with the business, which is exactly why automating it compounds. Every business team has a toil pile, and they can name it in five seconds when you ask, which is why the “happily never again” question sits in the very first interview.
From there, the agent climbs a ladder, and the ladder has a rule.
Rung one drafts the documentation after decisions are made.
Rung two pre-assembles the case file before the human opens it: order history, past tickets, the relevant policy section.
Rung three suggests a response the human edits and sends.
Rung four handles one narrow, routine category end to end, with humans reviewing a sample.
The rule that makes this change management instead of scope creep: each rung happens when the team asks for it, not when the roadmap says so. Three weeks after launch, Marco asks why the agent can’t also pull the order history before he opens a case. That’s rung two, requested from the floor. And the ladder isn’t a trick I invented: it walks the classic automation-staging model that Parasuraman, Sheridan and Wickens formalized in 2000, from information gathering, to suggested decisions, to supervised action.
Two failure modes need naming, because the happy path above is only one data point. First, the stall: if nobody asks for rung two by month two, that’s data, not patience. It almost always means version one missed the actual most-hated chore. Rerun the “happily never again” question and re-aim; the miss costs weeks, not quarters. Second, the squeeze: leadership pushing the mandate faster than the floor pulls. The version-one number is what buys you the time. Report the small win monthly, and name the next rung’s trigger out loud: “we expand when the team asks, or when note quality holds for four weeks.” A named trigger turns “when will it do more?” into a measurable answer.
One caveat at the top rung. Lisanne Bainbridge’s “Ironies of Automation” (1983) showed that automating the routine work erodes exactly the skills humans need for the hard cases that remain. The fix belongs in the spec, not in a values statement: humans keep a rotation of routine cases, not just a review sample. The team stays sharp, and the agent stays supervised by people who still know the craft.
A few smaller moves compound alongside the ladder. Let the team name the agent; named things belong to the namer. Keep someone from the team in the weekly transcript review. Publish what the agent can’t do, the guardrail list, as prominently as what it can. And measure the team’s time back, never individual productivity: the first dashboard that ranks humans against the agent ends the whole experiment. When someone above you asks how you’re rolling out agents, here’s the paragraph to hand them:
Before we build any agent, we run three interviews with the people who do the job. The spec falls out of the answers: what they’d tell a new hire becomes the instructions, what they look at becomes the tools, what they keep re-explaining becomes the memory, what they’d never let a new hire do alone becomes the guardrails. We prototype it ourselves and test it with the team before the AI team commits a sprint. And version one starts on the work they’d pay to stop doing. The agent earns the interesting work later.
One team, one number, one chore removed. That’s how agent programs actually start.
Run your first interview this week
The mandate said “agentify support.” What you delivered is narrower than the slide-deck version, and better: one team’s least-loved work removed, a prototype-tested spec the AI team built from directly, a small number that verifiably moved, and a support team asking what the agent can take on next. Delivering an agent to the business doesn’t mean delivering a platform. It means delivering a working relationship, between a team and a system it helped design.
The method travels as-is to any team whose work passes the gate. Finance, running invoice exceptions: version one drafts the dispute-resolution notes. Sales ops, answering RFPs (the long questionnaires big customers send before buying): version one drafts the compliance boilerplate everyone hates. HR, fielding onboarding questions: version one drafts FAQ answers from already-resolved tickets. Legal intake, triaging contract requests: version one pre-fills the intake summary. Marketing, reporting: version one drafts the weekly performance commentary. In every case the pattern holds: the interviews find the toil, the toil defines version one, and the team pulls the agent up from there.
So here’s the move for this week. Pick one team. Ask their lead for one hour and ten recent cases. Open with ”what work would your team happily never do again?” and write down everything that comes after. You’ll leave the room holding most of a spec, and the team will walk you to the door.
Your next agent is three conversations away.