Ask an AI agent vendor to define the workflow, permitted data and actions, acceptance evidence, delivery ownership, and the handover you will receive. Request concrete explanations of failures, approval controls, model changes, and exit dependencies. Their answers should identify inspectable artefacts and responsible people that can become part of the agreed scope.
Ask what business operation the agent will support
Vendor diligence is the work of determining whether a proposed engagement addresses your workflow under your operating constraints. A compelling conversation with a model does not establish that the team understands your records, permissions, review process, or obligations after launch.
Ask the vendor to describe the input, the proposed output, the authorised reviewer, and the resulting operation. They should be able to explain the workflow using the language of your application. If the answer expands into unrelated capabilities whenever a boundary is discussed, the scope is not yet ready to assess.
Use a hypothetical exception to make the answer concrete. For an employee equipment request, ask what happens when the source records disagree about eligibility. Does the agent stop, present the conflict, or invent a resolution? Request that the agreed behaviour appear in acceptance cases, rather than remaining a reassuring conversation.
Ask which integration assumptions have been checked
Identify every source and destination system the workflow needs. Ask which interfaces the vendor has inspected, which are assumed, and which dependencies will be simulated during early development. A simulated connector can support useful investigation, but it cannot demonstrate the live system's access rules or failure handling.
Ask how the requesting user's authority reaches the integration layer. Which data can the agent retrieve, under whose identity, and for what purpose? How does the system prevent a document or tool response from becoming an instruction to access something outside that scope? Request the intended enforcement location rather than accepting a promise that the prompt will tell the agent to behave.
Ask the team to describe a failed write whose outcome is unknown. The answer should address confirmation from the target system, duplicate prevention where the interface supports it, and operator intervention where it does not. These are concrete integration questions that a demonstration of generated text does not resolve.
The enterprise AI integration service describes contracts, authentication, permissions, and data boundaries as engineering work. Include that work in the engagement scope wherever the workflow depends on it.
Ask who can authorise an action and who executes it
Have the vendor draw the boundary between a suggestion and an applied change. Which component can write to the operational system? Where is an approval recorded? What binds the approval to the exact target and operation? What happens if the record changes while a proposal is awaiting review?
CodeDTX's Propose–Decide–Execute pattern is an explicit answer: the agent writes a proposal with evidence, a named human decides with a reason, and a separate execution layer applies approved work and records the artefact. The proposing agent has no outward write tool.
If that pattern is part of the proposed solution, ask to inspect evidence of the boundary. A rejected proposal should remain unexecuted. An altered operation should not reuse the earlier decision silently. A missing approval should cause the executor to reject the request regardless of how persuasive the proposed explanation sounds.
Ask how reviewers will inspect evidence without being overwhelmed or exposed to records they cannot otherwise access. The approval interface is part of the control. A backend decision record is insufficient if the person approving cannot see what change it authorises.
Ask what evidence will justify acceptance
Request acceptance conditions for ordinary work, ambiguous inputs, missing evidence, permission failures, rejected proposals, and unsuccessful execution. Ask who supplies representative examples and who is authorised to judge their expected outcome. The decision should not depend solely on the team delivering the system.
Inspect the distinction between deterministic tests and behavioural evaluation. Permission and execution rules need direct checks. Interpretation and evidence use need representative task cases and an explicit review rubric. If a model grades outputs, ask how that grading has been checked against human-reviewed examples.
The agent evals guide explains why a passing suite supports only the conditions it actually tests. Ask the vendor to show known limitations and untested dependencies beside the results. A claim that the system is production-ready should resolve into a named environment, allowed use, and reviewable release evidence.
Agree what happens if the evidence supports narrowing or stopping the project. A paid proof of concept is useful when its exit decision can reflect what the work establishes. If every possible result is framed as a reason to expand delivery, the original uncertainty is not being treated as a real question.
Ask how the product will be operated and changed
Name the people responsible for application incidents, model behaviour, integration failures, and business review. Ask what support information they will receive and which actions they can perform. An alert with no owner or no containment control is not an operating plan.
Walk through a model retirement, an unavailable evidence source, and an execution failure. Ask what the user sees, what work remains pending, and how the team restores the capability. Model replacement should include evaluation and a release decision; a fallback should name an available, permitted option.
Use the reference architecture to inspect coverage. Agent behaviour, integration, knowledge, reliability, safety, and the product interface each have maintenance needs. The vendor should identify which responsibilities are included in the engagement, which remain with your team, and which depend on a separate service agreement.
Request the proposed dependency record and runbook format before handover. Those artefacts reveal whether the team has considered configuration ownership, service access, recovery, and future changes. The guide to production monitoring provides concrete questions for the operational walkthrough.
Ask what your team can do when the engagement ends
Clarify repository access, source ownership, reusable components, deployment access, and continuing service dependencies in the written agreement. Paying for development does not by itself specify those arrangements. Bring unresolved terms to the people authorised to agree them before treating them as settled delivery assumptions.
Ask for an observable handover: your engineers run the application, execute the evaluation suite, investigate a failed request, and make a reviewed change. Documentation should explain the decisions behind the design as well as setup commands. Otherwise the team may possess the files while depending on undocumented knowledge to modify them.
The dedicated AI engineering teams approach treats capability transfer as a deliverable through shared repositories, paired work, recorded decisions, and runbooks. Before signing, convert the aspects your team needs into acceptance activities with named participants. That creates something you can inspect when delivery is reviewed.
Frequently asked questions
Should we choose a vendor based on the model it uses?
Model suitability matters, but the proposed product also depends on integration, permissions, evaluation, review, and support. Ask why the chosen model fits your workflow and how that choice will be tested. Then inspect the engineering around it. A model name alone does not establish that the vendor can deliver or maintain the business capability you need.
What demonstration should we request before agreeing the scope?
Request a walkthrough of a representative workflow and an exception that challenges a boundary. Ask the vendor to identify simulated dependencies and show the proposal, human decision, execution result, and failure handling where those are implemented. The purpose is to clarify assumptions and acceptance work, not to treat a demonstration as evidence of production access or complete readiness.
What should the proposal say about data access?
It should identify the required sources, intended purpose, access decision owners, identity model, and restrictions on retrieval and storage. It should explain where permissions are enforced and what happens when access is denied. Unresolved access assumptions should remain visible in the scope, alongside the work needed to confirm them before representative testing or operational deployment.
How can we verify that handover is more than documentation?
Have your engineers perform the activities they will own: run the software, evaluate a change, find a failed request, and use a recovery control. Agree those activities before delivery and preserve their results as acceptance evidence. Written materials remain necessary, but observed use reveals missing access, unclear decisions, and operational knowledge that a document review can overlook.
