IBM and Microsoft Will Sell You 6,000 Agents. None Are Yours

Last Updated: November 11, 2026

What was actually announced on 10 November

IBM and Microsoft launched Imagine Enterprise, described as an agentic platform for building, running and governing AI agents against industry-specific processes. IBM Consulting contributes more than 6,000 prebuilt AI agents and assets built on IBM Consulting Advantage, along with Process Studio, Context Studio and Advantage Core. Microsoft contributes Foundry, Copilot Studio, GitHub Copilot, Fabric, Microsoft 365, Entra, Purview, Defender and Azure. Both companies offer forward-deployed engineering support, and the press release is explicit that this applies to qualifying engagements.

Three delivery models are on offer: IBM Consulting deploys and operates the platform on your behalf, you co-innovate with IBM on an enterprise-scale implementation, or you self-manage. Industry frameworks launch with financial services, insurance and retail, with manufacturing, energy, public sector and mobility named as possible future additions.

The named reference is SEI, the financial-technology and asset-management firm that manages, advises or administers approximately $2 trillion in assets as of 30 September 2026. Read the SEI language carefully, because every write-up this week will round it up. The release says SEI is looking to advance its enterprise transformation by exploring emerging and agentic technologies. That is an exploration with intent, not a production deployment with a measured outcome. There is no published throughput number, no cycle-time delta, no cost baseline. Treat it as a logo, not as evidence.

Separately, IBM's launch blog states that 82% of global business leaders plan to deploy digital labor within eighteen months — a figure from IBM's own IBV study conducted with Microsoft, so it is a vendor survey supporting a vendor product. Useful directionally. Not a procurement input.

A prebuilt agent is a task template, not a deployed workflow

This is the single distinction that decides whether the 6,000 number means anything to you. A catalog agent ships with a role definition, a prompt scaffold, a set of expected inputs and outputs, usually a tool schema, and sometimes an evaluation set. That is genuinely valuable — it is three to six weeks of design work you do not repeat, and in insurance or claims it encodes domain decomposition most teams get wrong on the first attempt.

What it does not ship with is the part that takes the other 80% of the calendar. I have never seen a catalog item survive contact with a real estate of systems without the following five seams being built by hand:

Data contracts. The agent expects a claim object. Your claims system emits a 340-field record with four nullable date formats, a free-text adjuster note field that sometimes contains PII, and a status enum that three upstream systems disagree about. Someone writes that mapping, tests it against five years of historical records, and owns it when the upstream team ships a schema change on a Thursday.

Identity for non-human actors. Each agent needs a principal, a credential lifecycle, a scope, a sponsor and a deletion path. This is not a prompt problem.

Write-back permissions. Reading is easy. The moment an agent updates a policy record, posts a journal entry or sends a customer a settlement letter, you need per-action authority limits, approval gates, and an audit trail that a regulator will accept. IBM says governance controls define what each agent can act on autonomously and that agents cannot bypass defined authority limits. Good. Someone still has to enumerate those limits for every action in every process, and that enumeration is your work.

State between agents. Multi-agent processes fail on shared state far more often than on reasoning quality. Who holds the case context when the triage agent hands to the investigation agent? What is the idempotency key when the same first-notice-of-loss arrives twice? Catalog items are individually stateless by design; the state machine is yours.

Failure handling. Step four of seven fails after steps one through three have written to production systems. You need compensating actions, not retries. Almost no agent catalog ships compensation logic, because compensation is specific to your systems of record.

What is portable, and what quietly binds you

Lock-in in agentic platforms is not one switch. It is five layers with very different exit costs, and buyers routinely evaluate the cheap-to-leave layer while signing away the expensive one.

The identity row is the pleasant surprise. Microsoft Entra Agent ID is now generally available, with documented integration patterns for non-Microsoft agents including AWS Bedrock and n8n, a sidecar auth SDK, and a documented path to migrate Copilot Studio agents onto Agent ID. The same documentation notes that agent registry experiences are converging under Microsoft Agent 365. Practically: you can adopt Microsoft's identity and governance plane for agents you did not build in Copilot Studio. That matters, because it means buying the governance layer does not require buying the orchestration layer.

The orchestration row is where the money is. Once your claims hand-off graph lives as Copilot Studio topics and Advantage Process Studio artefacts, migrating is a rewrite, not an export. Ask the vendor for an actual export of a non-trivial multi-agent workflow during evaluation, not a statement that export is supported. I have watched more than one team discover that the export is a JSON blob which re-imports only into the product that produced it.

The forward-deployed engineer clause is a procurement signal

Forward-deployed engineering is the most operationally honest part of this announcement and the most commercially consequential. It is an admission by both vendors that the catalog does not deploy itself, that integration is bespoke, and that the gap between a demo and production is wide enough to need engineers sitting inside your building. That is correct, and it is more candid than most agent-platform marketing.

But for qualifying engagements is doing real work in that sentence. Neither company has published qualification criteria. In every FDE-style motion I have seen priced, qualification tracks committed platform spend, deal size, or reference value — not technical difficulty. Three questions decide whether this clause is worth anything to you:

Who qualifies? Get the threshold in writing: minimum committed Azure/Copilot spend, minimum consulting contract value, minimum number of workloads. If the answer is a relationship rather than a number, you are not qualifying.

How long do they stay? FDE engagements are typically measured in weeks to a couple of quarters. The useful number is not the start date, it is the exit criteria.

Who owns the run after they leave? This is the one that bites. The FDE builds the seams, and then the seams become a permanent operational liability: schema drift, model version changes, connector deprecations, prompt regressions, token cost creep. If your internal team cannot read and modify what the FDE built, you have converted a capability gap into a managed-service dependency at consulting rates.

The parallel path: rent the commodity steps, own the coordination

The architecture that survives a vendor change is boring and it has been stable for two years: let the catalog own the leaf tasks, keep the coordination graph on infrastructure you control.

Concretely, the leaf tasks are the genuinely commodity steps — document extraction, classification, summarisation against a known schema, policy-language lookup, draft generation. These are where a 6,000-item library earns its keep and where switching cost is near zero because the interface is a function call with a typed response. Rent them. Use Foundry models, use Copilot Studio agents, use IBM's insurance assets. There is no strategic advantage in writing your own first-notice-of-loss classifier.

The coordination layer is different. It holds your decision rights: which claims route to which adjuster authority level, when a human approval is mandatory, what the rollback is when a settlement letter has already gone out. That logic is the actual asset. Keep it in something you can read, diff and move — n8n for teams that want a visual graph with real version control, or a plain service in your own repo for teams with the engineering depth. Then use Entra Agent ID for identity across both, which Microsoft explicitly documents for n8n, so you keep enterprise identity and governance without surrendering the orchestration graph.

Two consequences worth being blunt about. First, this costs more up front than buying the whole stack — typically one to two additional engineers for a quarter. Second, it is the only version of this architecture where you can credibly run a competitive renewal. If you cannot move your workflow to a second platform in a quarter, your renewal price is whatever the vendor says it is. That tradeoff is the real decision in front of Q4 buyers, and it is a finance question as much as an architecture one. We build this pattern as our default on integration engagements, and the model-layer tradeoffs are covered in more depth on our model coverage page.

An evaluation checklist for this procurement cycle

Ten things to put in the RFP. Each one is a question I have seen go unasked and then become a six-figure surprise.

1. Ask for the actual catalog inventory for your industry — how many of the 6,000 apply to insurance claims specifically, and how many are agents versus assets?
2. Demand one end-to-end reference implementation, not a per-agent demo, with the data contracts visible.
3. Export a multi-agent workflow during the trial and attempt to re-import it somewhere else. Record what breaks.
4. Get the FDE qualification threshold as a number, with the engagement end date and exit criteria.
5. Price the run-rate separately from the build: who pays for schema drift, model deprecation and prompt regressions in year two?
6. Confirm whether consumption is metered per message, per credit, per token or per agent-hour, and model your worst-case month — Copilot Studio and Foundry pricing has changed more than once, so use the current rate card, not last year's.
7. Ask where your evaluation and audit data lives, and whether you can extract the full action log in an open format.
8. Establish which layers you can terminate independently. Can you keep Entra and Purview while replacing Copilot Studio?
9. Require named internal engineers on every integration artefact, with a knowledge-transfer gate before production.
10. Define the rollback plan for the agentic workflow itself. If you turn it off on a Monday, does the process still run?

When buying the fleet is actually the right call

There are three situations where I would tell a client to take the IBM Consulting delivery model without hesitation. If you are already deep in Microsoft 365, Azure and Fabric, the integration surface is largely pre-solved and the marginal lock-in is small because you are locked in already. If you have no internal AI engineering capability and no realistic plan to build one in four quarters, a managed fleet beats a half-built custom platform every time. And if your regulator wants a named accountable vendor with an auditable control framework, a joint IBM/Microsoft governance stack is an easier conversation than a homegrown one.

There are two situations where I would not. If the process you are automating is your differentiation — your underwriting judgment, your pricing logic, your clinical pathway — do not hand the coordination logic to a catalog, because you are outsourcing the thing competitors cannot copy. And if the process is still changing monthly, do not automate it yet at all. Agentic automation amortises over stable processes; an unstable process just produces expensive, well-governed churn. Gartner's estimate that over 40% of agentic projects will be canceled by end of 2027 on cost, unclear value or weak risk controls is mostly a description of teams automating processes that were not ready.

The week this landed also brought Snowflake's push on autonomous data engineering for the agentic enterprise, which reinforces the same underlying point from the data side: agents acting on stale or broken pipelines act on the wrong information, and no agent catalog fixes that. The pipeline is a seam too. If your data foundation is not trustworthy, buying 6,000 agents buys you 6,000 confident wrong answers.

Our read, plainly: Imagine Enterprise is a strong consulting-led offer with a genuinely good governance substrate, and the FDE clause is an honest signal about how much integration work remains. Buy the leaf tasks. Keep the graph. If you want a second opinion on where your particular estate's seams are, start here, or look at how we structure the parallel path in our build write-ups.