[jensneuse]

One thing I find interesting is how GraphQL has evolved from an API technology for API consumers with "different needs" to an API technology for agents. What helped organizations scale GraphQL across multiple teams is Federation, a way to split one supergraph into multiple subgraphs. So, what works well to scale teams actually works equally well for agents. The core value you can get from Federation is a "coordination" layer that is deterministic. Now, what's interesting is that you can scale agentic software development pretty well when you have a deterministic layer where everyone involved can agree. I wrote more about this on our blog if anyone is interested: https://wundergraph.com/blog/graphql-api-layer-for-ai-agents

[troelsSteegin]

I think of "Federation" as aggregating content from disparate in-situ sources into a common index under a consistent schema. I agree that schema is good, am always tempted by big schema, and seem to always settle for task-specific schema with mappings between schemas strictly as necessary. LLM's seem nice for schema to schema mapping and supernice for binding entities from unstructured sources into schema. But overall I feel it is pointless to talk about structure without talking about hydration - about binding and mapping. Do you see that as "solved"?