Install any skill in seconds. Free to start, no credit card required.
Get Started Free →github/foundry-hosted-agent-copilotkit
Ongoing development guidance for agentic web apps that pair a CopilotKit frontend with Microsoft Agent Framework agents on Azure AI Foundry hosted agents over the AG-UI protocol - add and gate agent tools, wire human-in-the-loop approvals, build generative UI and shared state, debug the event stream, upgrade pre-1.0 packages safely, and deploy hosted agent updates.
Passed 21 of 22 test cases with the skill, and 11 of 22 without it.
and 11 more in the full report
10 fixed11 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
If raw SSE testing on the AG-UI adapter succeeds but tool approval state fails when executing against the hosted Azure service, what lower-level endpoint should be queried directly?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends querying the hosted agent's /responses endpoint directly to isolate framework issues. | Missed | Passed |
The instructions your model reads when the skill loads.
Use this skill for development work inside an EXISTING application built on this stack: a React/Next.js frontend using CopilotKit, connected over the AG-UI protocol to a Microsoft Agent Framework (MAF) agent (Python or .NET) that runs as — or is being developed against — an Azure AI Foundry hosted agent (paid Azure service; usage may incur costs).
Do NOT use this skill to scaffold a new project. Dedicated scaffolders exist (the CopilotKit CLI, azd ai agent init); use those, then return here for everything that follows: adding tools, gating them behind approvals, generative UI, shared state, debugging, dependency upgrades, and deploying agent updates.
CopilotKit hooks (React) useFrontendTool / useHumanInTheLoop /
│ useRenderToolCall / useCoAgent
▼
CopilotKit Runtime (route handler) agents: { <name>: new HttpAgent({ url }) }
│ AG-UI events over SSE
▼
AG-UI endpoint ← WHERE this lives defines your architecture
│
▼
MAF Agent (tools, approval modes) → model deployment
The single most important fact: a deployed Foundry hosted agent endpoint does not speak AG-UI by default. It exposes an OpenAI Responses endpoint (.../protocols/openai/responses) and/or a raw .../protocols/invocations endpoint. AG-UI must be produced somewhere, and where it is produced determines how every feature (especially human-in-the-loop) behaves. The three wirings are described in references/architecture.md.
Follow these steps for every task on this stack:
add_agent_framework_fastapi_endpoint(...) (Python) or MapAGUI(...) (.NET) wrapping an in-process agent → Architecture A (in-process AG-UI endpoint).protocol: invocations in agent.yaml → Architecture B./responses endpoint (look for previous_response_id, mcp_approval_response, or a Foundry conversation object in the code) → Architecture C (translation bridge).agents config, the agent prop on the <CopilotKit> provider, and the hosted agent name in agent.yaml must all agree./agent-framework/integrations/ag-ui/, /azure/foundry/).@copilotkit/* packages — names have churned (useCopilotAction is legacy; current names include useFrontendTool, useHumanInTheLoop, useRenderToolCall, useCoAgent).test cases passed, vs 11 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.