The Three Questions We Ask Before Building Any Agent

A lot of people are asking about building "an AI agent" right now. Half the time, after we actually talk through what they're trying to do, the right answer is something smaller and simpler.

The filter I've landed on is three questions. I run through them in order, and I don't move on until each one has a real answer. If you're considering an agent — whether you build it yourself or hire someone — these are the questions worth pressure-testing first.

Question 1: What is the agent replacing?

The right answer is specific. "It's replacing the 40 minutes my office manager spends every morning re-keying bookings from email into our scheduling system." Or: "It's replacing the after-hours phone coverage we currently pay an answering service for."

The wrong answer is abstract. "It'll make us more efficient." "It'll help with customer service." Those answers describe a vibe, not a workflow.

Vibes don't survive contact with production.

If you can't name the specific human task or the specific tool you're replacing, you don't need an agent yet. You need to map your process first.

Question 2: Who owns the outcome when it goes wrong?

This one trips people up. Every agent will be wrong sometimes. The question isn't whether — it's who handles it when it happens, and how fast they find out.

If the answer is "the agent will just retry" or "the customer will tell us" — stop. You don't have a real ownership model, you have a hope. Agents need a human owner the same way any other production system does. Someone whose job description includes "the agent's output is my responsibility."

I've seen this fail in my own builds. Errors pile up in a Slack channel nobody reads. The agent keeps doing the wrong thing for days. By the time someone notices, you've got a mess to clean up. The fix is always the same: someone owns it, or it shouldn't ship.

Question 3: What does the agent need access to that it doesn't have today?

Agents are only as good as their reach. An agent that can read your calendar but can't book on it is a glorified search box. An agent that can answer questions about your inventory but can't actually create an order is a chatbot with extra steps.

Make a list of the systems the agent needs to touch. Then ask, honestly:

• Do we have API access?
• Are the credentials managed?
• Is there a sandbox?

If half the list is "we'd need to talk to IT" or "the vendor doesn't have an API," your real first project isn't an agent. It's plumbing.

The good news: the plumbing work pays dividends regardless. Even if you never ship the agent, getting your systems addressable is the foundational investment of the next decade.

The Pattern

Notice what these three questions have in common. None of them are about the model. None of them are about the framework. None of them are about prompts.

The hard part of shipping an agent isn't the AI. It's the boring, organizational, infrastructural work that has to happen around it.

The teams that win with agents won't be the ones with the best prompts. They'll be the ones who answered these three questions before they wrote a line of code.

Using The Answers

If you can answer all three clearly, you're in good shape to start scoping. If you can't, the honest move is to slow down and get to clear answers first — or to admit that this isn't the right project yet, and figure out what is.

That last part is the unglamorous truth. Sometimes the right call is not to build the thing.