AI Agents 101 | 14. Standards and Ecosystem
Standards and Ecosystem
Agent systems are becoming too broad for every product to invent its own private integration model.
Models need tools. Tools need permissions. Agents need to talk to other agents. Runs need traces. Organizations need governance. Users need portable expectations. Standards do not make systems safe by themselves, but they give the ecosystem shared boundaries.
The agent ecosystem is forming around protocols, packaged capabilities, observability, safety frameworks, and product-specific runtimes.
Level 1: Fundamentals
MCP is the clearest current standard for agent-to-tool integration. The 2025-06-18 MCP specification describes it as an open protocol for connecting LLM applications with external data and tools, using JSON-RPC 2.0 and host/client/server roles [1].
A2A is aimed at agent-to-agent communication. The A2A docs describe it as an open protocol for communication and collaboration between opaque agentic applications, and position it as complementary to MCP: MCP for agent-to-tool, A2A for agent-to-agent [2].
OpenTelemetry provides the broader observability vocabulary: traces, metrics, logs, APIs, collectors, semantic conventions, and vendor-neutral telemetry [5].
OWASP and NIST provide safety and governance anchors. OWASP catalogs LLM application risks such as prompt injection, insecure plugin design, excessive agency, and sensitive information disclosure [6]. NIST's AI RMF frames trustworthy AI across design, development, use, and evaluation [7].
The Hitchhiker guide treats these layers as part of a larger systems stack: RAG, memory, harnesses, MCP, A2A, multi-agent systems, frameworks, evaluation, and UI [8].
Level 2: Concepts
Different standards solve different problems.
| Boundary | Standard or Pattern | Main Question |
|---|---|---|
| agent to tool/data | MCP | how does an agent discover and call external capabilities? |
| agent to agent | A2A | how do agentic systems delegate, collaborate, and exchange task state? |
| runtime telemetry | OpenTelemetry-style tracing | how do we observe runs across services? |
| safety risk | OWASP LLM Top 10 | what failure classes should we defend against? |
| governance | NIST AI RMF | how should organizations manage AI risk over the lifecycle? |
| task knowledge | skills/instruction packages | how does an agent learn a reusable workflow? |
| product runtime | Agents SDKs/frameworks | how does a product execute loops, tools, state, and approvals? |
Standards are boundary agreements. They are not full architectures.
MCP
MCP standardizes how hosts connect to external capabilities. Its value is reducing bespoke integrations:
without protocol: each host integrates with each system
with protocol: hosts implement MCP clients; systems expose MCP servers
That does not remove the need for authorization, sandboxing, or trust. It makes the connection surface reusable.
A2A
A2A is for cases where the other participant is itself an agentic application, not merely a tool. It supports the idea that agents may discover one another, negotiate work, exchange status, and coordinate complex workflows [2].
The design question is whether the remote participant should be treated as:
- a tool call with a bounded response
- a handoff target
- a collaborator with its own task lifecycle
- an opaque external service requiring governance
Observability
OpenTelemetry is not agent-specific, but agent systems benefit from its vocabulary because they cross many services: model APIs, tool servers, queues, retrievers, approval services, and UI event streams [5].
Agent traces should connect:
- model call spans
- retrieval spans
- MCP tool spans
- A2A task spans
- guardrail decisions
- user approvals
- final artifacts
The goal is one coherent run trace, not scattered logs.
Safety Frameworks
OWASP gives a practical threat list for LLM applications [6]. NIST gives a governance lifecycle [7]. Use both. One is closer to engineering controls; the other is closer to organizational risk management.
Level 3: Engineering Detail
A standards-aware architecture should keep protocol boundaries explicit.
Capability Registry
{
"capability_id": "mcp.company.search_docs",
"type": "mcp_server",
"owner": "platform-search",
"version": "2026.07.1",
"transport": "streamable_http",
"tools": ["search_docs", "get_document"],
"data_classification": "internal",
"auth": "user_delegated",
"risk_tier": 1,
"approved_agents": ["support_agent", "research_agent"]
}
The registry answers: what is installed, who owns it, what can it do, what data can it access, and which agents may use it?
Protocol Choice
Need a model to read or act through an external system?
-> MCP or native tool integration
Need one agentic application to delegate to another?
-> A2A-style task boundary
Need reusable procedural knowledge?
-> skill or instruction package
Need runtime visibility?
-> trace spans, metrics, logs, run records
Need organizational controls?
-> governance policy, risk tiers, approvals, eval gates
Choosing the wrong boundary causes problems. If an external agent is treated like a simple tool, the caller may hide uncertainty or lose task state. If a simple data lookup is treated like a full agent collaboration, the system becomes overcomplicated.
Ecosystem Risk Register
| Risk | Ecosystem Cause | Control |
|---|---|---|
| tool sprawl | many MCP servers expose overlapping tools | capability registry and review |
| unclear ownership | no owner for plugin/server behavior | owner metadata and versioning |
| protocol trust confusion | standard connection mistaken for safe connection | permissions, sandboxing, audit |
| telemetry gaps | agent runs cross services without trace continuity | trace propagation |
| stale standard assumptions | protocol evolves after integration | version pinning and upgrade tests |
| vendor lock-in | runtime features tied to one product | abstract only where it buys portability |
Standards reduce integration friction. Governance keeps that friction reduction from becoming risk amplification.
Current Landscape
The ecosystem is not fully settled, but the shape is visible.
MCP has become a major agent-to-tool protocol boundary [1]. A2A is positioning itself as the complementary agent-to-agent protocol [2]. OpenAI's tools and integration docs show platform support for built-in tools, remote MCP, tool search, hosted capabilities, and tracing [3][4].
Observability is borrowing from the broader software ecosystem through OpenTelemetry [5]. Safety and governance are borrowing from security and risk frameworks through OWASP and NIST [6][7].
Skills, plugins, SDKs, and frameworks fill in the local productivity layer. They are less universal than protocols, but they matter because they package the workflows and conventions that make agents useful in real work.
The Hitchhiker guide is helpful as a systems map, but current implementation choices should still be checked against official protocol and product docs [8].
Practical Takeaways
Use MCP for agent-to-tool integration when interoperability matters.
Use A2A-style boundaries when the other party is an agentic application with its own state and task lifecycle.
Instrument runs with trace continuity across model calls, tools, retrieval, approvals, and UI events.
Treat standards as connection contracts, not safety guarantees. Authorization, sandboxing, evals, and audit still belong to your system.
Maintain a capability registry. Know which tools, servers, plugins, and skills are installed, who owns them, and what risk tier they carry.
Follow both engineering and governance frameworks. OWASP helps enumerate failure classes; NIST helps manage lifecycle risk.
References
[1] "Model Context Protocol specification, 2025-06-18." Model Context Protocol. https://modelcontextprotocol.io/specification/2025-06-18. Published/updated: 2025-06-18. Accessed: 2026-07-06. Used for: MCP purpose, JSON-RPC 2.0, host/client/server roles, tools, resources, prompts, roots, sampling, and elicitation.
[2] "Agent2Agent Protocol." A2A Protocol documentation. https://a2a-protocol.org/latest/. Published/updated: 2026. Accessed: 2026-07-06. Used for: agent-to-agent interoperability, opaque agentic applications, complex workflows, secure collaboration, extensibility, and MCP complementarity.
[3] "Using tools." OpenAI API documentation. https://developers.openai.com/api/docs/guides/tools. Published/updated: not listed. Accessed: 2026-07-06. Used for: built-in tools, function calling, remote MCP, file search, web search, and tool search.
[4] "Integrations and observability." OpenAI API documentation. https://developers.openai.com/api/docs/guides/agents/integrations-observability. Published/updated: not listed. Accessed: 2026-07-06. Used for: MCP-backed capabilities, SDK-managed MCP, hosted tools, and tracing.
[5] "What is OpenTelemetry?" OpenTelemetry documentation. https://opentelemetry.io/docs/what-is-opentelemetry/. Published/updated: not listed. Accessed: 2026-07-06. Used for: observability framework, traces, metrics, logs, vendor-neutral telemetry, collectors, APIs, and semantic conventions.
[6] "OWASP Top 10 for Large Language Model Applications." OWASP GenAI Security Project. https://owasp.org/www-project-top-10-for-large-language-model-applications/. Published/updated: 2025. Accessed: 2026-07-06. Used for: LLM application risks including prompt injection, insecure plugin design, sensitive disclosure, excessive agency, overreliance, and supply-chain risk.
[7] "AI Risk Management Framework." National Institute of Standards and Technology. https://www.nist.gov/itl/ai-risk-management-framework. Published/updated: 2026-04-07. Accessed: 2026-07-06. Used for: trustworthy AI lifecycle governance across design, development, use, and evaluation.
[8] "The Hitchhiker's Guide to Agentic AI: From Foundations to Systems." Haggai Roitman. Local source: agent-101/The Hitchhiker’s Guide to Agentic AI/book.tex. Published/updated: 2026. Accessed: 2026-07-06. Used for: ecosystem map across RAG, memory, harnesses, MCP, A2A, multi-agent systems, frameworks, evaluation, and agentic UI.
Enjoy Reading This Article?
Here are some more articles you might like to read next: