Agent, Skill, and (Intent) Routing

[ognis1205]

Challenges in Scaling Natural Language Interfaces in A2A

When building A2A-compatible agents that accept natural language input and route it to the appropriate AgentSkill, we inevitably face challenges as the number of skills grows.

While A2A encourages flexible interaction via prompts, scaling the number of skills brings forth several concrete issues around routing accuracy, ambiguity, and performance:

Specific Challenges Emerging with a Growing Number of Skills

1. Increased Ambiguity

   • For example, when a user says "Make a reservation," is it for a room, a restaurant, or a flight?
   • Even the same phrase may have different meanings across skills.

2. Overlapping Skills

   • Skills like "Summarize document" and "Analyze document" may both seem plausible given the same user intent, making disambiguation difficult.

3. Routing Accuracy Degradation

   • If skill definitions or expectations are vague, the agent might select the wrong one.
   • Longer or more context-dependent user inputs exacerbate this issue.

---

Key Discussion Topics

1. Scoping intent recognition and skill selection to a specific Agent—rather than evaluating all skills globally—not only significantly reduces ambiguity and improves precision. This approach also suggests a broader architectural shift: while the A2A model currently (implicitly) assumes "one host, one agent," many real-world scenarios could benefit from supporting multiple agents under a single host. Each agent could expose its own scoped skill sets and interfaces. This modular partitioning helps manage large capabilities and mitigates scaling issues—especially when combined with catalog-based discovery mechanisms.

2. Another important topic is how to handle cases when no matching skill can be found. This raises the question of whether the A2A specification itself should define standardized error codes or response formats for such fallback scenarios.

---

Extending Routing with Programmable Logic

Some frameworks, such as LangChain Routing, support hybrid routing approaches that combine natural language intent recognition with programmable, declarative routing logic. This allows more structured and reliable delegation across tools or agents beyond purely free-form input interpretation.

A key question for the A2A ecosystem is whether similar programmable routing capabilities can and should be defined at the protocol or usage level. Could the A2A specification be extended to support declarative routing policies, modular routers, or programmable dispatch? What benefits and challenges would such extensions entail for interoperability and flexibility?

Additionally, since routing between Agents and AgentSkills may involve guardrails or constraints to ensure correct dispatch, should the protocol also define corresponding error types or codes to handle routing failures explicitly? Defining such error semantics could improve robustness and clarity in routing behaviors within the A2A ecosystem.

[ognis1205]

I received some very insightful feedback from a core community member, which clarified the nuanced nature of agent skill invocation and discovery.

Skills Are Not APIs

They pointed out that agent delegation based on intent depends not only on the agent’s own prompting/model but also on how clearly the remote agent describes its behavior. Importantly, skills are not APIs — they should not be treated as contract-based endpoints. Instead, they are descriptions of what the agent can do, often loosely defined. This is why skills shouldn’t be directly requested or interpreted like API errors.

Clarification via TaskState

Interestingly, the protocol already includes a mechanism enabling them to ask for clarification instead of proceeding with uncertain execution. They noted that this feature is underutilized but potentially powerful for enabling more dynamic and exploratory interactions:

• Life of a Task
• TaskState

Scalability and Trust

They also acknowledged the challenges of scalability and quality in agent selection, noting that these will likely be addressed through context management strategies on the client side.

[lukehinds]

Unsure if its spec aligned but in AgentUp I map skills to Tools. Tools are registered as available for function calling by the model and in turn advertised as available within the Agent Card.

So an agent might have a tool get_location which is part of an API that calls Google maps with long/lat and replies with correct up to date map data. That is a skill that the particular agent has. It could also in a way be an inherent ability of most models, but without the tool it could be stale or hallucinated, so its a differentiating skill.

I can't really think of any skills an agent might have beyond Tools / MCP etc (or just plain ole APIs), perhaps the model itself? An agent might be multi-modal as it has a model capable of both text and image processing?

[lukehinds]

[ognis1205]

Hi @lukehinds ,

Thanks for sharing your approach — I actually agree with much of your understanding and design philosophy when thinking about what an AgentSkill represents at the implementation level. In fact, this whole thread started from a very similar modeling approach on my end.

That said, I do think there are cases where modeling AgentSkills strictly as Function Calling endpoints or MCP Tools may fall short. For example, in RAG-based Q&A agents, the interaction style is often exploratory and incomplete — more about trying to answer than precisely calling a tool. Restricting skills to pre-defined, tool-like constructs could make it harder to represent flexible, clarification-driven exchanges. (Which, interestingly, seems aligned with your point about multimodal agents — so I think we do share the same underlying concerns.)

In any case, from implementation perspective, I believe the current A2A AgentSkill abstraction will likely need to accommodate a broad spectrum — from guard-rails to Function Calling and/or MCP Tools to open-ended natural language handlers. It’s a deep and wide design space, and one we’ll probably have to refine collectively through usage and iteration across projects.

Also, perhaps it could be useful to eventually introduce a type field in the AgentSkill definition — something that indicates whether the skill is a tool, interactive, or some other category. That might help capture the range of interaction styles.

For what it’s worth, I’m also considering submitting a PR to the samples repo showing a case that leverages clarification, as I shared before in this thread, more explicitly — not sure if it’ll be accepted, but I think it could help surface some of these ideas.

P.S. I also had a look at the AgentUp project — haven’t explored everything yet, but it looks like a really useful framework. I’d love to learn more about it!

[lukehinds]

I love it, there is some great discussions playing out and thought put into it.

P.S. I also had a look at the AgentUp project — haven’t explored everything yet, but it looks like a really useful framework. I’d love to learn more about it!

Absolutely, its early days, a lot of polish needed - what communication method do you prefer , online zoom/hangouts, voice chat, discord, just let me know and can get something setup.

[ognis1205]

@lukehinds

Just to clarify my previous comment:

I believe your model of mapping skills to tools in AgentUp project makes a lot of sense when the agent’s capabilities are well-defined by APIs or function calls (e.g., via MCP or similar). However, in use cases like RAG-based Q&A bots, the notion of a "skill" may not align 1:1 with tools — the skill might be emergent from the model’s retrieval or reasoning ability, without a discrete tool boundary. (Even in such cases, it might be possible to map them 1:1 to functions or tools, depending on how they are implemented or operationalized.)

That said, the actual implementation can flexibly determine how skills are handled, and I believe that’s why the specification intentionally leaves the definition of AgentSkill somewhat vague. Because of this, there may not be a single "correct" interpretation at the implementation or operational level; rather, what matters more is how the concept of a skill is understood in the context of agent-to-agent interactions and at the prompt or reasoning level.

[lukehinds]

ack, I get just what you mean. I am using a rudimentary express of skill, but intent is a lot more nuanced!