IBM's watsonx Orchestrate announcements at TechXchange 2026 are substantive. They also stop at the vendor boundary. We map what an agent control plane actually enforces, and what your own orchestrator still has to emit.
Last Updated: October 28, 2026
IBM's TechXchange 2026 announcements give watsonx Orchestrate a genuine agent control plane: registry, policy enforcement, evaluation, identity binding and a kill switch. But discovery reaches into Amazon Bedrock, Microsoft Foundry and Google Gemini — not into your self-hosted n8n instance, your LangGraph service on ECS, or the MCP server a team stood up last quarter. Four control-plane primitives matter (registry, tool-call policy, audit trail, kill switch) and each one terminates at the vendor's runtime boundary. If more than a third of your agentic work runs outside that boundary, you need a thin, vendor-neutral layer in front of your own orchestrator that emits the same four signals. That is cheaper and more durable than migrating every workflow into one runtime.
The procurement question that TechXchange turned live is not "is IBM's control plane good". It is "what percentage of my agent estate does any single control plane actually see". Those are different questions, and the second one is the one that determines whether you still have to build.
What IBM actually shipped on 27 October
The substance is in the availability footnotes, not the feature list. IBM's press release states that HashiCorp Vault 2.2, Agent Identity, the watsonx Orchestrate evaluate capabilities, IBM Concert and Terraform policy are generally available, while Secure Hub and the Terraform remote MCP server are in public preview — and critically, the Orchestrate discover and contain capabilities are in tech preview. Discover and contain are the two features that carry the multi-vendor story. They are also the two least finished.
What discover does is specific: Orchestrate connects to Amazon Bedrock, Microsoft Foundry and Google Gemini to find agents built in those environments, extending to models and MCP servers too. Contain adds isolated sandboxes so a misbehaving agent can't interfere with others, plus a kill switch to shut any agent down.
Alongside it, IBM introduced the watsonx Orchestrate AI Gateway as a single enforcement layer for third-party agents, models and MCP servers, and turned the Orchestrate catalog into a governed catalog aligned to OWASP, CoSAI and the IBM AI Risk Atlas — surfacing MCP protocol conformance, tool schema integrity, tool description safety, input validation and default-credential rejection for selected servers. The Premium Runtime adds hardware-virtualized container isolation for agents that execute dynamic tool code against community MCP servers. That last one is an honest piece of engineering: shared-kernel execution of model-authored code is a real risk and most platforms are still pretending otherwise.
None of this is vapour. It is the most coherent agent management story any of the large vendors have assembled. The question is scope.
IBM positions the next generation of watsonx Orchestrate as an agentic control plane at Think, in private preview.
The Agentic Control Plane ships on AWS and IBM Cloud with runtime policy management, credential health monitoring, an Agent Access overview and content guardrails.
n8n 2.44 ships node type policies — instance- and project-level allow/deny/delegate rules on which nodes can be added, published and run.
TechXchange: AI Gateway, governed catalog, Premium Runtime, Agent Identity with Vault, discover and contain in tech preview.
The four primitives, and where each one stops
Strip the marketing and an agent control plane is four things. Every vendor builds the same four. Each one has a different failure boundary in a mixed estate, and conflating them is how buyers end up with a dashboard that is confidently wrong.
Registry. A list of every agent, its owner, its lifecycle status and its granted authority. IBM's Agent Identity establishes exactly this record when paired with Vault. A registry is only as complete as its discovery connectors, and discovery connectors are written against platform APIs. There is no API on a self-hosted n8n container that announces "here are my seventeen agentic workflows" to a third-party registry unless you write the push yourself.
Policy enforcement at tool-call time. This is the only primitive that actually prevents anything. It requires the policy decision point to sit inline on the call path — between the model's tool selection and the tool's execution. Everything else is reporting. The AI Gateway is IBM's inline point; it enforces on traffic that transits the gateway. Traffic that doesn't transit it isn't enforced, by definition.
Audit trail. Immutable, queryable record of what each agent did, with which credential, on whose behalf. The hard part is not storage, it is correlation across process boundaries: a trace that starts in a Teams message, runs through an orchestrator, fans out to three MCP servers and writes to a CRM.
Kill switch. Revocation of an agent's ability to act. There are two kinds and they are not equivalent: stopping the runtime that hosts the agent, and revoking the credentials the agent uses. Vendor planes usually give you the first for their own runtime and the second via the secrets broker. The second is the one that works across the boundary — which is why the Vault integration matters more than the sandbox.
| Primitive | What a vendor plane gives you | Where it terminates | What you still own |
|---|---|---|---|
| Registry | Inventory with owner, lifecycle, granted authority; discovery connectors into Bedrock, Foundry, Gemini | Platforms with a supported connector. Self-hosted runtimes and bespoke services are invisible | A push-registration step from every non-covered runtime, run in CI |
| Tool-call policy | Inline enforcement on calls routed through the vendor gateway; content guardrails and usage restrictions | The gateway's traffic path. Direct SDK calls and local MCP stdio servers bypass it | Egress control, so direct calls are not possible in the first place |
| Audit trail | Execution traces, tool interactions, token and cost attribution per agent | Spans the vendor's instrumentation emits. External hops appear as opaque outbound calls | W3C trace context propagation across every hop you control |
| Kill switch | Runtime shutdown plus real-time credential revocation when an agent exceeds its permissions | Runtime shutdown is vendor-local. Credential revocation travels, if the credential is brokered | Broker every agent credential. A hardcoded API key cannot be revoked by anyone's control plane |
Read the right-hand column again. Three of the four remediations are things you build in your own infrastructure, and none of them get cheaper by buying a second control plane.
Why the mixed estate is the default, not the exception
Gartner's own guidance makes the point that a centralized agent inventory has to span sanctioned tools and shadow AI, and its analysts are blunt that blocking unsanctioned tools pushes people further out of view rather than bringing them in. Max Goss, Senior Director Analyst at Gartner, warns that restricted employees "will likely go around the organization's controls". If your answer to a mixed estate is "we will standardize on one runtime", you are planning for a world that the inventory step is explicitly telling you does not exist.
And the gap is not only about shadow IT. The highest-value automations in most companies are glue: an n8n workflow that watches a queue, calls a model, hits three internal APIs and writes to a system of record. That workflow is an agent in every sense that matters to a risk committee, and it is not registered in anyone's agent platform.
Treating the vendor registry as the system of record
A discovery connector produces a confident, well-designed inventory. Teams then reason from it: "we have 41 agents, 38 are policy-compliant". The number is true about the agents the connector can see. It says nothing about the orchestrator workflows, cron-triggered scripts and local MCP servers that never appear. The dashboard's completeness is assumed, never tested, and the first incident is always with an agent that was not on the list.
Making your own orchestrator emit control-plane-grade telemetry
The good news is that the external layer is smaller than it looks, because the orchestrators have quietly grown the hooks. n8n is the clearest example because its governance surface is now specific enough to map onto all four primitives.
For policy, n8n 2.44 shipped node type policies: an ordered list of allow, deny and delegate rules per node type or package, evaluated at the instance level first — where a deny is final and no project can override it — then at the project level, which can only restrict further. The enforcement points are the ones that matter: n8n checks policies when workflows are saved, published and run, and when agents use tools, as well as on CLI imports, source control pulls and credential tests. Every block emits an audit event to your log streaming destinations. That is tool-call-time policy enforcement with an audit trail, in an orchestrator, managed over an API.
# Read the current instance policy, edit, then PUT it back with the version you read.
# API key needs the nodeTypePolicy:manage scope. Changes apply in about one second.
curl -s -H "X-N8N-API-KEY: $N8N_API_KEY" \
https://n8n.internal/api/v1/node-type-policies/instance > policy.json
# ...edit policy.json: deny the HTTP Request node outside approved projects,
# delegate the community MCP client node so project admins must opt in...
curl -s -X PUT -H "X-N8N-API-KEY: $N8N_API_KEY" \
-H 'Content-Type: application/json' \
--data @policy.json \
https://n8n.internal/api/v1/node-type-policies/instanceFor telemetry, n8n 2.27 moved OpenTelemetry configuration into the UI, which brought execution tracing to n8n Cloud for the first time. Each execution exports a workflow.execute span with workflow ID, name, version, node count, execution mode, status and error type, with a nested node.execute span per node. More importantly, it propagates W3C trace context in both directions: a traceparent header on an inbound webhook becomes the parent of the workflow span, and HTTP Request nodes inject one into outbound calls.
Here is the part the docs do not tell you. Those are not GenAI semantic convention spans. The OpenTelemetry GenAI conventions define invoke_agent, execute_tool, invoke_workflow and plan operations, and every one of those span definitions is still marked Development. So you are mapping an unstable target from a non-conforming source. Do the mapping in the collector, not in the orchestrator, so that when the conventions churn you change one processor config instead of redeploying every workflow. Budget for that churn — it is the single most underestimated maintenance line in agent observability work, and it is the reason we keep a current view of model and protocol behaviour rather than baking assumptions into pipelines.
A vendor-neutral control layer in front of your own orchestrator
CI publishes an agent manifest — owner, purpose, tools, data classes, escalation contact — to your registry and to the vendor plane's API. No manifest, no deploy.
No long-lived keys in the orchestrator's credential store. Short-lived, scoped secrets issued per agent identity, so revocation is one call and works regardless of which runtime the agent lives in.
Model calls and MCP calls leave through a gateway you control. Network policy denies everything else. This is what makes policy enforcement real rather than advisory.
Map workflow.execute and node.execute onto gen_ai.* attributes, stamp the registry ID as a resource attribute, and ship to the same backend as your vendor-runtime traces.
Disable at the orchestrator, revoke at the broker, block at the egress. Rehearse it quarterly with a real agent. An untested kill switch is a diagram.
Two details from the vendor side make step 4 easier than it was six months ago. AWS now writes AgentCore traces, prompts and logs to a single per-agent CloudWatch log group, default for agents created from 20 July 2026, with existing agents needing UNIFIED_TRACES_DESTINATION_ENABLED=true and ADOT 0.17.1 or later. Per-agent log groups mean per-agent IAM scoping and a single subscription to export everything. That is the shape you want from every runtime: one stream per agent identity, exportable.
The second is protocol drift. The 2026-07-28 MCP revision removed protocol-level sessions and the Mcp-Session-Id header, making MCP stateless: every request now carries its protocol version and client capabilities in _meta, and clients should identify themselves on each request. If your audit correlation was keyed on an MCP session identifier, that key no longer exists. Correlate on your own trace ID and registry ID instead, propagated as headers you control.
The honest buy case
Standardizing on one vendor runtime is the right call more often than vendor-neutrality purists admit. Three conditions make it genuinely cheaper.
First, if your agent estate is already concentrated — say 80% of agentic work already runs in one ecosystem and the rest is low-risk — the integration tax of a neutral layer exceeds the lock-in cost. Second, if your binding constraint is regulatory evidence rather than engineering flexibility, a plane that ships a governed catalog aligned to OWASP, CoSAI and the IBM AI Risk Atlas with EU AI Act compliance signals surfaced at discovery time is doing months of work you would otherwise do by hand. Third, if you are executing model-authored code against community MCP servers, hardware-virtualized isolation is not something to build.
The neutral layer wins when the estate is genuinely plural, when the agents doing revenue-bearing work live in an orchestrator rather than a vendor platform, or when the plane you are evaluating still has its multi-vendor features in tech preview — which, for discovery and containment, is where they are today. There is also a hybrid that is better than both and that almost nobody evaluates: let the vendor plane own identity while your orchestrator owns execution. n8n already ships this. Its Microsoft Agent 365 Trigger node gives an n8n-built agent an Entra ID identity with its own mailbox inside a Microsoft tenant, with Microsoft handling identity, lifecycle, security and compliance through Entra, Purview and Defender, and n8n handling workflow-level governance — RBAC, credential management and execution logs. That is the boundary drawn in the right place.
A related control that gets overlooked: n8n 2.46, released the same day as TechXchange, made every workflow run act as a person, able to use only the credentials that person is allowed to use, hiding execution data produced with credentials you cannot use. Combined with execution data redaction, where every reveal is logged as an audit event, that is least-privilege applied to the orchestrator itself. Most teams never turn it on. We treat it as table stakes in any agent integration engagement, and it is usually the first gap we find in an existing estate.
What I would do in the next 90 days
Do not start with a platform decision. Start with a reconciliation job, because it is the only thing that converts an opinion about coverage into a number. Pull three lists: agents known to your vendor plane, identities holding brokered credentials, and source IPs calling model or MCP endpoints through your egress. Join them. The unmatched rows are your actual governance problem, and their size decides the build-versus-buy answer for you.
Then sequence: egress control before policy engine, because policy you can bypass is theatre. Credential brokering before kill switch, because revocation needs something to revoke. Trace propagation before dashboards, because a dashboard over disconnected spans is worse than no dashboard — it looks complete. Registration as a deploy gate before any discovery tooling, because discovery finds what it was written to find.
And be willing to say "not yet". If an agent's failure mode is an irreversible external action — money moved, contract sent, record deleted in a system with no soft delete — and you cannot yet produce a per-action audit trail tying it to an owner, do not automate it. Keep the human approval step, with the respondedAt timestamp and approver identity that n8n now records on every Send-and-Wait node, and revisit when the telemetry is real. That is not caution for its own sake; it is the difference between an incident you can explain and one you cannot. If you want a second pair of eyes on where your boundary actually sits, start there, and the patterns in our build write-ups show how the pieces fit together in practice.
Frequently Asked Questions
Does IBM's watsonx Orchestrate control plane govern agents built outside IBM?
Partially, and through named connectors. IBM's discover capability connects to Amazon Bedrock, Microsoft Foundry and Google Gemini to find agents, models and MCP servers built there, and the AI Gateway acts as an enforcement layer for assets routed through it. Both discover and contain are in tech preview as of 27 October 2026. Agents running in a self-hosted orchestrator or a custom service are not discovered automatically — you register and instrument those yourself.
What governance controls does n8n actually have for agents?
More than most people assume. Enterprise node type policies let admins allow, deny or delegate node types at instance and project level, evaluated when workflows are saved, published and run, and when agents use tools — with each block emitting an audit event to log streaming destinations. Add OpenTelemetry tracing with W3C context propagation, execution data redaction with logged reveals, and per-person credential scoping on every run. Those map to policy, audit and least privilege.
Do I need a vendor control plane if I already have OpenTelemetry?
Tracing is one of four primitives, and it is the observational one. It will not stop an overprivileged agent from calling a tool it should not. You still need an inline policy decision point on the call path, brokered short-lived credentials so revocation works, and a registry that is authoritative at deploy time. Buy the control plane for enforcement and identity; keep OpenTelemetry as the neutral substrate underneath both estates.
Are the OpenTelemetry GenAI agent conventions safe to build on?
Build on them, but isolate the mapping. The agent span definitions in the GenAI semantic conventions — create agent, invoke agent, invoke workflow, plan, execute tool — are all marked Development, not stable, which means attribute names and semantics can still change. Do the translation from your orchestrator's native spans in an OpenTelemetry collector processor so a convention change is a config edit rather than a redeployment across every workflow and service.
What is the cheapest way to get a complete agent inventory?
Reconciliation, not discovery. Join three lists you already have: agents in your vendor registry, identities holding brokered credentials, and source identities calling model or MCP endpoints through your egress gateway. Rows that appear in the second or third list but not the first are unregistered agents. Run it nightly. It costs a day of work, it produces a defensible completeness number, and it keeps working as runtimes change.
Did the MCP spec change break agent audit trails?
It broke one common shortcut. The 2026-07-28 revision removed protocol-level sessions and the Mcp-Session-Id header, making MCP stateless, with protocol version and client capabilities carried per request in _meta. Any correlation logic keyed on an MCP session ID needs rewriting. Correlate on your own trace ID and registry ID propagated as headers instead — those survive protocol revisions, which is the general lesson here.
When should I just standardize on one vendor runtime?
When roughly four-fifths of your agentic work already lives in one ecosystem and the remainder is low-risk; when your binding constraint is regulatory evidence rather than engineering flexibility; or when you are executing model-authored code against community MCP servers and need hardware-level isolation you would not build yourself. Outside those conditions, a thin neutral layer in front of your own orchestrator is usually cheaper and ages better.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime
