By May 2026, the agent vendor map is consolidating in three directions at once. Frontier labs are absorbing the eval, observability, and developer-tooling layer (OpenAI bought Promptfoo in March 2026; Anthropic acquired a smaller eval vendor in February; Google made an offer on Helicone that fell through over governance). Hyperscalers are absorbing the integration and data layer (Salesforce closed Informatica on March 14, 2026; ServiceNow bought a workflow agent startup for $1.4B in April). And vertical agent companies are getting rolled up by the incumbents whose category they were disrupting (three legal-tech, two RCM-healthcare, and four insurance-claims agent vendors were acquired between January and May 2026). The agent platform strategist is now the person the corp-dev team comes to when a target appears on the shortlist — and the question is not "is this a good product." The question is "if we buy this, does the agent stack we run actually get stronger, or do we inherit a year-long integration project that produces a duplicate of what we already have." This lesson is the technical-plus-commercial due-diligence pack the strategist runs on every agent target before signing the LOI. Thirty questions in seven categories. A red/yellow/green scorecard the corp-dev team will trust. And the named tools, named clauses, and named numbers the strategist puts on the page so the diligence is not just a vibes check.

Why Agent Vendor Diligence Is Not SaaS Diligence

The corp-dev team has a SaaS diligence playbook. It is twenty years old, well-tested, and almost completely wrong for agent vendors. The SaaS playbook asks about MRR, churn, NRR, CAC payback, gross margin, and the engineering org's tenure. All of these matter. None of them tell the strategist what they need to know about whether the agent stack the target ships will still be operable inside the acquirer eighteen months after close. The agent vendor has six failure surfaces a SaaS vendor does not.

The six new surfaces

First, the eval set. An agent vendor's product is the eval set its prompts and tool integrations pass against. If the target cannot show the strategist the eval set, the eval coverage report, the regression-on-model-upgrade history, and the customer-specific eval extensions, then the product the strategist is buying is a prompt and a hope. The price the company is paying assumes the prompt is reliable; the eval set is the only evidence reliability exists. Targets that cannot produce the eval set in week one of diligence have already failed.

Second, the observability layer. Every production agent emits traces. Every responsible vendor stores them, makes them searchable, and exposes them to customers. Vendors that obscure traces, redact them aggressively, or run them through a proprietary black-box "summary" are vendors whose product is unverifiable. The strategist needs to see the target's LangSmith, Langfuse, Helicone, or Arize Phoenix integration; the trace retention policy; the customer-facing trace UI; and the team's own trace-review cadence. A vendor that does not run weekly trace reviews on their own production agents is a vendor whose agents are not being maintained.

Third, the model and prompt versioning discipline. The target's prompts changed last month. The model the target uses (GPT-5.2, Claude 4.5, Gemini 3 Ultra) changed last month. If the target cannot produce a git-style history of every prompt change with the eval-set delta and the production-traffic A/B result, the strategist is buying a moving target. Agent vendors that ship prompt changes without versioning are vendors whose customers will silently regress on day one after close when the acquirer "consolidates" model providers.

Fourth, MCP and Skills compatibility. The Model Context Protocol shipped as an industry standard in mid-2025 and by May 2026 is the lingua franca of tool integration. Skills (the file-format extension Anthropic shipped in late 2025) is the analogous convention for agent capability packaging. A target whose tool integrations are bespoke, non-MCP, non-Skills-compatible bindings to its own internal abstractions is a target whose integrations the acquirer will rewrite. That rewrite is six to twelve months of engineering for any non-trivial integration count.

Fifth, the escape-hatch openness. Every agent vendor uses one or more frontier-lab models under the hood. Targets that have hard-coded a single provider (OpenAI-only with no abstraction layer; Anthropic-only with hard dependencies on Claude-specific tool formats) are targets the acquirer cannot move to its preferred provider without a rewrite. Targets with an open abstraction layer (LiteLLM, OpenRouter, Portkey, or a clean in-house provider interface) can be moved in a sprint. The diligence question is whether the target's code can run against the acquirer's model gateway tomorrow, or in a year.

Sixth, customer concentration on agent-specific contracts. A SaaS vendor's customer concentration matters because losing a large customer is a revenue hit. An agent vendor's customer concentration matters more because the agent-specific contract terms often include uptime SLAs, model-version-pinning rights, custom eval-set commitments, and indemnification carve-outs that the acquirer is now obligated to honor for the contract life. A 40% customer concentration in three logos, each with a custom eval suite the target maintains, is forty percent of the acquired engineering team's bandwidth locked into legacy maintenance for the next three years.

Agent vendor diligence is SaaS diligence plus six new surfaces: eval-set quality, observability transparency, prompt and model versioning, MCP and Skills compatibility, escape-hatch openness, and agent-specific contract overhang. Strategists who skip any of these inherit the cost as a surprise twelve months after close.

The Thirty-Question DD Pack

The strategist runs thirty questions across seven categories. The pack is delivered to the target as a single document the week the LOI lands, with a two-week response deadline. Targets that cannot answer in two weeks are targets whose internal documentation is not real. The questions are written so that "we cannot answer that" is itself the answer; the scorecard accounts for non-responses as evidence.

Category one: eval-set quality (questions 1-5)

Question 1: Provide the current eval set for the three highest-traffic production agents. Include eval cases, ground-truth labels or rubric definitions, and the eval runner configuration (Braintrust project, Promptfoo config, or in-house equivalent). The strategist looks for case count (per-agent eval sets below 200 cases are thin; above 1,000 are mature), case freshness (more than 30% of cases authored in the last 90 days indicates active maintenance; less than 5% indicates the eval set is frozen), and rubric clarity (LLM-as-judge rubrics with operationalized definitions versus "is this good, true/false" which is uninstrumented).

Question 2: Provide the most recent six monthly eval reports showing per-case pass rate trends by agent. The strategist looks for trend direction (flat is healthy; declining without acknowledgment is unhealthy; rising suspiciously is often eval-set goodharting where the team added easy cases to inflate scores).

Question 3: Provide the eval-set regression history for every model upgrade in the last twelve months. For each upgrade, show before/after pass rates per agent and the remediation actions taken on regressions. The strategist looks for evidence the target gates model upgrades on eval pass rates and has an actual remediation playbook (the answer "we just upgraded and watched what happened" is a fail).

Question 4: Show three eval cases that the target's lead eval engineer is most embarrassed by — the cases where the agent fails in ways the team has not yet figured out how to fix. The strategist looks for the team's epistemic honesty (a target with no embarrassing cases is a target with no real evals); the strategist also looks for the failure modes themselves (failures in tool sequencing, in numeric reasoning, in long-context recall are common and forgivable; failures in basic policy compliance or PII handling are not).

Question 5: Provide the per-customer custom eval extensions. For each top-10 customer with a custom eval suite, show the case count, the maintenance owner, and the contract clause that obligates the target to maintain it. The strategist is sizing the post-acquisition maintenance load and the contractual cost of failing to honor it.

Category two: observability transparency (questions 6-10)

Question 6: Show the production observability stack. Which tool (LangSmith, Langfuse, Helicone, Arize Phoenix, in-house) is the source of truth for traces? What is the trace retention policy (30 days is thin; 90 days is standard; 12+ months is mature for high-stakes domains)?

Question 7: Demonstrate the customer-facing trace UI. Can customers see their own agent's traces? At what redaction level? Is there a customer audit-log export? Vendors that hide traces from customers are vendors whose customers do not trust them; vendors that expose traces are vendors whose customers verify quality independently.

Question 8: Show the team's own trace-review cadence. Provide trace-review meeting notes for the last six weeks for each production agent. The strategist looks for evidence of active maintenance — named owners, identified failure modes, follow-up eval cases added, prompt revisions shipped, regressions caught early.

Question 9: Provide the incident postmortems for the last twelve months of agent-related incidents. The strategist looks for whether the postmortem identifies root cause at the prompt/tool/model layer (good) versus blaming "the model hallucinated" with no further analysis (bad). Targets that cannot produce postmortems either do not have incidents (suspicious; agents always have incidents) or do not write them down (worse).

Question 10: Show the alerting and on-call rotation for production agents. The strategist confirms agents are treated as production systems — there is an on-call, there are alerts on eval pass rate drops, there are alerts on cost spikes, there are alerts on tool error rates.

Category three: MCP and Skills compatibility (questions 11-15)

Question 11: List every tool integration the target ships, classified as MCP-native, MCP-wrappable, or proprietary-non-MCP. For non-MCP integrations, provide the engineering estimate to convert each to MCP. The strategist is sizing the integration-rewrite backlog; non-MCP integrations are six weeks to six months each depending on complexity.

Question 12: For agent capabilities, classify each as a Skills-compatible bundle (file-system convention with SKILL.md, scripts, and resources), a structurally similar in-house format that can be converted, or a tightly coupled proprietary capability format. Skills compatibility is the difference between a capability the acquirer can move into its own platform in a week and one that requires a rewrite.

Question 13: Show how the target authenticates and authorizes tool calls. Is there OAuth 2.1 with PKCE for user-context calls? Is there a per-tenant credential vault? Are tool calls logged with the user identity that initiated them? Vendors with weak auth on tool calls are vendors whose acquirer inherits a security incident.

Question 14: Show the model abstraction layer. Is the target using LiteLLM, OpenRouter, Portkey, or an in-house provider interface? Or are model calls hard-coded against a single provider's SDK? The strategist is sizing the cost of routing the target's traffic through the acquirer's preferred gateway.

Question 15: Provide the production cost per agent per month, broken out by model provider, token category (cached vs uncached, input vs output), and tool-call cost. The strategist is confirming the target has cost-attribution discipline (without per-agent attribution, the acquirer cannot post-merge consolidate spend or apply chargeback).

Category four: model and prompt versioning discipline (questions 16-20)

Question 16: Provide the prompt change history for the three highest-traffic production agents over the last six months. The strategist looks for git-style version control (PromptLayer, LangSmith Hub, in-house git-backed prompt store, or Anthropic's prompt management) with named authors, change descriptions, and eval-set links.

Question 17: For each model upgrade in the last twelve months, provide the A/B test result that gated the upgrade. The strategist looks for evidence of canary deployment (5% traffic, then 25%, then 100%) and the rollback decision tree.

Question 18: Show the prompt-and-model pinning strategy for customer contracts. Which customers have contractual rights to pinned model versions or prompt versions? What is the cost of maintaining those pins? The strategist is sizing the legacy maintenance obligation.

Question 19: Show the prompt-injection and jailbreak red-team report from the last quarter. The strategist looks for evidence the target has run an active adversarial test (not just "we use OpenAI's safety filters") and has remediated findings with prompt or tool-layer defenses.

Question 20: Show the structured-output reliability metrics. For agents that return JSON or structured data, what is the schema-validation failure rate? Targets above 2% structured-output failure are targets with fragile output handling.

Category five: escape-hatch openness (questions 21-24)

Question 21: List the load-bearing third-party dependencies that, if removed, would degrade the product within 90 days. The strategist looks for hard dependencies on single-provider SDKs, single-vendor vector databases, or proprietary fine-tuned models the target does not own.

Question 22: Provide the data-portability story for customer data. If a customer wants to leave, what data can they export, in what format, on what timeline? Targets without a credible data-portability story are targets whose customers feel trapped and will churn under acquirer ownership.

Question 23: Show the build-from-source-of-truth runbook. If the acquirer wants to rebuild the product from scratch on the acquirer's preferred stack, can the strategist do it in six months using the eval set, the prompt history, and the tool-integration specs? If not, what is missing? The strategist is calibrating build-cost-if-they-disappear as a negotiation lever.

Question 24: For open-source components the target ships or depends on, what is the license posture? Is the target itself open-source under AGPL/Apache/MIT (the OSS license affects what the acquirer can do post-close)? Are there any GPL contamination risks in the target's stack?

Category six: customer concentration (questions 25-27)

Question 25: Provide the top-20 customer revenue concentration. Show the percentage of ARR from each. The strategist looks for the standard concentration risk (more than 20% of ARR from one customer is high concentration; more than 50% from top-3 is extreme).

Question 26: For the top-10 customers, show the contract specifics that survive a change of control: uptime SLAs, model-version-pinning, custom eval-set commitments, indemnification carve-outs, and data-residency commitments. The strategist is sizing the obligations the acquirer inherits.

Question 27: Provide the customer churn analysis for the last twelve months. For each lost customer above $50K ARR, show the reason for loss. The strategist looks for patterns — quality issues, integration friction, pricing, competitor wins — that will accelerate post-acquisition.

Category seven: team and IP (questions 28-30)

Question 28: Provide the engineering org chart with tenure and equity vesting status for everyone above L5 (or equivalent). The strategist is identifying the key-person risk and the retention plan the acquirer will need.

Question 29: Provide the IP assignment status. Are all founders' inventor agreements in place? Are there any open-source contributions from employees that were not properly cleared? Any disputed patents?

Question 30: List every model provider, infrastructure provider, and data vendor with which the target has a contract above $50K annual. For each, show the renewal date, the change-of-control clause, and the price-protection terms. The strategist is sizing the post-close vendor-renegotiation backlog.

The Red/Yellow/Green Scorecard the Corp-Dev Team Will Trust

The thirty questions produce a scorecard. The scorecard is the artifact the strategist hands the corp-dev lead, the head of M&A, and the executive sponsor of the deal. It is a single page. Each of the seven categories receives a red/yellow/green rating with a one-sentence justification and a quantified consequence.

The scorecard format

One row per category. Three columns: Rating (red/yellow/green), Justification (one sentence), Consequence (a dollar number or a time number). Example: "Eval-set quality: YELLOW. Per-agent case counts are below 500 for 7 of 12 production agents; eval-set regression history for the GPT-5.2 upgrade is missing. Consequence: 4-6 months of post-acquisition eval-set buildout costing $400K-$700K in engineering time before the agents are operable inside our platform."

The scorecard is the only document executives read. Long memos do not survive the deal room. A one-page red/yellow/green with quantified consequences is what gets debated, what gets edited, and what becomes the basis for the offer price adjustment.

The thresholds for each category

Eval-set quality. Green: per-agent case counts above 500 for 90% of production agents; six months of monotonic-or-improving pass-rate trends; complete regression history for model upgrades; embarrassing cases identified and prioritized; customer-specific eval extensions documented. Yellow: 50-90% on case counts; partial regression history; team can identify failure modes verbally but documentation is sparse. Red: case counts below 200 for majority of agents; no regression history; pass-rate trend is declining without acknowledgment; team cannot produce embarrassing cases (suggests no real evals).

Observability transparency. Green: production stack uses one of the named tools (LangSmith, Langfuse, Helicone, Arize Phoenix) or a credible in-house equivalent; 90+ day trace retention; customer-facing trace UI with audit export; weekly trace-review cadence with notes; postmortems for all incidents above a defined severity. Yellow: observability exists but is not customer-facing; trace reviews are monthly not weekly; postmortems are inconsistent. Red: no customer-facing observability; no trace-review cadence; "the model hallucinated" is the dominant postmortem root cause.

MCP and Skills compatibility. Green: 80%+ of tool integrations are MCP-native or MCP-wrappable in under two weeks each; capabilities are Skills-compatible or structurally similar; model layer is abstracted via LiteLLM/OpenRouter/Portkey or clean in-house interface; OAuth 2.1 with per-tenant credentials. Yellow: 40-80% MCP-convertible; capability format is proprietary but documentable; model layer has thin abstraction. Red: integrations are bespoke; capabilities are tightly coupled; model layer is hard-coded to single provider; auth model is brittle.

Versioning discipline. Green: git-style prompt version control with named authors and eval links; A/B-gated model upgrades with documented decision trees; named customer pinning obligations with sized maintenance cost; quarterly red-team report; structured-output failure rate under 1%. Yellow: prompts are versioned but not eval-linked; model upgrades are canaried but not rigorously A/B'd; pinning obligations exist but are not sized; red-team is annual. Red: prompts change without version control; model upgrades are big-bang; no red-team; structured output fails above 2%.

Escape-hatch openness. Green: no single-provider hard dependencies; data portability is documented and tested; build-from-source-of-truth runbook is plausible in 6 months; license posture is clean. Yellow: one or two hard dependencies but with documented workarounds; data portability is partial; rebuild would take 9-12 months; minor license cleanup needed. Red: deep hard dependencies on single providers; no data portability; rebuild estimate is 18+ months; license posture has material risk (GPL contamination, disputed IP).

Customer concentration. Green: top customer is under 15% ARR; top-3 under 35%; change-of-control survivability for top-10 is documented and acceptable; churn analysis shows fixable patterns. Yellow: top customer 15-25%; top-3 35-50%; some onerous contract overhangs but bounded; churn shows mixed patterns. Red: top customer above 25%; top-3 above 50%; significant contract overhangs (multi-year pinning, custom eval sets at acquirer's cost, indemnification carve-outs); churn shows accelerating patterns.

Team and IP. Green: key engineering leads have 2+ years of vesting remaining or signed retention packages; IP assignments are clean; OSS clearances documented; no patent disputes; vendor contracts have favorable change-of-control terms. Yellow: 1-2 year vesting; IP cleanups are minor; some vendor contracts trigger on COC but at known cost. Red: founders or key leads are fully vested with no retention; IP has open questions; vendor contracts trigger material repricing on COC.

The aggregate verdict

The strategist does not just hand over seven category ratings. The strategist hands over an aggregate verdict — Recommend / Recommend with Conditions / Do Not Recommend — and a price-adjustment recommendation tied to the yellow and red ratings. The conditions on a "Recommend with Conditions" verdict are specific: "Recommend with Conditions: (1) seller funds first $500K of MCP integration rewrite, (2) seller delivers eval-set buildout to 500+ cases per agent before close, (3) acquisition price reduced by $X reflecting top-3 customer concentration risk." The corp-dev team negotiates with these in hand.

Three Named 2026 Deals the Strategist Learns From

Three deals from the first half of 2026 illustrate what good and bad agent vendor diligence looks like at scale. Each has a publicly-discussable pattern the strategist can map onto a target.

OpenAI / Promptfoo (March 2026)

OpenAI's acquisition of Promptfoo in March 2026 was a textbook example of frontier-lab absorption of the open-source eval layer. The strategic logic was straightforward: Promptfoo had become the de facto open-source eval tool by late 2025; OpenAI's developer tools had a gap in customer-facing eval; integration would close that gap and lock in developer mindshare against Anthropic and Google. The diligence story (publicly inferable) was strong on eval-set quality and observability transparency (Promptfoo's whole product is evals); strong on MCP compatibility (Promptfoo had shipped MCP support in late 2025); moderate on customer concentration (open-source distribution diffuses concentration but the enterprise contract base was thin); strong on team retention (founders signed multi-year packages with explicit roadmap influence). The deal closed at a price that reflected the strategic fit and the eval-set asset value, not the standalone revenue.

The lesson for the strategist: when the target's product is the diligence answer (an eval vendor will pass eval-set quality; an observability vendor will pass observability transparency), the diligence focus shifts to the other five categories. The price the acquirer pays is for the strategic fit; the diligence verifies the strategic fit is real.

Salesforce / Informatica (closed March 14, 2026)

Salesforce's $8B acquisition of Informatica, which closed on March 14, 2026, was driven primarily by the data-integration layer Salesforce needed for Agentforce. The diligence story here was different: Informatica had decades of integration assets, deep customer relationships in regulated industries, and a substantial customer-concentration footprint with very long contract overhangs. The integration risk was not the agent-stack diligence categories (Informatica was not primarily an agent vendor); it was the cultural and product-integration risk of folding a thirty-year-old data-integration company into a CRM-platform giant. The strategic value was the data fabric for Salesforce's agents; the diligence focus was on contract overhangs, customer-data-residency commitments, and the integration roadmap timeline.

The lesson for the strategist: not every agent-adjacent deal is an agent deal. Sometimes the agent-platform strategist is being asked to evaluate a target whose value is the data, the distribution, or the regulatory posture that the company's agents will sit on top of. The diligence pack reweights but does not change.

The vertical-agent rollups (Q1-Q2 2026)

Between January and May 2026, multiple vertical agent companies were acquired by incumbents in their categories. Three legal-tech agent vendors went to Thomson Reuters, LexisNexis, and Clio. Two revenue-cycle-management healthcare agent companies went to athenahealth and Waystar. Four insurance-claims agent companies went to Guidewire and three carrier-owned tech subsidiaries. The pattern: incumbents that had under-built agents themselves bought the vendors that had shipped first, often at premiums (5x-9x revenue) that reflected the multi-year head-start the acquirer was buying.

The diligence pattern across these deals was uneven. The deals that went well shared a common diligence story: green on eval-set quality and observability (the verticals demanded it); green on MCP and Skills compatibility (the customers were already integrating against MCP); yellow on customer concentration (vertical specialists concentrate, but the acquirer's customer base absorbed the risk). The deals that struggled shared a different pattern: red on versioning discipline (the target had been moving fast and breaking things); red on escape-hatch openness (the target was hard-coded to one provider, often Anthropic or OpenAI, and the acquirer's enterprise customers demanded multi-provider); yellow-to-red on team retention (founders left within twelve months because the acquirer's processes were incompatible with the speed they had been operating at).

The lesson for the strategist: in a vertical rollup, the team-and-IP category often matters most. The acquirer is buying a team that knew how to build for a specific vertical faster than the acquirer could; if that team leaves, the acquirer is left with code they cannot maintain.

The 2026 deals teach three patterns. When the target's product is the diligence answer (eval vendor, observability vendor), focus diligence on the other surfaces. When the target is agent-adjacent (data, distribution), reweight to contract overhangs and integration roadmap. When the target is a vertical rollup, team retention is the deal.

The Week-by-Week Diligence Process

The strategist runs the diligence on a four-week timeline. Beyond four weeks, the deal slows and competing bidders catch up; under four weeks, the diligence is shallow and the acquirer overpays for what they cannot verify. The four weeks have specific cadences and deliverables.

Week one: pack delivery and access setup

Day 1: deliver the 30-question DD pack with two-week response deadline. Day 2: set up data room access — eval-set repositories, observability dashboards, prompt-history exports, contract repositories. Day 3-5: the strategist's team triages first responses, identifies gaps, and schedules week-two technical sessions. By end of week one, the strategist has a preliminary view on at least the first two categories (eval-set quality and observability transparency) because these can often be verified directly from the data room without depending on target responses.

Week two: technical sessions

Five technical sessions, each 90-120 minutes, each with a specific surface. Session 1: live eval-set walkthrough — the target's lead eval engineer runs the eval set on a high-traffic agent live, the strategist watches the output. Session 2: live trace review — the target conducts an actual trace review meeting with the strategist observing. Session 3: live deployment walkthrough — the target deploys a prompt change end to end with the strategist watching the version control, the eval gate, the canary, and the rollout. Session 4: integration architecture walkthrough — the target's lead engineer walks through the tool integration patterns, the MCP coverage, the auth model. Session 5: cost and observability dashboard walkthrough — the target shows per-agent cost attribution, alerting, and incident dashboards. By end of week two, the strategist has direct evidence on five of seven categories.

Week three: commercial and contract diligence

The strategist's commercial counterpart (corporate development, finance) takes the lead. Customer reference calls (5-8 of the top-20 customers, including at least 2 of the top-3). Contract review of the top-10 customer contracts. Vendor contract review for change-of-control implications. IP and HR review for team-and-IP category. The strategist participates in customer reference calls to ask agent-specific quality questions ("does the target's eval set actually predict the failures you see?"). By end of week three, the strategist has the full evidence base for all seven categories.

Week four: scorecard, verdict, and price-adjustment recommendation

The strategist produces the scorecard and the aggregate verdict. The strategist meets with the corp-dev lead to walk through the yellow and red ratings and propose conditions for a Recommend with Conditions verdict, or price-adjustment recommendations for a Recommend. The strategist also produces a short integration-readiness memo — what the first 90 days of post-acquisition integration would look like at the current diligence findings — that feeds directly into the post-acquisition integration playbook the strategist will run if the deal closes.

The Anti-Patterns Strategists Avoid

Five anti-patterns recur across botched agent-vendor diligence efforts. Each has a named symptom and a named fix.

The demo-driven diligence

Symptom: the strategist watches a polished sales demo of the target's product, finds it impressive, and assumes the underlying engineering matches the polish. Fix: refuse to accept demos as evidence. Require live eval runs, live trace reviews, live deployments. Demos are sales theater; the diligence pack is the production reality.

The "we will fix it post-close" delusion

Symptom: the strategist identifies a yellow or red rating, the corp-dev team waves it off as "we will fix it after the acquisition," and the deal closes at the unadjusted price. Fix: insist that every yellow or red has a quantified consequence and a named owner for post-close remediation. If the consequence is $700K of post-close engineering, the price comes down by $700K or the deal does not close.

The single-bidder collapse

Symptom: the strategist is the only bidder and concludes diligence is less critical because the seller has no leverage. Fix: diligence quality determines the post-close failure rate, not the negotiation position. Single-bidder situations often hide why no one else is bidding — diligence is the only way to find out.

The acquirer-blind-spot ratings

Symptom: the strategist's own platform has the same yellow ratings (the acquirer also lacks rigorous prompt versioning) and so the strategist underweights the target's yellow. Fix: the diligence rating is absolute, not relative to the acquirer's own posture. Buying a target that has the acquirer's weaknesses compounds the weakness; the strategist either accepts the compound or proposes the integration plan that addresses both at once.

The eval-set theater

Symptom: the target presents a polished eval-set artifact that looks comprehensive but is not actively used in production deployment gating. Fix: confirm the eval set is the gate, not the report. Require the target to demonstrate a prompt change being blocked by an eval-set regression. If the target cannot show such a case, the eval set is theater and the rating is red.

Key Takeaways

• Agent vendor diligence is SaaS diligence plus six surfaces: eval-set quality, observability transparency, prompt and model versioning, MCP and Skills compatibility, escape-hatch openness, and agent-specific contract overhang. Strategists who skip any of these inherit the cost as a post-close surprise.
• The 30-question DD pack is delivered to the target at LOI with a two-week response deadline. Targets that cannot respond in two weeks are targets whose internal documentation is not real; the non-response is itself diligence evidence.
• The seven categories are eval-set quality (5 questions), observability transparency (5), MCP and Skills compatibility (5), versioning discipline (5), escape-hatch openness (4), customer concentration (3), and team and IP (3).
• The output is a one-page red/yellow/green scorecard with quantified consequences per category. Long memos do not survive deal rooms; the one-pager is what executives debate and what becomes the basis for the offer-price adjustment.
• The aggregate verdict is Recommend / Recommend with Conditions / Do Not Recommend, with specific conditions or price adjustments tied to yellow and red ratings.
• The OpenAI/Promptfoo deal (March 2026), Salesforce/Informatica close (March 14, 2026), and the Q1-Q2 2026 vertical-agent rollups each teach a different diligence reweighting pattern.
• The four-week diligence cadence is pack delivery (week 1), technical sessions (week 2), commercial diligence (week 3), scorecard and verdict (week 4). Shorter timelines produce shallow verdicts; longer timelines lose deals.
• Five anti-patterns to avoid: demo-driven diligence, the "we will fix it post-close" delusion, single-bidder complacency, acquirer-blind-spot ratings, and eval-set theater. Each has a named fix.
• The strategist's diligence work feeds directly into the post-acquisition integration playbook — the same yellow and red ratings become the 90-day integration backlog.