Agentic AI Foundation Standards in Embabel

[neilchaudhuri]

The Agentic AI Foundation, a spinoff of the Linux Foundation, is attempting to do for AI what the W3C did for the web 30 years ago. Long before AI, I was relentlessly pro-standards in every product I built for customers, and I was recently named one of 138 Agentic AI Foundation ambassadors worldwide. I think standards are even more important in the AI era given that model capability and cost change literally daily.

I think it would be beneficial for Embabel to incorporate some AAIF standards. In fact, it already does.

These are the current AAIF standards:

• MCP
• A2A
• AGENTS.md
• Goose
• agentgateway
• Agent Router

Embabel already supports MCP (though maybe not the most recent version which brought significant changes to become a stateless protocol) and A2A. I believe Embabel should also support AGENTS.md and the two gateways.

It is common for GitHub projects to have an AGENTS.md, a file that articulates standards, best practices, and key tasks for coding agents. I recently wrote up my own take on it. An Embabel version would provide important guidance to coding agents on how best to utilize Embabel's vast feature set and build and test Embabel applications.

Agent Router and agentgateway are gateways (Agent Router more specific to Envoy), which are critical in any distributed systems architecture but especially in an AI architecture. I believe an agent framework requires integration with popular gateways to be viable for nontrivial applications, and standard gateways should especially be on the radar.

I do not think Goose is in scope. Goose is like an open standard Claude Desktop or OpenCode. Its power is the ease with which you can configure models, MCP servers, scheduled tasks, etc. It's cool but not relevant to Embabel development.

That covers the official AAIF standards. However, I should mention Agent Skills, which are an open standard but not technically in AAIF. I think Embabel should provide a "very particular set of skills," to borrow from Liam Neeson in Taken, that represent Embabel-approved ways of performing common tasks like creating agents, defining tools, choosing the right planning algorithm, etc. I wouldn't think of this as a priority necessarily, but when people ask the same questions over and over, those strike me as good candidates for skills.

Because they serve as instructions to coding agents, AGENTS.md and Agent Skills are similar here in that there are sort of two audiences, the kind that apply to Embabel maintainers and the kind that apply to Embabel consumers. Something to keep in mind.

Look forward to your thoughts.

[igordayen]

@neilchaudhuri - Thank you.

Looping @tschuehly @jasperblues @jimador @johnsonr @alexheifetz @simeshev

[simeshev]

@neilchaudhuri,

Thanks for writing this up, and for separating Goose from the rest.

A small note so we don’t treat the AAIF list as a single backlog. I did take a look and it sounds like AAIF hosts several projects; only some of those are standards:

• Standards / protocols: MCP, A2A, AGENTS.md

• Runtimes / products Goose (local agent host — agreed, out of scope)

• Infra implementations: agentgateway, Agent Router (maybe useful in some deployments, not specs Embabel has to implement)

Embabel already speaks MCP and A2A. That’s the interoperability layer that matters for Embabel being an JVM agent authoring framework. I don’t think we should take on Goose or treat the gateways as required work unless someone has a concrete deployment that needs them.

What I would take, if the rest of the team agrees:

1. AGENTS.md for this repo - short, Embabel-specific guidance for coding agents (build/test, module map, Java vs Kotlin usage, planner/GOAP gotchas, what not to invent). That’s docs, not a protocol integration. Happy to draft an issue.

2. MCP / A2A freshness - only as follow-up issues with a real gap (maybe A2A TCK, or a specific MCP version change?). Not as "adopt the rest of the AAIF catalog.”

Agent Skills and the gateways feel like later product questions, not something to schedule from this thread.

If that split sounds right, I'm happy to open a small PR for AGENTS.md and we can leave the rest until there’s a concrete issue.

[igordayen]

1. AGENTS.md for this repo - short, Embabel-specific guidance for coding agents (build/test, module map, Java vs Kotlin usage, planner/GOAP gotchas, what not to invent). That’s docs, not a protocol integration. Happy to draft an issue.
2. MCP / A2A freshness - only as follow-up issues with a real gap (maybe A2A TCK, or a specific MCP version change?). Not as "adopt the rest of the AAIF catalog.”

1 - @tschuehly, could you please remind me whether you created AGENTS.md, saw in other than embabel-agent repo
2 - #580, minor gap, following up

thanks

[neilchaudhuri]

I would never suggest a separate backlog, but @igordayen asked me to write something up and I have believed for 20 years that supporting standards is a good idea for any ambitious framework. So I was happy to do it.

While they are not all protocol standards, the components I described are all AAIF standards, but as I wrote, not all are relevant to Embabel. Goose clearly is not. As for the gateways, I'm not sure. A week ago, I would have agreed they are also not in Embabel scope, but that was before I saw #1947, which is coming in Embabel 1.5.3. If the team is apparently interested in supporting gateways, then I would think standard gateways, especially agentgateway which is more agnostic than Agent Router, are as good candidates as any.

Also, to use an American expression, I wouldn't sleep on infrastructure standards. Kubernetes being the de facto standard revolutionized Cloud Native (for better or worse but that is a different conversation). As I see the concerns of one customer after another, I think gateways are critical infrastructure for mature AI deployments, far more than even any individual model.

A few other points:

• I suppose one could characterize anything around customizing AI—prompts, Skills, Spec-Driven Development, AGENTS.md, etc.—as "docs," but I think that understates their power. There is an art to writing them, and when you do them well, they supercharge your agentic development by enforcing technology, project, and team standards at scale.
• It's important to remember that supporting a standard is not a binary matter where we support it or we don't. For example, every framework would say they support MCP of course, but on July 28th, MCP released a fundamental transformation, transitioning to a stateless protocol and significant security hardening. I haven't checked, but I doubt all the major frameworks have caught up. So support is a spectrum rather than binary. I also don't know if it's in Embabel scope to catch up rather than to wait to delegate to Spring AI or the official Kotlin SDK or whatever.

[igordayen]

@neilchaudhuri @simeshev

There is also a PR on Router: #1955 - seems inactive, even after a few follow-ups.

Architecturally, Embabel is not tightly coupled with Spring AI, and we tested Tool Loop Ops with LangChain4j successfully. Ideally, being vendor-agnostic is a good thing to have with respect to low-level APIs.

Per my understanding, there is an intersection between:
agentgateway
Agent Router

Is my understanding accurate?

Thank you.

[neilchaudhuri]

@igordayen I am not super knowledgeable about Agent Router because it became an official AAIF standard in the last last couple of weeks, but there is a strong overlap between that and agentgateway. They are both gateways, and its hard for me to imagine one product deploying both simultaneously.

The primary difference is that Agent Router is built on Envoy Proxy and Envoy Gateway, originally by engineers at Bloomberg and Tetrate. This implies a very specific deployment profile. In other words, it's only an option if you use (or plan to use) Envoy.

However, I do not have metrics on relative popularity and have not studied the differences in technical implementation details between them. If you have specific questions, I am sure I can get answers from my colleagues at AAIF.

[igordayen]

If you have specific questions, I am sure I can get answers from my colleagues at AAIF.

@neilchaudhuri - would be good to know AAIF's direction on router/gateway as an emerging standards. Thank you

[igordayen]

Adding the official link:

https://aaif.io/projects/agentgateway

[neilchaudhuri]

And this one for Agent Router.

I asked for any further information on direction @igordayen but haven't heard back yet. In the meantime, their GitHub pages offer roadmaps.

[capitaharlock]

I'd push back on the "requires integration with gateways to be viable" test. Exposing clean A2A and MCP endpoints matters more than embedding gateway-specific SDKs. Our runtime exposes an A2A card at /.well-known/agent.json plus a hosted MCP server, and there are zero references to agentgateway or Agent Router anywhere in the codebase. It's still reachable through standard routing because it speaks those protocols. That keeps the gateway a deployment decision instead of a framework dependency.

[igordayen]

My point was not "Embabel must be tightly coupled to AAIF gateways until AI destroys us all." :)

[igordayen]

However, if Embabel has indeed decided to get into the business of gateways with #1947 coming in v1.5.3, then standard gateways are as good candidates as any to also be on the roadmap.

@neilchaudhuri Undecided...still, thanks for the comments.

Perhaps broader support for the latest MCP standard is on the critical path.
I'm uplifting the A2A stack to the recent standard.

[neilchaudhuri]

@igordayen I would say the transition to the new stateless MCP should be the highest priority. That is extremely important. A2A also should be up there. AGENTS.md and Skills are useful, especially to reflect answers to the common questions I see in Discord and for heuristics (when to use which planner, avoiding functional and reactive types, wiring up tools and observability according to Embabel best practices, etc.), but they are not as high on the list.

As for gateways, it is not a binary, black-or-white thing like Embabel supports a gateway or it doesn't. There is a spectrum from complete agnosticism to "gateway-specific SDKs." For example, there is a Spring Cloud AWS and Spring Cloud Azure, but you can also deploy Spring Cloud on OpenShift. I think it makes sense to see how AI infrastructure evolves to see what hits, to use an American idiom, and then making decisions from there. If, for example, agentgateway really gets popular like Kubernetes did for Cloud Native, then a dedicated embabel-agentgateway might make sense. But these are decisions for down the road.

[igordayen]

I would say the transition to the new stateless MCP should be the highest priority. That is extremely important.

@neilchaudhuri - thanks.

Feel free to open an issue. Thanks!

[neilchaudhuri]

See #2054 @igordayen