Design Before You Code: Scoping One Agent's Job
Lesson 2 — The most expensive mistake in agent projects happens before anyone writes a line of code: scoping an agent that tries to do everything. Here's how to define one agent's job so precisely that the build itself becomes almost mechanical.
Prerequisites
- Lesson 1: Your BTP toolbox
The most expensive mistake in an agent project happens before anyone writes code. It’s the kickoff where someone says “let’s have it handle Business Partners, and also Sales Orders, and maybe invoices while we’re at it” — and three sprints later, the team is debugging an agent that does five things adequately instead of one thing well.
This lesson comes before any code on purpose. The highest-leverage decision in this whole journey is the one you make right now.
Start from the outcome, not the API
Don’t ask “which OData service should I expose?” Ask: what does a business user want to accomplish, in one jargon-free sentence? “Check whether a customer’s order shipped.” “Create a new supplier record.” Each is a real agent’s job. “Handle master data” isn’t a job — it’s a department.
The one-sentence test: if you described this agent’s purpose to the person who’ll actually use it, would they recognise it in one sentence? Need “and also” more than once? You’ve scoped two agents.
Every job is three honest lists
Why narrow beats broad, every time
| Narrow agent | Broad agent | |
|---|---|---|
| Testing | Small, enumerable space of behaviour | Too many combinations to truly cover |
| Governance | Short, defensible authorization list | ”Basically everything” — hard to defend |
| Client buy-in | One sentence, sponsor champions it | Vague scope, stalls at pilot |
Scope creep doesn’t look like a disaster. It looks like a reasonable request in sprint two. Guard against it now, on paper, while it costs nothing to say no.
Try it yourself
Pick a real process you know. Write its one-sentence job the way a user would say it — not an architect. Then fill the three lists honestly, including at least two refusal cases. Can’t finish in fifteen minutes? The scope is still too broad.
Where this shows up in SAP
The Business Partner agent does exactly four things — read, create, update, block — and refuses to delete, because the API doesn’t support it. The Sales Order agent creates orders and nothing adjacent. Neither tries to be a general-purpose SAP assistant — which is exactly why both are straightforward to trust.
Key takeaways
- Scope from the business outcome, one plain sentence — not from the API surface.
- Every job is three lists: what it must read, write, and refuse.
- Narrow agents win on testing, governance, and client buy-in — every time, measurably.
- Scope creep arrives disguised as a reasonable ask. Write the boundary down while it’s free.
Next: take that one sentence and build its first real capability — a single, read-only MCP tool, start to finish.