Hi team,
I have a few questions about Google AX that I'd like to clarify before diving deeper. Would appreciate your insights!
- Entry point of the agent service
What is the primary entry point of AX? Is it a user-facing conversational interface (like a chat UI), or is it an API/endpoint designed for external agents to call and interact with?
- Multi-agent platform scenario
The architecture seems to be designed around the idea that a large number of agent services run on a single platform. However, from what I've observed, this doesn't seem to be a common use case in production today.
Could you share more about the typical user scenarios or real-world use cases that drive this requirement? Is this more of a forward-looking vision, or are there already production workloads that demand this kind of large-scale agent orchestration?
- AX: Agent or Agent Runtime?
The AX framework itself includes components like a Planner, LLM, and Executor, which makes it look very much like an agent. At the same time, it also acts as a runtime for orchestrating other agents.
So, is AX intended to be an actual agent that performs tasks itself, or is it primarily an agent runtime/framework that provides infrastructure for other agents to run on top of? A clear distinction here would be very helpful.
- Scalability concern: Is the Planner a bottleneck under high concurrency?
In a high-concurrency scenario with a large number of agents running simultaneously, all of them would presumably rely on the central Planner for task planning and orchestration. This seems like it could become a single point of contention and a performance bottleneck, especially given that planning often involves LLM inference with non-trivial latency.
Is the Planner designed to be horizontally scalable (e.g., running as a cluster with load balancing)? Or are there other mechanisms built into AX to address this scalability challenge?
Thanks in advance for your time and clarification. These questions will help us better understand whether AX fits our production use cases.
Hi team,
I have a few questions about Google AX that I'd like to clarify before diving deeper. Would appreciate your insights!
What is the primary entry point of AX? Is it a user-facing conversational interface (like a chat UI), or is it an API/endpoint designed for external agents to call and interact with?
The architecture seems to be designed around the idea that a large number of agent services run on a single platform. However, from what I've observed, this doesn't seem to be a common use case in production today.
Could you share more about the typical user scenarios or real-world use cases that drive this requirement? Is this more of a forward-looking vision, or are there already production workloads that demand this kind of large-scale agent orchestration?
The AX framework itself includes components like a Planner, LLM, and Executor, which makes it look very much like an agent. At the same time, it also acts as a runtime for orchestrating other agents.
So, is AX intended to be an actual agent that performs tasks itself, or is it primarily an agent runtime/framework that provides infrastructure for other agents to run on top of? A clear distinction here would be very helpful.
In a high-concurrency scenario with a large number of agents running simultaneously, all of them would presumably rely on the central Planner for task planning and orchestration. This seems like it could become a single point of contention and a performance bottleneck, especially given that planning often involves LLM inference with non-trivial latency.
Is the Planner designed to be horizontally scalable (e.g., running as a cluster with load balancing)? Or are there other mechanisms built into AX to address this scalability challenge?
Thanks in advance for your time and clarification. These questions will help us better understand whether AX fits our production use cases.