Security teams must evaluate and approve MCP server usage within developer IDEs before enterprise-wide adoption can proceed.

Governance rules need to be available directly in developers' coding assistants and AI agents, not just in standalone tools and pipelines.

Nico discovered that MCP servers built from existing API documentation fail because the docs were written for humans, not AI agents.

Nico sees MCP servers exposing every API option when agents only need task-specific subsets, wasting context and causing confusion.

Developer documentation sites must be rebuilt to enable AI agents to efficiently consume them, including markdown endpoints for full content access.

Context engineers need to consolidate many upstream APIs and MCP servers into a smaller set of efficient tools that agents can use effectively.

MCP-enabled documentation disproportionately benefits experienced developers because junior developers don't know what questions to ask.

Documentation efforts are treated as a publishing exercise rather than a product discipline that actively enables and teaches developers.

MCP-enabled documentation should accelerate implementation work inside IDEs and copilots, but 'ask anything' interfaces fail when users don't know the right prompts.

The repo context layer (README, CONTRIBUTING, AGENTS) has no clear owner as AI copilots roll out across IDEs.

Organizations can enforce coding standards and CI gates but cannot enforce equivalent governance for the Markdown files that shape AI agent behavior.

Repositories can look documented but still fail basic agent tasks because the docs were written for humans, not for agent execution.

Repositories need to explicitly declare what AI agents are allowed to change and what is off-limits.

Scaling IDE copilots across hundreds of repos requires a repeatable way to verify each repository is agent-ready.

Markdown docs must follow predictable, machine-reliable structures so agents can consistently locate authoritative answers.

Beyond MCP, protocols like A2A, ACP, AP2, and x402 are proliferating — enterprises need unified governance across all agent communication protocols, not just one.

API teams need to adopt context engineering as a discipline — curating the optimal set of instructions, knowledge, and feedback that enables agents to effectively discover, understand, and consume APIs.

Agentic browsers and AI workspaces will autonomously discover, evaluate, and transact via APIs — organizations need APIs that are not just discoverable but transactable by agents with proper governance guardrails.

Organizations need to simulate how AI agents will discover, consume, and interact with their APIs at scale before production — using synthetic agent personas and AI-powered simulation environments.

Agentic browsers and AI-native workspaces are becoming the primary interface for discovering and consuming services — APIs need to be optimized for Generative Engine Optimization (GEO), not just traditional developer portals.

Enterprises with mature OpenAPI portal pipelines need MCP-server documentation that flows through the same build process — not vendor-coupled extensions or a parallel doc system.

Enterprises need a way to expose legacy SOAP, XML, and other pre-REST backends as MCP server tools so agents can read and write to systems no team wants to evolve — without forcing a multi-year rewrite or rebuild of the underlying stack.

Integration platforms bridging X12 EDI to modern APIs need a payload-assist pattern that surfaces the full per-trading-partner specificity without collapsing it under a thin normalized schema — otherwise the JSON-shaped API loses the lineage and validation that made the EDI document useful in the first place.

Order and document flow no longer travels a single channel — traditional EDI, API-over-EDI, standard API, social-commerce (TikTok / WhatsApp stream-driven order flow), agentic commerce, and now MCP all need to converge into the same backend, but most integration platforms force a separate stack per channel.

Vertical integration platforms — EDI, healthcare, supply chain, payments — want to take their accumulated industry expertise and translate it into a signals → weighable options → skills → deterministic integration workflows layer, with AI optional rather than load-bearing. Most of those platforms do not have the framework skillset in-house to build it.

Engineers at closed-off enterprises shipping their first public API now have to ingest OpenAPI, Arazzo, JSON-LD, MCP, agent skills, async patterns, and agent-payment standards in weeks — with no sequenced onramp that says what to learn, when, and why.

Engineering leads see agent-era API strategy as urgent before leadership does. They need a playbook — language, evidence, and risk framing — to convince executives without sounding like AI hype, especially at responsibility-mindset enterprises that won't move fast just because the market is.

Need a way to control that an MCP server actually behaves like it is intended to behave at runtime, not just that it exists in a registry.

Business product managers need to design and stand up the APIs they need without having to develop a backend, because most enterprise APIs are data APIs and the design work is about assembling existing data.

Need a way to create a trusted consumer identity for agents so API providers can issue tokens to a known-and-vouched-for agent rather than treating every agent as either anonymous or a human-delegation proxy.

API onboarding flows — sign-up, account creation, scopes, token issuance — are wildly inconsistent across providers, and the translation/gateway layer does not fix the hard middle: the onboarding-flow layer itself.

API directories die when only humans can write to them; agents need to be first-class registrants so the directory's feedback loop stays alive at agent-web scale.

Even with identity and onboarding solved, API providers carry advertising-era baggage — own the user, distrust middlemen — that blocks them from issuing tokens to agents at all.

MCP servers exposing dynamic tool discovery still run ahead of client support, leaving a cross-ecosystem compatibility gap that blocks scaling tool catalogs past a handful of agents.

Internal enterprise software is shifting to a pattern where every service is an API, every API is exposed to agents via markdown / skills files, and users themselves activate or deactivate features — replacing generic SaaS with customer-specific agentic interfaces.

Developer platforms need a canonical pattern for what 'agent-ready' actually means — a spectrum from markdown and llms.txt at the simple end through full discover-sign-up-and-build-PoC agent journeys at the complex end.

Need tooling that lets a non-engineering operator define skills, create role-based agents, give each agent its skill, and wire them together as a working fleet — VP of Marketing agent, Social Media Manager agent, Paid Ads Manager agent — on a single reviewable dashboard.

Developer platforms need server-side telemetry on agent traffic — who's calling, what they're trying, whether they succeeded — because client-side signals like user-agent strings can be spoofed and tell you nothing useful.

Developer platforms need a canonical onboarding pattern where the first step is copying an MCP skill prompt — copy the .env key, copy the prompt, run — replacing multi-page sign-up flows for agent-era developers.