How to Scope an AI Agent Before You Build It: A Forward Deployed Engineer's Playbook

It's 11 PM on a Friday and the founder messages you: “We need to build something with AI.” The reflex is to open an editor. The forward deployed engineer's job is to do the opposite — to scope the AI agent before a single line is written. Scoping is where most AI projects are quietly won or lost, long before the model is ever chosen.

To scope an AI agent means answering four questions in order: Is this a real problem? Which version of it is worth solving? How risky is it to hand to an AI? And how hard is it to wire into the systems that already exist? Get those right and the build is almost mechanical. Skip them and you ship a clever demo nobody needed. Here is the playbook I use, walked through one example: FoodFix, a food-delivery company drowning in support tickets.

#Step 1: Ask whether it's actually a problem

The first move is not technical. When that Friday-night message lands, the right response is a question: is this a real customer requirement, or an idea that sounded good at 11 PM? Most engineers build what they're told. A forward deployed engineer decides what's worth building — that gap is the whole role. Scoping starts by refusing to treat “build something with AI” as a spec.

FoodFix had a concrete pain underneath the vague ask. Twenty-five support agents, each handling about six queries an hour — roughly 150 conversations of capacity. At lunch and dinner, demand blows past that and wait times balloon. That is a real, measurable problem. “Build something with AI” was not; “cut peak-hour wait time” was.

#Step 2: Break the “why” into categories

Before you can automate support, you have to know why customers open a chat in the first place. Lumping every ticket into “support” hides the structure. At FoodFix the reasons broke cleanly into four buckets:

• Delivery issues — late, missing, or wrong-status orders
• Food quality — cold, spilled, or inedible food
• Wrong or missing items
• Payment — refunds, coupons, and billing questions

Categorizing is not busywork. Each bucket has a different volume, a different cost to handle, and — crucially — a different level of risk if you let an AI handle it. You cannot prioritize what you have not separated.

#Step 3: Quantify volume × load × AI risk

This is the heart of scoping, and the step most teams skip. For every problem area, collect data points: how many of these come in per day (volume), how much effort each one takes a human (load), and how dangerous it is to let an AI answer it (AI risk). Put it in a table.

Volume and load tell you where the pain is. AI risk tells you where you're allowed to start. Answering “is a refund even possible under your policy?” is a read-only, low-risk task — the agent looks something up and explains it. Actually issuing the refund, or stating a policy it half-remembers, is high-risk: get it wrong and you've made a promise the company has to honor.

That risk is not hypothetical. In 2024 a tribunal ordered Air Canada to honor a refund policy its support chatbot had simply invented; the airline argued the bot was a separate entity and lost. The lesson for scoping: the first thing you automate should be high-volume and low-risk. At FoodFix that's refund-policy questions — 350 a day, heavy load on agents, but low risk, because the agent only has to read the policy and explain it, never decide it.

If this looks like RICE with an extra column, that's exactly right — it's the same prioritization discipline applied to AI, where “risk” earns its own axis because a wrong answer can be a legal liability, not just a bad feature. (I break down RICE and how an FDE prioritizes separately.)

#Step 4: Map the system before you commit

Forward deployed engineers are technical people, and scoping has to account for integration complexity — not just the idea. A problem that's perfect on paper can be a nightmare to wire in. So before committing, map where the agent would actually live.

At FoodFix, a customer message flows from the app to a chat UI that opens a ticket, into the ticket database, then into a human queue and an agent dashboard. The agent dashboard is the natural insertion point: it already has the integrations a human agent uses — policy, payment, delivery, and coupon databases, plus chat history. Dropping an AI there means it reads the same context a person would and either replies or raises a refund, coupon, or escalation. Choosing that seam is a scoping decision; it's the difference between a two-week build and a two-quarter one.

#Step 5: Only now, design the agent

Notice we haven't talked about the LLM until now. That's deliberate. With the problem chosen and the integration mapped, the core loop is almost boring: the user's message goes to an LLM, the LLM responds. The craft is in the three decisions around that loop — what you put in the context window, which actions you let the agent take, and when it hands the conversation back to a human.

#What goes in the context window

Context is what separates a grounded agent from a confident liar. Don't dump the entire chat history — include only the last handful of messages (six is a reasonable default) so the model can resolve references like “my order” without drowning in tokens or cost. Then retrieve the policy documents relevant to the question and put them in the context, so answers are grounded in FoodFix's actual rules rather than the model's imagination. That's retrieval-augmented generation, and whether you even need an LLM at all is its own decision. Grounding the agent in real policy is also what keeps a refund-policy bot on the low-risk side of the line, instead of inventing policy the way Air Canada's did.

# What the agent sees on every turn — scoped, grounded, bounded
context = [
    system_prompt,                        # rule: answer ONLY from the policy below
    *chat_history[-6:],                   # last 6 messages, not the whole thread
    retrieve(policy_docs, query=user_q),  # RAG: only the relevant policy chunks
]

# Actions the agent may take — start read-only, expand as it earns trust
tools = [
    lookup_order, lookup_policy,          # reads  -> low risk, ship first
    # issue_refund, apply_coupon,         # writes -> high risk, add later, gated by approval
]

#Which actions the agent can take

Next, decide which actions the agent can take — and scope them to the risk tier you set in Step 3. A refund-policy agent should start read-only: it can look up an order, read the policy, and explain what applies, but it does not issue the refund itself on day one. A safe progression climbs one rung at a time — first it answers questions; then it drafts a reply or a refund for a human to approve with one click; only once it has earned trust does it take the write action on its own. Each rung is a deliberate scoping decision, not a default the framework hands you.

#When the agent hands off to a human

Finally, design the handoff. An agent that never escalates is exactly how you get an Air Canada moment. Give it a hard rule: answer only from the retrieved policy, and when a question falls outside it — or the model's confidence is low — route the ticket to the human queue instead of guessing. That queue already exists in the system map above; the agent's job is to shrink it, not to pretend it's unnecessary. The bar for a good support agent is simple: resolve the easy majority end-to-end, and hand everything else to a person with the context already gathered.

#An improvement worth scoping next

Scoping doesn't end at launch. An obvious extension at FoodFix: let customers attach a photo of the food. A vision model can look at a picture of a spilled or wrong order and help decide whether a refund is warranted — turning a slow, judgment-heavy category into something the agent can triage. But notice what that does to the table: image-based refund decisions are higher AI risk than answering policy questions, so they belong in a later phase, after the low-risk wins have built trust. The framework tells you not just what to build, but in what order.

#Scoping is the real work

Anyone can wire an LLM to a chat box. The forward deployed engineer's edge is everything that happens before that: turning “build something with AI” into a ranked list of real problems, gated by risk, mapped to the systems that already exist. The model is the easy part. Knowing which agent to build — and which to refuse — is the job.