Placement question for agentgateway and AGENTS.md, two AAIF hosted projects absent from the landscape

[asish-singh]

Following #25 and #27, which covered goose, two other AAIF hosted projects are missing from landscape/landscape.yml. Both raise a genuine placement question, so I am raising it for the Domain Editors rather than proposing a subcategory myself.

What is missing

I checked both against the published aaif/aaif-landscape landscape.yml, where each carries maturity: member, the same status MCP and goose have.

agentgateway (https://agentgateway.dev/, https://github.com/agentgateway/agentgateway), described upstream as a gateway for agentic AI that unifies MCP, agent to agent communication, LLM inference, APIs and services under one control plane. The published landscape files it under Frameworks & Infrastructure, Orchestration & Multi-Agent.

AGENTS.md (https://agents.md/, https://github.com/agentsmd/agents.md), a simple open format for guiding coding agents. The published landscape files it under Foundations & Protocols, Protocols & Standards.

Why the current subcategories are an awkward fit

For agentgateway, this taxonomy has no gateway, proxy or control plane subcategory. Orchestration Runtimes covers frameworks that compose agent logic rather than infrastructure that routes traffic between agents and tools, and Prompt & Runtime Guardrails is about inspecting and constraining model behaviour rather than routing. A data plane component does not clearly belong to either.

For AGENTS.md, Communication Protocols currently holds MCP and A2A, which are wire protocols. AGENTS.md is a repository file convention, so grouping it there would stretch what Communication Protocols means. Discovery & Naming is closer in spirit, since the file is how an agent finds instructions for a codebase, though that subcategory today holds registries and identity systems.

The question

Would the editors prefer to place these in existing subcategories, accepting the stretch, or to add something like a Gateways & Control Planes subcategory under Agent Runtimes, Frameworks & Workflow Orchestration and a Conventions & File Formats subcategory under Protocols & Discovery Registries? Either answer works for me. I mainly want the foundation's own hosted projects represented, and the second option may generalise better as more infrastructure and convention style projects arrive.

@thc1006 has offered to prepare the landscape.yml entries once a subcategory is chosen.

[asish-singh]

I have put up #30 as a draft so the two options above are concrete rather than hypothetical. It adds a Gateways & Control Planes subcategory and a Conventions & File Formats subcategory, with one entry in each.

To be clear about intent, the decision is still the editors' to make. If existing subcategories are preferred, or different names, I will close the draft or rewrite it to match.

@thc1006 you offered to prepare these entries, so please treat the draft as a starting point rather than a claim on the work. Happy for you to push to the branch, or to close mine in favour of yours if you would rather write it from scratch.

[thc1006]

Thanks @asish-singh, this is a good way to make the options concrete, and I would rather build on your draft than duplicate it.

The two entries look right to me: both project: member, homepage and repo URLs matching the published aaif/aaif-landscape, objective descriptions with no superlatives, and logo: placeholder.svg. I ran the full file through the #28 validator locally and it comes back clean.

The subcategory names and the existing-vs-new question stay with the Domain Editors. The two new names read well to me and follow the reasoning in #29, but I am happy either way. If they want a small change once they weigh in, I can push it to your branch, so there is no need to close the draft on my account.

[asish-singh]

Thanks @thc1006, that works well. The branch is open to you, so push whenever you like, and good to know the #28 validator comes back clean. That PR looks worth merging on its own merits, since it would catch this class of issue before a human reviewer has to.

Agreed that the naming call sits with the Domain Editors. One process question, since this adds subcategories rather than a single entry, which makes it structural. @malbasic would you prefer #29 and the draft in #30 on the agenda for a Workstream Sync, or is asynchronous editor review the better route? Happy either way, I just want to make sure it is queued in whichever place actually gets a decision.