The deal closed on a Friday. By Monday morning, the strategist's calendar had nineteen new meetings, two integration leads from the acquired team had already given notice, and the company's CIO was asking when the duplicate eval frameworks would be down to one. The post-acquisition window is short, the political capital is finite, and the failure mode is well-known: two parallel agent platforms that never merge, that quietly drift, and that twenty-four months later represent the most expensive and least defensible architectural state the company has ever produced. This lesson is the 90-day post-acquisition integration playbook for an acquired agent capability — the day-by-day work that turns a closed deal into a unified platform. Identity migration on day one. MCP allowlist merger by week three. Eval-set consolidation by week six. Cost-attribution re-tagging by week eight. Sunset of duplicate stacks by week twelve. A North Star architecture diagram the acquired team helps write. A sponsor accountable for the cutover. And a explicit recognition that the strategist who waits past the 90-day window for any of these inherits the parallel-platform failure mode for the rest of their tenure. The diligence work feeds directly in — the yellow and red ratings on the scorecard become the 90-day backlog. The strategist who runs the integration is, ideally, the strategist who ran the diligence.

Why the 90-Day Window Is the Only Window

Post-acquisition integration has a tight timing logic and most strategists underestimate how tight. The first ninety days are the only period when the acquirer has the political capital, the acquired team's attention, and the executive sponsorship aligned to make structural integration decisions. After ninety days, attention drifts to the next deal or the next quarterly priority; integration becomes "we'll get to it"; and the parallel-platform pattern hardens into the company's operating reality.

What the 90-day window actually buys

The window buys five things. First, identity decisions — single-sign-on (SSO), directory consolidation, permission model alignment — can be made unilaterally because the acquired team has not yet formed habits around their own auth posture inside the acquirer. After ninety days, anyone who has been working in the company a quarter has habits, and habits become political. Second, MCP and tool-integration decisions — which connectors the unified platform exposes, which custom integrations are sunset — happen while the acquired team's tool inventory is still freshly documented from diligence. Third, eval-set merger — combining the two teams' eval sets into a single source of truth — happens before the eval sets diverge further with continued independent development. Fourth, cost-attribution re-tagging — moving the acquired team's spend into the acquirer's cost-attribution model — happens before the next quarter's chargeback cycle. Fifth, duplicate-stack sunset — explicitly retiring one of the two platforms — happens while the acquired team's engineers can still help with the migration before they leave.

What happens if you miss the window

The failure mode is two parallel agent platforms that never merge. The strategist sees the pattern in every botched acquisition in the 2024-2026 dataset: the company runs the acquired team's platform alongside the acquirer's platform; both platforms continue to develop; their evals diverge; their cost-attribution models diverge; their identity models diverge; their MCP allowlists diverge; their model providers diverge. Twenty-four months later, the company has two production agent platforms with no clear sunset path and a cost structure that is roughly 1.7x what either platform would cost standalone. Half the engineering team supports each; the eval cases on platform A are not portable to platform B; customer contracts pin specific agents to specific platforms. The strategist who allowed this pattern to take hold has produced the most expensive architectural state the company has ever produced.

This is not a hypothetical. Three of the eleven significant agent acquisitions in 2024 went this way; two of the seven in early 2025; preliminary signals on two of the early 2026 deals suggest the same pattern is forming. The strategist who knows this and acts in the 90-day window avoids it. The strategist who treats integration as a "we'll sort this out over the year" project becomes the case study.

The 90-day window is the only window. After 90 days, attention drifts, habits form, and the parallel-platform pattern hardens into the company's operating reality. Three of eleven 2024 acquisitions, two of seven early-2025 acquisitions, and two of the early 2026 deals show the pattern. Strategists who know this and act in the window avoid it. Strategists who do not become the case study.

Day-One Actions: Identity, Access, and Communication

Day one is not "start planning." Day one is execution on a small number of decisions that have to be made immediately to keep both sides functional and to signal that the integration is happening on a timeline. The actions are concrete, named, and observable by the end of week one.

Identity migration

The acquired team's accounts and permissions are migrated into the acquirer's identity provider on day one or week one at the latest. If the acquirer uses Okta, every acquired-team account gets an Okta identity tied to a corporate email alias. If the acquirer uses Azure AD or Google Workspace, the equivalent applies. Permission groups are mapped on a documented framework: the acquired team's "agent platform admins" map to the acquirer's "agent-platform-admins" group, with explicit translations for any groups that do not have a direct equivalent.

This is not glamorous work and it is often delegated to IT. The strategist's involvement is to ensure the mapping is correct for agent-specific permissions: who can deploy a prompt change to production, who can approve a model upgrade, who has read access to traces, who can modify eval sets. Mis-mapped agent permissions in week one become security incidents in week six.

Access to the acquirer's platform

The acquired team gets read-only access to the acquirer's existing agent platform in week one — to the observability dashboards (LangSmith, Langfuse, Helicone, or Arize Phoenix), the eval framework (Braintrust, Promptfoo, or in-house), the model gateway (LiteLLM, OpenRouter, Portkey, or in-house), the prompt repository, and the trace-review meeting calendar. They are not yet expected to use it as their primary platform; they are expected to see what the acquirer has so that integration discussions can be specific rather than abstract.

Conversely, the acquirer's platform team gets read-only access to the acquired team's stack — eval sets, traces, prompts, integration code. The mutual access enables the integration team to do real work in week two and beyond.

The cutover communication

By end of day one, both sides know who the integration lead is, what the 90-day plan looks like at a one-page level, and what the executive sponsor's role is. The communication is not a deck; it is a one-page memo sent to both teams that names the lead, names the sponsor, names the weekly cadence (a standing 60-minute integration-team meeting), and names the four major milestones (identity migration done, MCP merger done, eval consolidation done, duplicate stacks sunset). The memo is dated; the dates are committed publicly; the integration lead is accountable for them.

The acquired team's existing communication channels are connected to the acquirer's. Their Slack workspace is either bridged or migrated; their on-call rotation is aware of the acquirer's on-call rotation; their incident response process is reconciled with the acquirer's. By end of week one, an on-call from the acquired team can reach the acquirer's on-call without a tribal-knowledge lookup.

The day-one anti-patterns

Three anti-patterns appear in week one. (1) "Let's wait until we know each other better" — the strategist delays identity migration to "build relationships first"; six weeks later identity is still pending and the acquired team is operating in a parallel auth domain that is hardening into permanent. (2) "We'll move them onto our platform when they're ready" — the strategist defers platform access until the acquired team requests it; the request never comes because they have their own working platform; integration stalls. (3) Public communication that does not name the timeline — "we are excited to be working together and will share more details soon" is the language that signals the integration will not happen on a schedule.

The Three-Week Arc: MCP Allowlist Merger

Weeks two and three are the MCP and tool-integration merger. The work has three deliverables: a unified MCP allowlist, a tool-deprecation plan for duplicate integrations, and a migration path for any acquired-team-specific tools the acquirer's customers will adopt.

The unified MCP allowlist

By end of week three, the company has one MCP allowlist that serves both teams. The allowlist is a documented list of every MCP server the company permits its agents to call. Each entry has: server name, owner, auth model (OAuth 2.1 with PKCE, service account, etc.), data-classification level (which categories of data the server can receive and return), and a deprecation status (live, planned-deprecation with date, or sunset).

The merger work is mechanical but tedious. The acquired team's tool inventory (collected in the diligence pack) is mapped against the acquirer's allowlist. Each tool falls into one of four buckets: same tool on both sides (use the acquirer's version, sunset the acquired team's); equivalent tool on both sides (pick one, document the rationale, sunset the other); acquired team has a tool the acquirer needs (add to the acquirer's allowlist after security review); acquired team has a tool the acquirer does not need (sunset or quarantine).

The tool-deprecation plan

For every tool being sunset, the plan names the agents that depend on it, the migration target, the engineer responsible for the migration, and the date by which the migration must complete. The deprecation plan is published as a single document with one row per deprecated tool. Total tool deprecations from a typical agent acquisition: 8-25 tools, of which 4-12 are non-trivial migrations.

The plan also names tools that are explicitly not being merged — for instance, a customer-facing tool that the acquired team's customers depend on and that the acquirer will continue to maintain in parallel for contractual reasons. Explicit non-merger is the strategist's tool against the "merge everything" pressure that often comes from the acquirer's platform team; some parallelism is permanent and that is acceptable as long as it is explicit.

Authentication and credential reconciliation

The acquired team's tool credentials are migrated to the acquirer's secret-management system (Vault, AWS Secrets Manager, Azure Key Vault, or equivalent). Per-tenant credentials, where they exist, are mapped to the acquirer's per-tenant model. Service-account credentials for shared infrastructure are rotated and re-issued in the acquirer's auth domain.

This is the work that, if delayed, produces the security incident in month four. The acquired team's credentials sit in their original locations, with their original rotation policies (which may be loose), and with access patterns that the acquirer's security team cannot audit. A credential leak in this state becomes a six-month incident-response project.

The Six-Week Arc: Eval-Set Consolidation

Weeks four through six are the eval-set consolidation. The deliverable is a single source of truth for evals across both teams, with a documented merger plan for cases that were previously split.

The eval-set inventory

The strategist starts by cataloging both teams' eval sets. For each agent on each side: case count, case authoring history, runner (Braintrust project, Promptfoo config, in-house), rubric type (deterministic, LLM-as-judge with rubric, hybrid), CI integration status, and customer-specific extensions. The catalog is usually a spreadsheet with one row per (team, agent, eval-set) tuple.

The catalog reveals the merger pattern. Typically there are three patterns: (1) the two teams have evals for the same domain (support, claims, sales-ops) and the eval sets need to be merged because the underlying use case is the same; (2) the two teams have evals for different domains and the eval sets just need to be unified in the same runner; (3) the two teams have evals for the same domain but on intentionally different model providers, and the merger requires creating a provider-agnostic case set with provider-specific assertions.

The merger plan

The merger plan is published with one row per (consolidated-agent, source-eval-set) tuple. For each row: the disposition (keep as-is, port to acquirer's runner, port to acquired team's runner, retire), the engineer responsible, the date, and the eval-coverage baseline expected post-merger (number of cases per agent, target pass rate, ownership for ongoing maintenance).

The plan also handles the runner consolidation. If the acquirer is on Braintrust and the acquired team is on Promptfoo, the plan names which runner becomes the source of truth (often the acquirer's, but not always — sometimes the acquired team's tooling is better and the acquirer adopts it). The non-chosen runner is sunset over the eval-merger period; cases are ported with their full history (authors, dates, regression notes) preserved.

The CI integration

By end of week six, every production agent (from both teams) has CI-gated eval runs in the unified runner. Prompt changes cannot ship without the eval gate. Model upgrades require eval-set regression review. Trace-review meetings reference the unified eval set. The eval set is the gate, not the report.

This is the most consequential consolidation in the entire 90-day playbook. Eval-set unification is the technical step that makes parallel-platform sunset possible. Without it, each team has its own quality measurement and there is no shared definition of "ready to ship." With it, the two teams share a quality standard and have something to negotiate against during the duplicate-stack sunset.

The Eight-Week Arc: Cost-Attribution Re-Tagging

Weeks seven and eight are the cost-attribution re-tagging. The deliverable is that every dollar of agent-related spend across both teams is tagged in the acquirer's cost-attribution model and flows to the right cost center.

The spend inventory

The strategist catalogs every spend source from both teams: model providers (OpenAI, Anthropic, Google, hosted Llama), observability tools (LangSmith, Langfuse, Helicone, Arize Phoenix), eval tools, vector database (Pinecone, Weaviate, etc.), infrastructure (compute, storage, networking), and any third-party tool subscriptions tied to agent operation. For each: monthly run-rate, contract terms, change-of-control status, and renewal date.

The catalog often surfaces multiple instances of the same provider being paid separately by each team — duplicate Anthropic accounts, duplicate Pinecone subscriptions, duplicate LangSmith workspaces. These are immediate consolidation candidates with quick cost wins.

The tagging schema

Each agent gets a tag in the acquirer's cost-attribution model. The schema is typically (business-unit, product, agent-id, environment). Every model API call, every observability event, every eval run is tagged on emission. The work of tagging is largely done in the model gateway and the observability layer; the work of mapping the acquired team's existing tags into the acquirer's schema is done in the integration sprint.

The chargeback model is documented. Each business unit that has agents pays for those agents' spend through the cost-attribution flow. The acquired team's BUs are added to the chargeback model; if their customers were previously charged at a different rate, the strategist negotiates a transition (typically a 6-month grace period with old pricing, then conversion to the acquirer's pricing).

The model-provider consolidation

The acquirer's model-provider contracts (volume discounts, committed-use agreements, dedicated capacity) usually beat the acquired team's standalone contracts. The acquired team's traffic is routed through the acquirer's model gateway, which means the acquired team's spend benefits from the acquirer's negotiated rates. Typical savings: 15-35% on model spend within the first ninety days post-integration.

This is a savings number the strategist surfaces to the CFO as evidence of integration value. It is the most quantifiable benefit of the post-acquisition integration and the easiest one to defend; strategists who do not surface it leave money on the table both in actual savings and in political capital with finance.

The Twelve-Week Arc: Sunset of Duplicate Stacks

Weeks nine through twelve are the duplicate-stack sunset. This is the work that, if not done, produces the parallel-platform failure mode. It is the hardest political work in the playbook because someone's stack is being deprecated, and that someone is usually still on the payroll.

The North Star architecture diagram

By start of week nine, the integration team has produced a North Star architecture diagram showing the unified platform at end of 90 days. The diagram has named components — the model gateway, the observability stack, the eval runner, the prompt repository, the MCP allowlist, the secrets manager, the cost-attribution layer. Each component has a named owner from one of the two teams (or a hybrid owner pair). The diagram is signed off by the executive sponsor, the strategist, and the engineering leads from both teams.

The North Star diagram is the artifact that resolves debates. When week-eleven discussions about which observability tool to keep get heated, the diagram is the reference point. The diagram is not a wishlist; it is the committed end-state, and discussions are about how to get there, not whether to.

The sunset plan

For each duplicate component, the sunset plan names: which component is being retained, which is being deprecated, the migration path for users of the deprecated component, the migration deadline, and the engineer responsible. The plan also names the data preservation strategy — traces, eval-set history, prompt-change history, incident postmortems — to ensure no learning is lost in the migration.

Sunset of an observability tool, for example, looks like: end-of-week-nine, the deprecated tool stops accepting new writes; end-of-week-ten, all queries are redirected to the retained tool; end-of-week-eleven, the deprecated tool's data is exported and archived; end-of-week-twelve, the deprecated tool's contract is in renewal-negotiation status (typically negotiate a six-month wind-down for read-only access if customers need historical traces).

The sunset of the acquired team's platform (or the acquirer's)

The hardest sunset is the agent platform itself. Two patterns: most commonly, the acquired team's platform is sunset because the acquirer's is the long-term standard (this is the typical pattern). Less commonly, the acquirer adopts the acquired team's platform because the acquired team's tech is genuinely better. In either pattern, the sunset involves migrating agents from the sunset platform to the retained platform, one agent at a time, with each migration gated by passing the unified eval set on the retained platform.

Typical migration cadence: one agent per engineer-pair per two weeks. For a 12-agent acquired-team portfolio with 4 engineers paired into 2 pairs, the migration is 12 weeks. Strategists who attempt to migrate the entire portfolio in week 12 are strategists who produce production incidents; migrations are sequential and they take time. The 90-day playbook gets the migration started and produces the first three or four agent migrations; the remaining migrations finish in months 4-6.

The decision-making process for the sunset

The strategist does not make the sunset decisions alone. The decision-making process is documented: each duplicate component goes through a formal "platform decision" review with the engineering leads from both teams, the strategist, and the executive sponsor. The decision criteria are: technical fit (which tool serves the unified roadmap better), economic fit (TCO, contract terms, vendor relationship), and migration cost (which tool requires less migration work). The decision is documented in the platform team's decision log.

Decisions that go against the acquired team (their tool is sunset) are paired with explicit recognition of the acquired team's work and explicit roles for the acquired team's engineers in the retained tool's ongoing maintenance. Sunset decisions that strip the acquired team of ownership without giving them ownership somewhere else are sunset decisions that cause the acquired team to leave.

The Failure Mode: Two Parallel Platforms That Never Merge

The failure mode is well-defined and the strategist who recognizes it can avert it. The pattern is consistent across botched 2024-2026 integrations.

The five stages of parallel-platform drift

Stage one (weeks 1-12): integration is delayed beyond the 90-day window. The strategist accepts "we need more time to understand each other's stacks." Both platforms continue with their existing tooling.

Stage two (months 4-6): the two teams develop their own integration patches and tooling. The acquired team adds a feature to their eval framework; the acquirer adds a different feature to theirs. The feature sets diverge.

Stage three (months 7-12): customer-specific work entrenches the divergence. The acquired team's customers are pinned to the acquired team's platform; the acquirer's customers are on the acquirer's platform. Switching costs accumulate.

Stage four (months 13-24): each platform develops its own roadmap with its own headcount allocated. The combined org is now running two agent platforms with two roadmaps and two cost structures. Total agent-platform spend is approximately 1.7x what either platform would cost standalone.

Stage five (months 24+): the parallel-platform reality is treated as architecture. Future hires are made for one platform or the other. The merger is informally abandoned. The cost overhead is normalized as "the cost of doing business after the acquisition."

The signals the strategist watches for

Five early signals indicate the parallel-platform pattern is forming. (1) Integration milestones slip past their published dates without explicit rescoping. (2) The North Star architecture diagram is "in progress" past week 9. (3) The eval-set merger is "complex, will take more time" past week 6. (4) The MCP allowlist still has two lists past week 4. (5) The acquired team's senior engineers begin leaving in months 4-6 (which they do partly because they see the parallel platform is becoming permanent and their career is on the deprecated stack).

The strategist's response when signals appear

The strategist escalates immediately when signals appear. The escalation is to the executive sponsor and is explicit: "the integration is at risk of the parallel-platform failure mode; here are the specific milestones we are missing; here is what I need from you to get them back on track." The escalation is documented and the sponsor's response is documented. Sponsors who do not respond are sponsors whose deal is becoming the case study; the strategist needs to know which sponsors will engage and which will not, early enough to either get the deal back on track or to position themselves outside the eventual blame for the parallel-platform reality.

The Anti-Patterns Strategists Avoid

Five recurring anti-patterns in post-acquisition integration.

The "let them keep operating" delusion

Symptom: the strategist allows the acquired team to keep operating their own platform "for now" to avoid disruption. The "for now" never ends. Fix: every component has a sunset date in the 90-day plan, and the sunset dates are published.

The merge-everything pressure

Symptom: the acquirer's platform team pressures the strategist to merge every component, including ones that have legitimate reasons for parallelism (customer-pinned contracts, regulated-data domains). The strategist accepts and produces an unmergeable plan that loses credibility. Fix: explicit non-merger is named in the plan with documented reasons; non-merger is acceptable when it is intentional.

The acquired-team-as-resource fallacy

Symptom: the acquired team is treated as resources to support the acquirer's existing architecture without ownership of unified-platform components. Senior engineers leave within nine months because they have no ownership. Fix: every retained component in the unified platform has at least one owner from the acquired team. Ownership is what retains engineers.

The eval-set drift

Symptom: the eval-set merger is delayed past week six because "we need to agree on rubrics first." Eval sets continue to develop independently; merger gets harder by the week. Fix: merger happens in week six with imperfect rubrics; rubric harmonization is a subsequent project, not a prerequisite.

The cost-attribution debt

Symptom: cost-attribution re-tagging is delayed past week eight because "we need to redesign the chargeback model first." Spend continues to flow into untagged cost centers; finance loses visibility; the next quarter's chargeback cycle bills wrong. Fix: re-tagging happens against the existing schema in week eight; schema improvements are a subsequent project.

When the Integration Is Actually Complete

The 90-day playbook ends at week twelve with a defined end-state, but the integration is not "done" at week twelve. The strategist needs an explicit definition of complete to avoid the integration drifting indefinitely.

The end-of-90-days checkpoint

At end of week twelve, the strategist holds a checkpoint meeting with the executive sponsor, the integration team, and the engineering leads from both teams. The checkpoint reviews: identity migration (done, with metrics on permission-error rate), MCP allowlist merger (done, with the deprecation plan executed), eval-set consolidation (done, with all production agents on the unified runner with CI gating), cost-attribution re-tagging (done, with the next chargeback cycle running against the new schema), and duplicate-stack sunset (in progress, with the first 3-4 agents migrated and the plan for the remaining agents in months 4-6).

The checkpoint also identifies the components that did not meet their 90-day milestones, with explicit rescoping. Rescoping is acceptable; silent slippage is not. Each rescoped component has a new deadline and a new accountability.

The 6-month and 12-month checkpoints

The 90-day checkpoint is followed by 6-month and 12-month checkpoints with the same executive sponsor. The 6-month checkpoint confirms: all agents migrated to the unified platform, all duplicate vendor contracts wound down, and the unified eval-set covering all production agents with maintained per-agent case counts above the agreed threshold (typically 500+ for high-traffic agents). The 12-month checkpoint confirms: the integration has produced the model-spend savings, the unified roadmap is being executed by a single team structure (not two parallel teams), and the acquired team's retention is at or above the acquirer's company-wide baseline.

Integrations that hit all three checkpoints are integrations that worked. Integrations that miss any of them have entered the parallel-platform pattern and the strategist's escalation work begins again.

Key Takeaways

• The 90-day window is the only window for structural integration decisions. After 90 days, attention drifts, habits form, and the parallel-platform pattern hardens.
• Day one is execution, not planning: identity migration into the acquirer's IdP (Okta, Azure AD, Google Workspace); mutual read-only access to both platforms; one-page cutover memo naming lead, sponsor, cadence, and four major milestones.
• Weeks 2-3: MCP allowlist merger. One unified allowlist with documented owners, auth model, data-classification, and deprecation status. 8-25 tool deprecations typical; 4-12 non-trivial migrations.
• Weeks 4-6: Eval-set consolidation. Single source of truth in a chosen runner (Braintrust, Promptfoo, or in-house); CI-gated eval runs on every production agent; merger of overlapping cases; preserved history.
• Weeks 7-8: Cost-attribution re-tagging. Spend tagged in acquirer's schema; chargeback model documented; model-provider consolidation typically saves 15-35% on model spend.
• Weeks 9-12: Duplicate-stack sunset. North Star architecture diagram signed off by all parties; sunset plan with named owners and dates; first 3-4 agent migrations executed; remaining migrations in months 4-6.
• The failure mode is two parallel agent platforms that never merge. Five-stage drift pattern. Total cost ~1.7x standalone. Strategist watches for five early signals and escalates explicitly when they appear.
• Five anti-patterns: "let them keep operating" delusion, merge-everything pressure, acquired-team-as-resource fallacy, eval-set drift, cost-attribution debt. Each has a named fix.
• The integration is complete when the 90-day, 6-month, and 12-month checkpoints all pass. The 6-month checkpoint confirms full migration; the 12-month checkpoint confirms savings, unified roadmap execution, and acquired-team retention at or above company baseline.
• The diligence work feeds directly in: the yellow and red ratings on the DD scorecard become the 90-day backlog. The strategist who ran the diligence should run the integration.