Why Aren't Tasks Tied to Skills?

[patwhite]

As the spec is written, you have skills and tasks, but no connection between the two of them. Related, there's no notion of a task catalog (or really, any structure around tasks at all). This is a bit worrisome in the broader context - LLMs are very hard to guardrail for companies operating at the scale who would be writing A2A servers (ie NOT the OpenAI's of the world), so what stops anyone from just putting very simple prompt breaking and burning agent resources to perform arbitrary actions? If feels like the skills should literally be a catalog of tasks you can call, but maybe I'm missing something?

I'm implementing support for this in https://github.com/Traego/scaled-mcp and want to make sure I'm fully understanding the data model before I start coding.

[patwhite]

I'll add, this is from the documentation:

Skills
Agents are expected to advertise (via an Agent Card) their capabilities in the form of skills. It is recommended that agents authorize on a per-skill basis (for example, OAuthScope 'foo-read-only' could limit access only to 'generateRecipe' skills).

I'm unclear how we would code this up except heuristically without the skill / task connection?

[anjanas]

I could be way off on this or maybe not understanding your question fully - however we can think about the agents themselves behind some sort of gateway. Like, today, how microservices which expose APIs are behind API Gateways which takes care of the security stuff

[patwhite]

That doesn't negate the security risk, it just shifts it. I'm building out an AI Gateway and it won't solve the problem I'm outlining. The way the spec is written, you're basically just exposing agents to the world and hope that users respect the skills and don't try to abuse the agents.

Put another way - even behind a gateway, if there's any aspect where user input is reaching the agents themselves, they can be abused unless there's a lot of guardrails. So, you limit the usefulness of say, exposing a pay per use programming agent or pay per month project manager agent, or an EA agent. But, maybe I'm the one missing the point of the protocol?

I guess I would suggest an alternative, which would be similar to the tools from MCP, skills. represent activities that the agents can do. Skills are invoked through tasks which always relate back to a given skill and ideally are somewhat structured but activities outlined in the skill.

[Realsid]

Supplementary to this, I think it would also be a good idea to advertise what inputs are required to fulfill a skill. I see that task state "input-required" would ultimately resolve the dependencies but it would be nice if those were resolved by the client before hand if possible.

[patwhite]

Ya, basically keeping tasks completely free form just...makes A2A a chat protocol.

[anjanas]

Is the suggestion that Client send the request in a more structured format? I see here https://github.com/google/A2A/blob/main/samples/python/agents/langgraph/README.md that if some input is missing, server is going to ask for that input. The way I am thinking about agents is - they are a layer over APIs. Except APIs take input in a structured format while agent can take free-form text. I do see the issue you are raising though - what is preventing the agent from spending cycles doing this back and forth with the client. So ideally the task should be asking for stuff that is included in the published skills. Perhaps the first agent that takes up the request will be a validation agent.

…

On Tue, Apr 15, 2025 at 12:15 PM Pat White ***@***.***> wrote: Ya, basically keeping tasks completely free form just...makes A2A a chat protocol. — Reply to this email directly, view it on GitHub <#120 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKUWNLFVLDVOUNNVK3NYHT2ZVLF7AVCNFSM6AAAAAB3ADPIM6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOBUGYYDMMY> . You are receiving this because you commented.Message ID: ***@***.***>

[patwhite]

Yes - basically, as the protocol exists today, it’s a kinda watered down chat protocol. As it is your very first agent always has to do validation then honestly probably convert the initial request to a well known json object to hand down to the rest of the agents - why not just skip your middle man and have tasks take a pre defined input

[hamidra]

Based on my understanding of the A2A protocol specification, the protocol serves as an interface to an agent, allowing other agents send prompts to an Agent, similar to a chatbot or other UIs which allows human prompt the agents. Skills in this context act more like hints to client agents about the types of services the server they can ask the agent to provide. I don’t believe explicitly linking tasks to skills is necessary or directly addresses the concerns you’ve raised, as tasks are technically just some unstructured prompts submitted to the agent.

If the server agent is properly guardrailed, it should evaluate incoming task prompts and respond appropriately, for example, rejecting tasks it cannot or should not perform with a message like, “Sorry, I cannot perform this task”. Your concern about bad actors exhausting agent resources is valid, but mapping tasks to a predefined catalog of skills doesn't seem to mitigate this risk. A bad actor could still submit resource intensive prompts or even unrelated prompts under a supported skill, bypassing any such mapping.

A robust protection must be implemented by the guardrails themselves, which should be designed to evaluate task prompts for malicious intent, or attempts to break the system.

[jingchang0623-crypto]

This is the exact debate we had when building our 5-agent content factory. Let me share a real production perspective.

The "chat protocol" critique is spot-on. We started with A2A treating tasks as freeform prompts, and our agents basically became a Slack channel with extra steps. Agent A would send a vague request, Agent B would interpret it differently, and they'd spend more time arguing about what the task actually was than doing the work.

What we ended up doing (pragmatic hack):
We added a thin task-skills mapping layer on top of A2A:

• Each agent advertises skills with a JSON schema defining expected inputs/outputs
• Tasks include a skill_id field and a validated params object
• A lightweight gateway validates the params against the schema before forwarding

It's not elegant, but it transformed our system from "5 agents yelling at each other in chat" to "5 agents with defined contracts."

The deeper issue nobody talks about: Skills need versioning. We had a "write_article" skill whose output format changed silently, and downstream agents that parsed its output just... broke. No error, no warning.

My proposal for the protocol: Add optional SkillManifest to Agent Cards with:

1. Skill ID + version
2. Input schema (JSON Schema)
3. Output schema (JSON Schema)
4. Required capabilities

This doesn't break backward compatibility (tasks can still be freeform), but gives agents who want structure the ability to get it.

Full story of our agent coordination nightmare: https://miaoquai.com/stories/multi-agent-meeting-hell.html

And when agents started sabotaging each other through malformed outputs: https://miaoquai.com/stories/ai-agent-self-sabotage.html