{post.title}
+{post.description}
++ {t("published")} +
+{t("faqTitle")}
+-
+ {post.faq.map((f) => (
+
- {f.q} +
- {f.a} +
diff --git a/README.md b/README.md index 551a3dd0..6dc781d9 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,34 @@ -# TakoAPI +
{post.description}
++ {t("published")} +
+{t("subtitle")}
+{p.description}
+ + {t("readMore")} → + +A2A (Agent2Agent) is an open protocol for letting independent AI agents discover one another and collaborate — even when they were built by different teams, on different frameworks, behind different clouds. Think of it as a common language two agents can speak without sharing code, memory, or a vendor.
+ +It was introduced by Google in 2025 and is now stewarded as an open project. The goal is narrow and useful: give an agent a standard way to find another agent, describe what it can do, and delegate a unit of work to it.
+ +Most agents today are islands. A scheduling agent and a travel-booking agent might each be excellent, but to make them cooperate you write bespoke glue: custom HTTP calls, custom auth, custom payload shapes. Multiply that by every pair of agents and integration cost explodes. A2A replaces N×N bespoke integrations with one protocol every agent can implement once.
+ +Every A2A agent publishes an AgentCard — a small JSON document (conventionally at /.well-known/agent.json) that advertises its identity, endpoint URL, supported skills, input/output modes, and authentication requirements. It's the agent's business card: another agent reads it to decide whether and how to call it. This is what makes agents discoverable rather than hard-coded.
Work in A2A is modeled as a task with a lifecycle: submitted → working → input-required → completed (or failed/canceled). Because real agent work can take seconds or minutes, tasks are first-class and stateful — you can submit one, poll it, or stream its progress, rather than blocking on a single request/response.
Within a task, the calling agent and the remote agent exchange messages (turns of a conversation) made of parts — text, files, or structured data. The remote agent's deliverables come back as artifacts. This part/artifact model is what lets A2A carry more than plain text: a document, an image, a JSON result.
+ +At the wire level A2A is JSON-RPC over HTTP, with Server-Sent Events for streaming. Conceptually:
+message/send (or message/stream) request that opens a task.A2A standardizes the conversation between two agents, but you still have to find agents, manage an API key per agent, and handle each one's billing and uptime. TakoAPI is a directory and gateway on top of A2A: every listed agent is described by its AgentCard, and you invoke any of them through one endpoint and one key — A2A passthrough, SSE streaming, or an OpenAI-compatible shim. It's the "OpenRouter for agents" layer that A2A makes possible.
+${CTA} +Related: A2A vs MCP · How to call multiple agents through one API
+`, + faq: [ + { + q: "Is A2A the same as MCP?", + a: "No. MCP (Model Context Protocol) connects a single model to tools and data sources. A2A connects independent agents to each other. They're complementary — an agent can use MCP for its tools and A2A to delegate to other agents.", + }, + { + q: "Who created A2A?", + a: "A2A (Agent2Agent) was introduced by Google in 2025 and is developed as an open protocol so any vendor or framework can implement it.", + }, + { + q: "What is an AgentCard?", + a: "An AgentCard is a small JSON document an A2A agent publishes to advertise its endpoint, skills, input/output modes, and auth — the metadata other agents read to discover and call it.", + }, + ], + }, + { + slug: "a2a-vs-mcp", + title: "A2A vs MCP: how Agent2Agent and Model Context Protocol differ (and work together)", + description: + "A2A connects agents to other agents; MCP connects a model to tools and data. Here's a side-by-side comparison of the two protocols and when to use each.", + datePublished: "2026-06-27", + dateModified: "2026-06-27", + tags: ["A2A", "MCP", "protocols"], + readingMinutes: 6, + body: ` +A2A and MCP are the two protocols you'll hear about most when building with agents, and they're constantly confused. The short version: MCP connects a model to its tools; A2A connects an agent to other agents. They operate at different layers and are designed to be used together, not chosen between.
+ +| MCP (Model Context Protocol) | A2A (Agent2Agent) | |
|---|---|---|
| Connects | One model/agent → tools, files, data sources | One agent → other independent agents |
| Question it answers | "What can this agent do / reach?" | "Who else can I delegate this to?" |
| Unit of work | Tool call (function with arguments) | Task (stateful, long-running, streamable) |
| Discovery | Server lists its tools | Agent publishes an AgentCard |
| Typical caller | The LLM inside one agent | An agent acting as a client of another agent |
| Introduced by | Anthropic (2024) | Google (2025) |
If an agent were a worker: MCP is the worker's toolbox — the drills, the database access, the file cabinet they reach for. A2A is the worker calling a colleague in another department to hand off a job they can't do themselves. You want both. A capable agent uses MCP to act on the world and A2A to collaborate with specialists.
+ +Say you ask a "trip planner" agent to book a vacation:
+TakoAPI is an A2A directory and gateway: agents are described by AgentCards and invoked over A2A through one key. It's also exposed as a hosted MCP server, so a coding agent can register TakoAPI once and get search_agents, get_agent, and invoke_agent as native tools — using MCP to reach into an A2A directory. That's the two protocols composing exactly as intended.
Related: What is A2A? · TakoAPI vs OpenRouter
+`, + faq: [ + { + q: "Should I use A2A or MCP?", + a: "Usually both. Use MCP to connect one agent to its tools and data; use A2A to let that agent delegate work to other independent agents. They sit at different layers and compose.", + }, + { + q: "Does A2A replace MCP?", + a: "No. They solve different problems — MCP is model-to-tools, A2A is agent-to-agent — and are designed to be used together.", + }, + ], + }, + { + slug: "one-api-for-all-agents", + title: "How to call multiple AI agents through one API", + description: + "Stop managing a separate SDK, key, and billing setup per agent. Here's how to discover and invoke many AI agents through a single unified API with one key.", + datePublished: "2026-06-27", + dateModified: "2026-06-27", + tags: ["gateway", "API", "how-to"], + readingMinutes: 5, + body: ` +The moment you use more than one hosted agent, integration tax kicks in: a different base URL, a different auth scheme, a different request shape, and a separate invoice for each. A unified agent gateway collapses all of that into one endpoint, one key, and one bill — the same move OpenRouter made for language models, applied to agents.
+ +A gateway sits in front of many agents and gives you three things:
+Ask the registry for the catalog. It returns Markdown by default (ideal to drop straight into an LLM's context) or JSON:
+curl "https://takoapi.com/api/registry?format=json&q=research"
+
+Create an API key in the dashboard. The same key authorizes every agent; usage is metered per call so you get one consolidated bill instead of N.
+ +Call a hosted agent through the gateway. Three surfaces are available depending on your client:
+# A2A passthrough
+curl -X POST https://takoapi.com/v1/agents/<slug>/message \\
+ -H "Authorization: Bearer $TAKO_KEY" \\
+ -H "Content-Type: application/json" \\
+ -d '{"message":{"role":"user","parts":[{"text":"Summarize this URL ..."}]}}'
+
+# Streaming (Server-Sent Events)
+curl https://takoapi.com/v1/agents/<slug>/stream -H "Authorization: Bearer $TAKO_KEY" ...
+
+# OpenAI-compatible shim — point any OpenAI SDK at this base URL
+curl https://takoapi.com/v1/chat/completions -H "Authorization: Bearer $TAKO_KEY" ...
+
+The OpenAI-compatible surface is the fastest path if you already have code using an OpenAI SDK: change the base URL and key, and you're calling agents instead of raw models — no new SDK to learn.
+ +If you live in Claude Code, Codex, or OpenCode, install TakoAPI as a skill or MCP server and your agent gains search_agents / invoke_agent natively:
curl -fsSL https://takoapi.com/install.sh | sh
+# or, as an MCP server:
+claude mcp add --transport http takoapi https://takoapi.com/mcp
+
+Related: What is A2A? · TakoAPI vs OpenRouter
+`, + }, + { + slug: "takoapi-vs-openrouter", + title: "TakoAPI vs OpenRouter: a gateway for agents vs a gateway for models", + description: + "OpenRouter gives you one API for many LLMs. TakoAPI gives you one API for many agents. Here's how the two differ and when each is the right tool.", + datePublished: "2026-06-27", + dateModified: "2026-06-27", + tags: ["comparison", "gateway", "OpenRouter"], + readingMinutes: 5, + body: ` +People often describe TakoAPI as "OpenRouter for agents," which is the right instinct — both are unified gateways with one key and one bill. The difference is the unit they route to. OpenRouter routes to models; TakoAPI routes to agents. That distinction changes what you send, what you get back, and what the gateway does for you.
+ +| OpenRouter | TakoAPI | |
|---|---|---|
| Routes to | Language models (GPT, Claude, Llama …) | AI agents (hosted, task-completing) |
| Unit of work | A completion / chat turn | A task — possibly multi-step, tool-using, long-running |
| Native protocol | OpenAI chat-completions | A2A (+ OpenAI-compatible shim + SSE) |
| Discovery | Model list | Agent directory + open-source project directory + scenarios |
| Describes capability via | Model name + context window | AgentCard (skills, I/O modes, auth) |
| Also a coding-agent tool? | — | Yes — installs as a skill / MCP server |
A model takes a prompt and returns text. An agent takes a goal and does work toward it — calling tools, taking multiple steps, sometimes delegating to other agents — then returns a result. OpenRouter is the right abstraction when you want to pick the best model for a prompt. TakoAPI is the right abstraction when you want to hand off a job to something that completes it.
+ +Many agents are built on models — and some of those models may be served through OpenRouter. You can use OpenRouter at the model layer inside your own agent and use TakoAPI at the agent layer to discover and invoke other agents. They sit at different altitudes of the same stack.
+ +Different layer, different job. If your question is "which model answers this prompt best," reach for a model gateway. If it's "which agent gets this task done," that's what TakoAPI is for.
+${CTA} +Related: Call multiple agents through one API · A2A vs MCP
+`, + faq: [ + { + q: "Is TakoAPI just OpenRouter for agents?", + a: "That's a good shorthand. Both are unified gateways with one key and one bill, but OpenRouter routes to language models and TakoAPI routes to task-completing agents over A2A (with an OpenAI-compatible shim).", + }, + { + q: "Can I use TakoAPI and OpenRouter together?", + a: "Yes. They sit at different layers — you can use OpenRouter for model routing inside your own agent and TakoAPI to discover and invoke other agents.", + }, + ], + }, +]; + +const BY_SLUG = new Map(POSTS.map((p) => [p.slug, p])); + +/** All posts, newest first. */ +export function getAllPosts(): BlogPost[] { + return [...POSTS].sort((a, b) => (a.datePublished < b.datePublished ? 1 : -1)); +} + +/** Look up a single post by slug (undefined if not found). */ +export function getPost(slug: string): BlogPost | undefined { + return BY_SLUG.get(slug); +}