Build or buy AI agents: what to verify before committing

A demo tells you the thing can work once. It tells you almost nothing about who fixes it at 2am.

So pick the route whose evidence shows your team can operate, diagnose, change and eventually replace the service. Building does not remove your dependence on suppliers. Buying does not remove your accountability for what the agent does.

This article assumes you have already decided a bounded agent is worth evaluating for a specific job. It works through one fictional support proposal to show what I would ask for. No route wins on principle, and if the evidence is not there yet, the honest answer is that you are not ready to commit.

If that first decision is still open, work out whether the job needs an agent at all before reading further. A fixed retrieval step or an ordinary workflow often does the job with far less to operate.

Define one job before comparing proposals

Comparisons go wrong when the job is vague. Write down one workflow, narrowly, before you look at any proposal.

The fictional example used throughout this article: a B2B SaaS support team wants an assistant that drafts answers to account-specific product questions, using approved documentation and the account records it is permitted to read. An authorized person reviews every draft and sends it. The agent does not touch billing, issue refunds, chase invoices or change anything in a customer's account.

That scope is the thing you are buying or building. It tells you which access the agent needs, which failures matter, and who has to be available when something breaks.

Every proposal below is assessed against the same scope and the same approved, sanitized test cases. That is the only way the comparison means anything.

What each route still leaves your team

Three routes are on the table. All three leave real work with you.

A managed product can remove a lot of implementation work. It does not remove your responsibility for which records the agent may read, whether its answers are acceptable to send, or what happens when it is wrong. You still own the review step and the consequences.

An in-house implementation on commercial components gives you control over configuration and records. It does not make you independent: you are still depending on a model provider, and now on your own staffing too. Access to the source code proves nothing about whether someone on your team can rotate a credential under pressure.

A managed foundation with a custom layer splits the work, and therefore splits the responsibility. That split is the thing I would examine hardest, because a broken connector can end up belonging to nobody.

None of this makes one route cheaper or safer. It makes the obligations visible, which is the point.

Work through one support proposal

Here are three unnamed proposals for that same support workflow. Every capability described below is an assumed condition of the fictional proposal, not a claim about any real product or supplier.

Each entry below is marked with where it stands: a supplier statement from the proposal, a proposed design we would build, observed evidence we have actually seen, or unresolved. Nothing here is marked observed, because no demonstration has happened in these fictional proposals. Writing that down honestly, rather than rounding it up to a capability, is the work.

Proposal A, the managed product

• Access and outcome: supplier statement. A read-only connector to the permitted account records, with drafts held in a review queue for a human approver. Next: buyer's engineering lead confirms in writing which record types the connector can reach, and whether that set can be narrowed.
• Integration work: unresolved. The proposal does not itemize the buyer-side setup for identity, the review queue and any permission narrowing. Next: engineering lead asks for that work itemized, then estimates it with whoever would do it.
• Configuration and version history: supplier statement that configuration is versioned inside the platform. Unresolved whether we can read that history ourselves. Next: engineering lead asks to view the version history of a policy change in the sandbox.
• Run and final-state evidence: unresolved. The quote mentions a run log but not whether it shows retrieved source versions, tool results and the final state of the draft. Next: engineering lead requests one complete run record for an agreed test case and checks whether it answers "what did it use and what did it do".
• Evaluation after a change: supplier statement that the model may be updated. Unresolved who re-runs our test set afterwards, and whether we are told in advance. Next: engineering lead asks for the notification terms and proposes that we re-run the agreed cases on notice.
• Credentials and permissions: supplier statement, held by the platform with our administrator able to revoke. Next: support lead confirms revocation actually cuts access, during the sandbox session.
• Incident stop and recovery: supplier statement, a pause control in the admin interface. Unresolved what happens to drafts in flight. Next: support lead pauses mid-run in the sandbox and inspects what is left behind.
• Export and replacement evidence: unresolved, and this is the largest gap. The quote does not establish whether versioned configuration and permitted run records leave the platform in a usable form. Next: engineering lead requests an actual export of both from the sandbox, confirms a second team can read them, and obtains written export terms.
• Retained by us either way: deciding which records are in scope, reviewing and sending every reply, and owning what the customer receives.

Proposal B, in-house on commercial components

• Access and outcome: proposed design. Our own service reads the permitted records and writes drafts to the existing support queue. Next: engineering lead confirms the permission scope with whoever owns that data.
• Integration work: unresolved. The service, the run recording, the test set and the ongoing operating work all need scoping before anyone can size them, and what they displace from the roadmap is open. Next: engineering lead scopes and estimates the work, and agrees with the product lead what is being deprioritized before this starts.
• Configuration and version history: proposed design, held in our own repository. Controlling the system of record is not the same as having usable version history. Next: engineering lead verifies in the sandbox that a policy change can actually be read back with its history.
• Run and final-state evidence: proposed design, recorded to our own storage. Unresolved whether the planned records actually capture retrieved source versions and final draft state, because nothing has been built yet. Next: engineering lead writes the record format down and walks one agreed case through it on paper before building.
• Evaluation after a change: proposed design, our test set re-run when we change the prompt, the policy or the model version. Unresolved who owns that when the engineer who built it is on other work. Next: engineering lead names a second person and a trigger.
• Credentials and permissions: proposed design, our secret store, our rotation schedule. Unresolved in practice, see below.
• Incident stop and recovery: unresolved, and this is the largest gap. The design says we can stop it; nobody has shown that they can. Next: a named operator demonstrates credential rotation, a mid-incident stop and a restoration in the sandbox, with the engineering lead watching.
• Export and replacement evidence: proposed design. Holding the artifacts is not the same as having shown a second team can use them. Next: engineering lead verifies permitted export and reconstruction in the sandbox. Note the limit: the model provider stays external, so this is custody of our own artifacts rather than independence.
• Retained by us either way: all of the above, plus the operating load. Access to the source proves nothing about whether someone is available to use it at 2am.

Proposal C, managed foundation plus custom integration

• Access and outcome: supplier statement for the foundation, proposed design for our integration layer. Next: engineering lead writes one sentence per component saying which part reads what.
• Integration work: unresolved. The work spans two interfaces rather than one, and how much of it recurs when either side changes is unknown. Next: engineering lead scopes the integration and change-coordination work with the supplier and our own team, and asks the supplier for their change cadence.
• Configuration and version history: split. Foundation configuration is a supplier statement; our layer's configuration is a proposed design in our repository. Unresolved how the two versions are kept in step. Next: engineering lead proposes a single change record covering both.
• Run and final-state evidence: split and unresolved. Separate records are a supplier statement on the foundation side and a planned design on ours; neither separate nor joined records have been demonstrated. Next: engineering lead asks both sides to produce a joined record that follows one agreed case end to end.
• Evaluation after a change: unresolved. A foundation model change and an integration change both alter behavior, and the proposal does not say who re-runs the tests. Next: engineering lead proposes that we own the test set regardless of which side changed.
• Credentials and permissions: split, with our layer holding the connector credentials. Next: support lead confirms where each credential lives and who can rotate it.
• Incident stop and recovery: unresolved, and this is the largest gap. A broken connector, a permission failure and a model behavior change could each belong to either side. Next: document one end-to-end incident owner, then run the agreed test to confirm that owner can actually stop and restore the whole path, not just their component.
• Export and replacement evidence: split. Our layer is ours; the foundation's side carries the same open question as Proposal A. Next: engineering lead asks for the equivalent export demonstration.
• Retained by us either way: the review step, the customer outcome, and the coordination work between the supplier and our integration team.

Ask for the evidence before committing

Those are the same nine requirements in the same order for every proposal, which is what makes them comparable:

• The required outcome and the exact access the agent is permitted.
• Integration work, named and estimated by whoever would do it.
• Who owns configuration and its version history.
• What run and final-state evidence you can inspect, including the state the environment ended in.
• Who re-runs the evaluation after a change, and when.
• Credential and permission controls, and who holds them.
• Who stops the agent during an incident, and who restores service.
• What evidence you can export if you replace this route.
• What stays your responsibility whichever route you choose.

Every proposal has to meet all nine. Closing the largest gap on one route does not excuse the others: Proposal A still has open questions about version history, re-evaluation and in-flight drafts even after the export question is answered.

Do not total this into a score. Scoring turns a missing essential control into a rounding error, because convenience scores well and absence scores nothing at all.

A requirement can be met by different architectures. Owning every component is not a requirement in itself.

Anthropic's engineering guidance on evaluating AI agents, published 9 January 2026, makes a point worth borrowing here: run the same task repeatedly, keep the traces (the records of the agent's steps and tool results), and check the final state of the environment rather than the reply. That is about testing agents, not about procurement, and it does not tell you whether to build or buy. It does tell you what "it worked in the demo" is worth. If you want more on testing the whole exchange rather than single answers, we covered that separately.

NIST's voluntary AI Risk Management Framework Playbook covers related ground under Govern: safe decommissioning, named accountability for roles, third-party risk, and contingencies when a third party fails. It is guidance rather than law or certification, the page itself warns that a revision is coming, and the specific checklist above is our synthesis rather than anything NIST prescribes.

A continuity exercise, proposed and untested

In a permitted sandbox, meaning an isolated test environment that touches no real customer data, run a sanitized product question with known allowed account context against a versioned policy. Ask the supplying team to show you which records and instructions the agent was allowed to use and which actions it was permitted to take, which source versions were retrieved, how it was configured to handle them, what the tools returned, what the operator decided and what state the draft ended in.

Run equivalent cases for all three proposals, including a missing permission, an out-of-date source and an unavailable connector. Define the expected stop or escalation for each case in advance, then inspect the state rather than trusting the final message. (Source versions matter more than people expect.)

Then hand a second team only the artifacts the proposal actually permits exporting, and ask whether they can identify the applicable configuration and sources, explain what the earlier run did, and rebuild the agreed test in a replacement sandbox. Write down what they could not do without help.

Keep its limits in view. Do not copy credentials, hidden model reasoning, unnecessary personal data or records you have no permission to export. This proves nothing about disaster recovery, production portability or legal compliance, and it promises no exact behavioral match after a move: you will have to revalidate, and some underlying services stay external even when you build. It is a procurement acceptance condition we are proposing, not a tested method.

Know when to defer

The honest end state for this fictional comparison is conditional. There is no winner yet, and saying otherwise would be inventing one.

Proposal A stays open until the export and run-evidence gap is answered with a demonstration, and until its version history, re-evaluation and in-flight-draft questions are answered too. Proposal B stays open until a named person actually shows the operational steps, and until someone owns re-evaluation when the original engineer is elsewhere. Proposal C stays open until one party is documented as the end-to-end incident owner and the agreed test shows that owner can stop and restore the whole path.

Clearing those does not hand you an answer. It makes the routes comparable, and only then can you weigh what the evidence actually showed: the integration effort each route demonstrated, the operating duties it leaves with your team, and how much of the configuration and run history you are permitted to take with you. Do not rank the routes before that evidence exists. A proposal that meets every requirement is eligible for further evaluation; that is still not the same as being ready to commit, which is a judgment about whether the obligations you are taking on fit the team you actually have.

Deferring is a real option. So is a smaller scope: draft-only on a narrower question set, or a fixed workflow with no agent, revisited when the evidence improves.

A lower-risk workflow needs a lighter continuity plan than this one. Anything high-risk or regulated needs qualified specialist review well beyond this article.

If you are weighing this for the first time and want a second opinion on the scope rather than the vendor, that is the kind of question a fractional CTO or a focused AI adoption review is useful for. Either way, the next step is the same: pick one proposal, name the person who owns its unresolved item, and ask for the demonstration this week.