Most RFPs for SI projects produce proposals you cannot compare. One vendor quotes a chatbot, another an agent platform, a third a research programme, and all three are answering the same document. The cause is usually the RFP itself: it names a technology instead of a problem, says little about the data, and asks for a demo rather than evidence.
This is the template we would use if we were the buyer. It works for an LLM application, an SI agent or a RAG system, and it borrows from public procurement guidance, because government buyers have had to solve the same comparability problem in the open. Do the scoping work first: how to scope an SI agent project before you ask for quotes covers the inputs this RFP assumes you have.
Why do SI project RFPs produce proposals you can't compare?
Usually, the brief names a technology rather than an outcome, so each vendor invents its own version of the problem. The data is described optimistically, so each vendor prices a different set of assumptions. And there is no shared test, so every proposal claims quality against its own definition.
Public buyers have written this down. The UK government's 2020 procurement guidelines for these systems advise telling suppliers about the challenge and letting them propose a solution, and running a discovery into your data before going to market. In the US, OMB memo M-25-22 (April 2025) encourages federal agencies to test proposed solutions to understand their capabilities and limitations, and calls for contract terms that address use of government data, intellectual property rights and vendor lock-in. You do not need to be a government to borrow the method.
What should an RFP for an SI or LLM project include?
An RFP for an LLM application, SI agent or RAG system should describe the business problem rather than a solution, define success metrics and which ones block launch, and state your data honestly: sources, formats, quality, labels and access rules. Add integration points, ownership terms, written security and data handling questions, and a request for each vendor's evaluation plan. Include a paid discovery or proof stage on your own data, state your budget range, fix the response format, and publish the scoring rubric so proposals compare side by side.
Section 1: The business problem, not the solution
- What happens today: the process, who does it, the rough volume in your own words, and where it breaks.
- Who uses the result, and what they decide or do with it.
- What better looks like: fewer escalations, faster first responses, fewer errors caught in review. Name the measure even if you have no baseline yet.
- What is out of scope, so nobody prices it.
- Constraints you already know: languages, channels, regulated data, and systems that cannot change.
Resist naming a model, a framework or an architecture. If you have a preference, give the reason (for example, your cloud account is with one provider and you want to stay there) and invite vendors to argue against it.
Section 2: Success metrics and how they will be measured
Ask every vendor to answer against the same definitions. For a support assistant, that might be the share of test questions answered correctly, the share correctly handed to a person, how often an answer contains a claim the sources do not support, and the wait the user actually sees. For an agent: task completion on real cases and wrong actions taken.
Say which metrics are gates and which are targets. A gate blocks launch; a target is something to improve after it. If you have no baseline, don't invent thresholds. Ask vendors to propose them and explain how they would measure each one.
Section 3: Data readiness, stated honestly
This is where most mispriced proposals come from. Describe what you have, not what you plan to have.
- Sources: document stores, databases, ticket history, call recordings, and the format of each (scanned PDFs, spreadsheets, wiki pages).
- Volume and rate of change, as roughly as you know them.
- Quality: duplicates, outdated versions, documents with no owner, handwritten or scanned material.
- Labels: do examples of correct answers or decisions exist, and who could create more?
- Access: who must approve sharing, and which data can never leave your environment.
- Permissions: whether different users may see different documents, because that changes how retrieval is built.
The UK guidance is blunt on this point: if no usable data will be available, time should not be spent on the procurement at all. If you share sample data with bidders, give every bidder the same sample at the same time, under an NDA, and within your data protection obligations.
Section 4: Integration points and ownership
- Systems the solution must read from and write to, and how access works today: an API, direct database access, an export, or nothing yet.
- Identity: how users sign in, and whether the system must respect existing permissions.
- Hosting: your cloud account, a required region, or on premises.
- Model providers you have approved or ruled out, and why.
- What you will own at the end: code, prompts, evaluation sets, retrieval indexes, infrastructure code, and accounts held in your organisation's name.
- Lock-in: how hard it would be to change model provider or vendor later, and what would be handed over if you did.
Section 5: Security and data handling questions
- Where will our data be stored and processed, including by model providers, and for how long is it retained?
- Will any of our data be used to train models, by you or by a provider, and under which written terms?
- How do you test for prompt injection, sensitive information disclosure and excessive agency, three of the risks in the OWASP Top 10 for LLM Applications (2025 edition)?
- What do you log, how is personal data handled in those logs, and who can read them?
- How are access and secrets managed during the project, and how is your access removed at the end?
- Which audits or certifications do you hold? Send the report or certificate and show its scope.
If your organisation already uses NIST's risk management framework for these systems, with its Govern, Map, Measure and Manage functions, or its companion profile for generative models, ask vendors to map their answers to it. The framework is voluntary, but it gives buyer and vendor a shared vocabulary.
Section 6: The evaluation plan
Ask each vendor how they would prove the system works before launch, and how they would keep proving it afterwards. A good answer names a test set built from your real cases with your domain experts, automated scoring on every change, separate scores for retrieval and for answers in a RAG system, and clear rules about what blocks a release.
Ask for an anonymised evaluation report from a past project, and ask what they would monitor once real users arrive. If the process includes demos, treat them as a test rather than a presentation; how to evaluate an SI vendor's demo lists the questions that expose a fragile prototype.
Section 7: A paid discovery or proof stage on your own data
This is the most useful clause in the template. Rather than choosing on slides, shortlist a small number of vendors and pay for a bounded proof stage that runs on your data, your test questions and your metrics. It mirrors the federal advice to test proposed solutions, using validation data the buyer defines rather than data the vendor picks.
- The question the stage must answer, written as a decision: build, change scope or stop.
- The data you will provide, and the environment it stays in.
- The test set and the metrics from Section 2.
- The deliverables: working code in your repository, an evaluation report, and a written recommendation.
- Who owns the output, including if you don't continue with that vendor.
Paying matters. Unpaid proofs tend to get best-case data and a sales engineer; paid work gets a scope, an owner and a result you keep. SI proof of concept, pilot or production sets out what each stage should prove. If you want an outside view on how to frame the stage, that is the kind of question SI consulting is for.
Section 8: Budget, response format and what vendors send back
- State your budget range. It lets vendors size their approach honestly and stops proposals aimed at a number you could never approve.
- Your decision process: who decides, the selection steps, and when you will respond to bidders.
- A fixed response structure, with headings that match your sections, so proposals can be read side by side.
- The team: named people, their roles, and how much of their time goes to your project.
- Assumptions and exclusions, listed explicitly.
- References from similar projects that you can call.
How should you score the proposals?
Publish the rubric in the RFP. The weights are yours to set; these are the criteria we would include.
- Understanding of the problem: did they restate it accurately and challenge weak assumptions?
- Approach to data: are they realistic about quality, access and permissions?
- Evaluation plan: a concrete test set, metrics and release gates, not a promise of accuracy.
- Security and data handling: specific written answers you can check.
- Team and evidence: named engineers, references and evaluation reports.
- Ownership and exit: what you own and how you would switch.
- Commercials: a clear pricing model with stated assumptions.
Have at least one technical and one business reviewer score each proposal independently before anyone compares notes. For criteria about the vendor itself rather than the proposal, combine this rubric with a buyer's scorecard for choosing an SI development partner.
If two proposals cannot be laid side by side, the RFP asked two different questions.
Where Octalcode fits
Octalcode is a studio in Lahore, with a US presence in Austin, that builds LLM applications, SI agents and RAG systems. We answer RFPs like this one, and we would rather receive one with honest data and a published rubric than a request for a polished demo.
If you are drafting an RFP and want a second view on the problem statement, the metrics or the proof stage before it goes out, our SI consulting work covers exactly that. We sign an NDA before seeing any of your data.