How to Scope an SI Agent Project Before You Ask for Quotes

Most SI agent quotes are hard to compare because each vendor is quoting a different project. One assumes the agent drafts replies for a person to send, another assumes it sends them, and a third has added integrations nobody asked for. The gap is rarely skill. The buyer never wrote down what the agent is for.

This worksheet is meant to be filled in before you speak to any vendor. It does not cover how an agent is built (that is in our guide to building an SI agent for your business, step by step), and it assumes you have already decided an agent is the right tool rather than a chatbot or a plain workflow. If you have not, start with SI agent vs chatbot vs workflow automation. What follows makes quotes comparable and keeps the first release small.

1. Name one workflow and what starts it

Scope one workflow, not a department. "Help the finance team" is a wish. "When a supplier invoice arrives in the shared inbox, match it to a purchase order and prepare it for approval" is a workflow. A vendor can scope the second. The first invites guesses.

• What is the trigger: an incoming email, a form submission, a new ticket, a scheduled check, or a person asking in chat?
• What does the workflow look like today, step by step, and who does each step?
• Where does it end? Name the output: a drafted reply, an updated record, a routed ticket, a decision with reasons.
• What is explicitly out of scope for the first release? Write it down. This list protects the project more than any other line in the brief.

If you list several workflows, pick the one with the clearest inputs and the most forgiving mistakes. Add the others once the first is trusted.

How do I scope an SI agent project before asking vendors for quotes?

Write a one-page brief before you speak to any vendor. Name one workflow, its trigger and its output, plus what is out of scope. List the systems the agent reads and writes and how each is reached. Sort every action into three lists: acts alone, needs approval, never allowed. Collect real past cases with expected outcomes as an evaluation set. Then describe hand-offs to people, data permissions, volume and speed in plain words, and who owns the agent after launch.

2. Map the systems it reads and writes

Much of the effort in an agent project goes into the systems around the model. List every system the agent touches and whether it reads, writes or both.

• Sources it reads: inbox, CRM, ERP, ticketing tool, shared drives, knowledge base, internal databases.
• Systems it writes to, and exactly which fields or objects it changes.
• How each system can be reached: a documented API, an export, a database connection, or only a screen a person clicks through. The last one changes the project considerably, so flag it.
• Who owns each system internally and approves access.
• Which source is authoritative when two of them disagree.

Flag unstructured inputs such as scanned PDFs, handwritten forms or mixed-language attachments, and include a few anonymised samples. Vendors scope far better from real inputs than from descriptions.

3. Decide what it may do alone and what needs approval

This is the section that changes a quote most, and the one buyers most often leave blank. List every action the agent could take, then sort each one into three columns.

• Acts alone: low-impact and easy to reverse, such as tagging a ticket or drafting an internal note.
• Acts after approval: a named person confirms before it happens, such as sending an email to a customer or changing a ledger entry.
• Never: actions the agent must not be able to take at all, enforced by permissions in the connected systems rather than by instructions in a prompt.

The OWASP Top 10 for LLM Applications lists excessive agency as a risk (LLM06:2025) and traces it to three causes: tools the agent does not need, permissions broader than the task, and high-impact actions taken without independent approval. Your three columns address all three before anyone writes code. How approvals work day to day is covered in human-in-the-loop approval patterns for SI agents. For scoping, say which actions need approval and who approves.

4. Define "done well" as real cases

"Accurate" and "helpful" cannot be tested. Real examples can. Before you ask for quotes, collect past cases from the workflow and write down what a good outcome looked like for each one. This becomes the evaluation set the vendor builds against, and the yardstick for deciding whether a release is ready.

• Typical cases: the ordinary bulk of the work.
• Hard cases: ambiguous requests, missing information, conflicting records.
• Cases the agent should refuse or hand over, and what it should say when it does.
• For each case: the input, the expected action or output, and what would count as a serious mistake rather than a minor one.

Ask the people who do the work today to label the cases, not the project sponsor. They know where the edge cases are. Then decide which mistakes are unacceptable. An agent that sometimes drafts a clumsy reply may be fine. One that sometimes pays the wrong supplier is not, and that difference should drive the approval column above. Our note on eval-first delivery explains why this set matters more than a demo.

5. Plan for failure and the hand-off to a person

Every agent meets cases it cannot handle. The brief should say what happens then, so vendors design for it instead of discovering it in production.

• What should the agent do when it is unsure: stop, ask for the missing detail, or pass the case on?
• Who receives the hand-off, in which tool, and with what context attached so they do not start from scratch?
• What must be recorded about each run so a person can see what the agent did and why?
• Who can pause the agent entirely, and how?

6. Set data access and permissions

List the data the agent will see and the rules that already apply to it. If your staff can only see records for their own region or clients, an agent acting for them should be held to the same rule, enforced in the systems it calls rather than trusted to the model.

• Categories of data involved: personal data, financial records, health information, contracts, internal-only documents.
• Whose permissions the agent runs under: a dedicated service account, or the identity of the person it acts for.
• Where data may be processed and stored, and any limits set by customer contracts or regulators.
• Whether the vendor may use production data during the build, and if so, whether it must be masked.
• If the data includes personal data of people in the EU, an outside vendor processing it on your behalf will normally need a processor contract under Article 28 of the GDPR. Ask your privacy lead to confirm what applies.

7. Describe volume and speed in plain words

You do not need exact figures to scope well, but you do need the shape of the demand. Described in plain words, it lets vendors choose an architecture that fits.

• Volume: a handful of cases a week, a steady stream through the working day, or sharp peaks around month end or a campaign?
• Speed: is someone waiting on screen for the result, or can it arrive later in a queue?
• Hours: does it run outside office hours, and who covers hand-offs then?

A person waiting in a chat window and a batch that runs in the background are different systems. Say which one you need.

8. Name who owns it after launch

An agent is not finished at launch. Providers update models, source documents change, and real cases drift away from the ones you tested. Decide now who on your side owns it.

• A business owner who decides what the agent should do and approves any change to its permissions.
• A technical owner who handles incidents, model changes and integration updates.
• Who reviews quality once it is live, and how new cases are added to the evaluation set.
• Which accounts (model provider, cloud, repositories) must be in your organisation's name from the start.
• What the vendor must hand over: documentation, runbooks, the evaluation set and the prompts.

The one-page brief

Pull the answers into a single page and send the same page to every vendor. Quotes built from one brief can be compared. Quotes built from separate conversations cannot.

1. Workflow: one sentence naming the trigger, the steps and the output.
2. Out of scope: what the first release will not do.
3. Systems: each system, whether the agent reads or writes it, and how it is reached.
4. Actions: three lists (alone, with approval and the named approver, never).
5. Evaluation set: the real cases collected, who labelled them, and which mistakes are unacceptable.
6. Failure and hand-off: what happens when the agent is unsure or a system fails, and who receives the case.
7. Data and permissions: data categories, whose identity the agent uses, and where data may live.
8. Volume and speed: the shape of demand, and whether a person waits on the result.
9. Ownership: business owner, technical owner, accounts and handover items.
10. Open questions: what you do not know yet and want the vendor to help answer.

A good vendor will challenge parts of this page. One who quotes without a single question has probably not read it. If filling it in raises more questions than answers, that is the point where an independent SI consulting review is most useful, from us or anyone else.

Where Octalcode fits

Octalcode is a studio in Lahore, with a US presence in Austin, that builds SI agents, LLM applications and RAG systems. When a brief like this reaches us, we read the action columns and the evaluation cases first, because that is where most scoping gaps hide.

If you would rather pressure-test the worksheet before sending it to anyone, our SI consulting work covers exactly this: narrowing the workflow, sorting the actions and turning past cases into an evaluation set. You keep the brief, whichever vendor you choose.