Open Standards
The Dandelion runs on two open standards — A2A and MCP. Which means your AI OS can plug into any agent, any tool, and any LLM in the ecosystem. Today, and five years from now.
The problem
You adopt a vendor. Their agents talk to their agents. Their tool integrations use their proprietary schemas. Their LLM is the LLM. Two years later, you're locked in — and the ecosystem has moved on without you.
The two protocols
Everything in The Dandelion runs on these two open specs. Understanding them is the fastest way to understand why the platform is built to last.
How agents communicate with each other
A2A lets one agent delegate to another by calling its skills — not by reaching into its tools. The parent sees clean, named capabilities. The child handles its own implementation. It's the protocol difference between "use this API" and "ask this teammate."
How agents connect to data and tools
MCP is the USB-C of AI — a single open spec for exposing tools, resources, and prompts to any MCP-aware agent. Build or adopt one MCP server and every agent in your greenhouse (and every agent anywhere) can use it.
A2A Deep dive
The cleanest way to understand A2A is to watch a parent agent delegate. The parent sees skills. Each child handles its own tools. Encapsulation, applied to AI.
An agent's public surface is a list of named skills like `qualify_lead` or `draft_proposal` — each with an input schema, an output schema, and a description. Internal implementation details stay internal.
When the Ops Agent needs a candidate screened, it calls the Recruiting Agent's `screen_candidate` skill. It doesn't know, or care, which tools the Recruiting Agent uses to do it. Classic encapsulation applied to AI teams.
Long-running work streams progress back to the parent via SSE. Pause points (human approval, MFA, clarification) are first-class states in the protocol — not bolted-on webhooks.
Any A2A-compliant agent — ours, yours, or a third-party's — can be registered in your greenhouse and called by name. Build a Python agent, drop in a Claude-flavored one, adopt a vendor's A2A agent tomorrow. All the same protocol.
MCP Deep dive
MCP standardizes how agents reach external systems. Three primitives — tools, resources, and prompts — cover the surface area of any integration.
A Gmail MCP server exposes `send_email` and `search_threads`. A Salesforce server exposes `create_lead` and `update_opportunity`. Standardized schemas mean any MCP-aware agent can use them without custom wiring.
MCP servers can expose structured resources — a customer record, a PDF, a dashboard — that agents pull into their context on demand. No wholesale document dumps. Just the right slice, at the right moment.
Servers can ship with pre-built prompt templates for common workflows. Your NetSuite MCP server can include a `close_month_end` prompt that knows every account, every reconciliation step, every approval.
Every new MCP server shipped by the community — and there are already hundreds — is automatically usable by your agents. You inherit interoperability for free, in perpetuity.
The architecture
Every layer of the platform maps cleanly onto an open standard. Nothing is proprietary where it doesn't need to be.
What this means for you
Change models per-agent or globally. Your business logic lives in skills, not model prompts.
Every new server in the ecosystem is already compatible. You inherit integrations for free.
Bring a vendor's agent or a bespoke one. If it speaks A2A, your greenhouse can call it.
If you ever leave The Dandelion, your agents, skills, and MCP servers still work. That's the point.
Function calling hands a raw tool surface to an LLM — the LLM picks which tool to use and how. A2A adds a layer of abstraction: one agent calls another agent's skill, and the callee decides internally which tools to invoke. It enables encapsulation, independent scaling, and language/runtime independence between agents. An A2A child agent can be a TypeScript Claude agent, a Python GPT-4 agent, or a workflow — the caller doesn't need to know.
Often no. The MCP ecosystem already has servers for most common business tools (Gmail, Slack, GitHub, Postgres, Stripe, and so on). For bespoke internal tools, we write a thin MCP server during the partnership — usually a day or two of work, and then every agent you ever build can use that tool. We view MCP servers as reusable infrastructure, not throwaway adapters.
Yes. If the agent is A2A-compliant, it registers via its agent card and becomes callable by skill name from any other agent in your greenhouse. If it isn't A2A-compliant yet, we can wrap it — most LLM agents can be made A2A-compliant in a few hundred lines.
Both protocols are versioned. Minor versions are backward-compatible. Major versions are rare and well-signaled by the standards groups (A2A is stewarded with Linux Foundation involvement; MCP is stewarded by Anthropic with an open specification). Compared to being locked into a proprietary vendor's internal API, you'll migrate far less often.
No. Because agent logic lives behind A2A skills and tool access lives behind MCP, the LLM is effectively a swappable dependency. We pick the best model for each agent — reasoning-heavy agents might run Claude Opus, cheap classification agents might run a small open-weight model — and you can change that choice at any time.
It doesn't add complexity for you — it adds durability. You experience the partnership and the platform; the standards are how we guarantee the work we do for you will keep working five years from now, as the AI ecosystem changes underneath.
Book a technical call. We'll walk through how A2A and MCP would map onto your actual stack — what to adopt, what to wrap, and what to leave alone.
