You do not need to choose the model or design the architecture before contacting a development company. You need to explain the work the system should support and the constraints that matter.
A concise brief with real examples is more useful than an ambitious feature list that does not define a successful outcome.
State the problem as work, not technology
Instead of “we need an AI agent”, write: “Our team receives supplier quotations in different formats, copies fields into a comparison table and checks inconsistent totals. We need a reviewable way to prepare that table.”
This leaves room for the supplier to propose the appropriate combination of conventional software, extraction, retrieval or model-based processing.
Identify the user and the decision-maker
Name the people who will use the result and the person who can approve product decisions. Distinguish the budget owner, technical contact and source-data owner where they are different.
Explain the current workflow, how often it happens and what makes it difficult. Where you have measurements, include the method and period. Where you do not, label the figure as an estimate.
Provide input and output examples
Describe where inputs come from, their formats and the permissions required. Include examples of both routine and difficult cases. For each, show the output a person would accept.
Do not send confidential records through a public form. Agree a suitable sharing route and access scope before providing non-public material.
Define a bounded first release
Separate essential tasks from later features. State what the first version must allow a user to complete, which integrations are required and which actions remain manual.
For example: “The first version extracts and flags quotation fields for human review and exports a table. It does not send orders, negotiate with suppliers or update the accounting system.”
Explain constraints and acceptance
List relevant access controls, hosting requirements, available integrations, performance expectations and operational responsibilities. A constraint is more useful when its reason is clear.
Acceptance should include representative tasks and important failures. Explain when the system should ask for clarification, return no answer or hand work to a person.
Be explicit about the commercial situation
Give an approximate budget range if available, the intended timing and any fixed external deadline. State whether funding or procurement approval is already in place. This helps a supplier propose an appropriate first stage rather than quote an unsuitable full build.
Ask how ownership, third-party costs, support and handover will be handled. Those belong in the project conversation before commitment.
A brief you can copy
Problem: What work is currently difficult?
Users: Who will use the system, and who approves the project?
Current process: What happens today, and how often?
Inputs: Which files, systems and permissions are involved?
Required outputs: What should a person be able to use or approve?
First-release scope: What must be included, and what is explicitly excluded?
Acceptance: Which examples and conditions determine a successful result?
Constraints: Data, integrations, hosting, timing and support.
Commercial context: Budget range, decision process and intended start.
Open questions: What do you need the delivery partner to help determine?