Scoping
The single biggest source of wasted time in AI agent projects is a brief that's too vague to build from. When the brief says "automate our customer success process," the implementation team spends the first two weeks asking clarifying questions instead of building. By the time they understand what they're building, half the timeline is gone.
A good brief is one a developer could hand to another developer who has never seen your company — and that developer could start writing code on day one. Here's the format we use to get there.
Start by describing the workflow as a story. Not as a list of requirements, not as a system diagram — a story with a beginning, middle, and end.
Example of a bad workflow description: "We want to automate RFQ processing."
Example of a good workflow description: "Every day, 20-50 RFQ emails arrive in our sales@ inbox. A salesperson reads each one, looks up the relevant pricing in our ERP (we use SAP), checks inventory availability in the same system, writes a quote, and sends a PDF to the customer. This takes about 90 minutes of salesperson time per day. We want an agent that does all of this automatically — reads the email, pulls pricing and inventory, generates the quote, and sends the PDF — without human intervention."
The story version gives a developer everything they need to understand scope: what triggers the workflow, what steps happen, what systems are involved, and what the output looks like.
Every agent needs a trigger — the event that causes it to run. Be specific:
Define what the agent receives and what it produces — with examples.
Inputs: List every piece of data the agent needs to do its job. Include where that data comes from (which system, which field or endpoint). If the data comes in different formats, provide examples of each.
Outputs: Define what the agent produces and where it goes. "An email" is not specific enough. "A PDF attachment sent to the address in the RFQ, CC'd to the sales rep who owns that account in Salesforce, with a copy saved to the customer's folder in Google Drive" is specific enough.
List every system the agent needs to interact with and what it needs to do in each:
Integration inventory is where most briefs fail. Teams list the systems but don't know the API details, don't know who controls access, or don't realize the API they're counting on doesn't have the endpoint they need. Surface these questions in the brief — don't let them surface during the build.
The workflow you described in section 1 is the happy path. Section 5 is about what happens when something goes wrong or the input doesn't match expectations.
For every step in the workflow, ask: what can go wrong here? Common categories:
For each edge case, define the expected behavior. If you don't know what the expected behavior should be, that's a decision to make now — not mid-build.
Define what "working" looks like. This section forces a conversation about quality thresholds before anyone starts building.
Before you hand a brief to an implementation team — or use it to evaluate vendors — apply this test: give it to a colleague who is technically literate but doesn't know your business. Ask them to answer these three questions:
If they can answer all three correctly from the brief alone, the brief is ready. If they have to ask you clarifying questions, the brief isn't done yet.
The extra time you spend writing a clear brief will come back to you in build time, revision time, and the absence of mid-sprint surprises. Every hour of scoping saves three hours of debugging.
Agent Implementations runs a structured scoping process that produces a brief like this in 30 minutes. Book a scoping call — we'll walk you through it.