Using AG-UI with Foundry Hosted Agents #4720
|
Hi! I would like to deploy a hosted agent to Foundy. It will mainly just have some local code tools, but I want to take advantage of the observability, session storage and scaling features etc that follows on the platform. I would also like to access this agent from a CopilotKit frontend, so I need the agent to be able to respond in AG-UI events. Is there a clean or right way to do this? Because the Can I just deploy my agent to Foundry with the tools available and then add a AG-UI FastAPI application that proxies to the Foundry agent over REST? It's another proxy service in addition to the Copilotkit Runtime, but maybe it doable. So basically running both these apps servers and make them communicate over REST? Or am I overthinking this? For reference it's mainly the functionality of the boilerplate Starlette/FastAPI from these two functions that I want to integrate: from azure.ai.agentserver.agentframework import from_agent_framework
from agent_framework.ag_ui import add_agent_framework_fastapi_endpoint |
Replies: 1 comment 2 replies
|
Hi Viktor Shamal Andersen (@shamal-kp), I ran into the same wall and ended up building a working example, so sharing what worked in case it saves you some time: https://github.com/Santiagosala2/foundry-agui-example You're right that AgentFrameworkAgent doesn't fit into the wrapper from azure.ai.agentserver.core - that path assumes the responses protocol, which is OpenAI-compatible and platform-managed, so you never get control of the event stream. AG-UI needs its own SSE format, so that's a dead end. But you don't need the proxy app either. Hosted agents also support the invocations protocol, which hands you the raw HTTP request and lets you write the SSE stream yourself — the docs even list AG-UI explicitly as an invocations use case (protocol table here). So the whole thing runs inside the hosted container, and you keep the observability/session storage/scaling benefits. The core of it is just an invoke handler that pipes AgentFrameworkAgent's events through the AG-UI encoder: app = InvocationAgentServerHost() @app.invoke_handler where protocol_runner is your AgentFrameworkAgent(agent=..., state_schema=..., predict_state_config=...) — same as in the recipe agent example. In azure.yaml you declare protocols: invocations instead of responses. On the CopilotKit side, the runtime just points an HttpAgent at the agent's invocations endpoint. Two gotchas once it's deployed: you need a bearer token for the https://ai.azure.com/.default scope (the caller needs the Foundry User role), and a Foundry-Features: HostedAgents=V1Preview header. My repo has the full thing end to end — a travel planner with shared state (predict_state_config streaming into the UI), the azd deployment setup, and the Next.js/CopilotKit side. Happy to answer questions if you hit anything. |
Hi Viktor Shamal Andersen (@shamal-kp), I ran into the same wall and ended up building a working example, so sharing what worked in case it saves you some time: https://github.com/Santiagosala2/foundry-agui-example
You're right that AgentFrameworkAgent doesn't fit into the wrapper from azure.ai.agentserver.core - that path assumes the responses protocol, which is OpenAI-compatible and platform-managed, so you never get control of the event stream. AG-UI needs its own SSE format, so that's a dead end.
But you don't need the proxy app either. Hosted agents also support the invocations protocol, which hands you the raw HTTP request and lets you write the SSE stream yourself — the docs even l…