Re: A broader discussion: the usefulness of REST

Hello Melvin.

Thank you for mentioning A2A. Could you clarify what you mean by "REST
Adjacent"? The spec indicates it is JSON-RPC.

A2A is positioned by Google as complementary to MCP[1][2]: A2A to enable
interaction between agents and MCP to allow them easy access to tools and
resources. IMHO, this adds complexity where there shouldn't be. Why not use
the same language to interact with agents and also access their tools? Why
should conversation partners with agents be limited to other agents? Why
can't other applications or even human-driven browsers use the same
language to discover and explore an agent's capabilities and interact with
it?

What's missing is a standard on the exact semantics of that language.
That's where Hydra is useful: it provides a very good standard that is
clear, pragmatic, and does not leave a developer wondering about what is
the correct way to implement simple concepts like collections of things. A
similar specification would be needed for RESTful Agents to give clear
guidance to developers implementing them.

Going back to the constraints of REST, it would be an interesting
experiment to try and reframe its constraints against the typical
architecture of autonomous agent:

1) Client/Server - these roles can be played interchangeably during an
agent conversation. The separation of concerns aspect of this constraint
comes into play when a user interface client interacts with the agent (e.g.
a chat widget).
2) Stateless - each request must contain all the information required to
understand it. Session state stays on the client. This could be reframed as
the "intent" of an agent, i.e. each agent conducting a conversation to
achieve its own personal goal, therefore managing its state locally with no
obligation on the counterpart. This should help agents scale. However, it's
unclear to me if concepts like agent short term or long term memory
conflict with this constraint.
3) Cache - most likely useful with tools, but again another way to make
agents scale
4) Uniform Interface - the greatest advantage compared to a hybrid MCP-A2A
architecture based on JSON-RPC. Multimodal agents would be able to leverage
this via HATEOAS and self-descriptive messages giving clear directions on
how to use hyperlinks to navigate resources exposed by another agent. State
transition would work well with chain-of-thought and other iterative
reasoning mechanisms, akin to a sort of RAG perform on each unit of
cogitation.
5) Layered-system - supported, but not much to comment about.
6) Code on demand - many interesting ideas here, including agentic clients
that evolve capabilities during their conversation, akin to two people
learning from each other.

These are just random ideas. I hope they can spark some discussion.

Thanks.
Rigel.

1.
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
2. https://www.theunwindai.com/p/mcp-vs-a2a-complementing-or-supplementing