Federated Agentic UI: a component catalog assembled at runtime from micro frontends

[lutzleonhardt]

Hi everyone 👋

I built a demo with CopilotKit, AG-UI and A2UI in Angular that explores one question: what if the component catalog the agent can use isn't fixed, but assembled at runtime?

In real apps, the building blocks an agent should be able to use often depend on context: the user's permissions, the device, the tenant's license, feature flags. So in this demo, every component comes as a capability with two halves:

• Vocabulary for the model: the component and function descriptions the agent sees
• Implementation for the renderer: the matching Angular components registered with the A2UI renderer

Capabilities are delivered by Native Federation remotes (micro frontends), so separate teams can ship them independently. If a capability is loaded, the model can use it. If it isn't, the model doesn't know the component exists and tells the user what it can't show instead of improvising. Neither the shell nor the agent server is rebuilt or redeployed.

In the video: same prompt twice. Without the maps capability, the assistant says it has no map component. With it, you get an interactive map with a working distance slider.

hero-linkedin.mp4

Some details:

• Stack: Angular, CopilotKit, AG-UI, Mastra as the agent server, @a2ui/angular for rendering, Native Federation
• Eval gate: a headless-browser eval checks that the model only uses components from the announced catalog (4 of 5 runs must pass)
• Runtime checks: capabilities are validated when loaded, and agent output is schema-validated at the tool boundary before rendering
• Restriction by absence: instead of telling the model what it mustn't show, you leave the component out. (UI boundary, not a data boundary: authorization still belongs in the backend.)

The base architecture follows Manfred Steyer's book "Agentic UI with Angular".

• Demo (no API key needed, replays recorded runs): https://lutzleonhardt.de/conference-finder/
• Repo and docs: https://github.com/lutzleonhardt/native-federation-a2ui

Happy to hear how others handle context-dependent capabilities with CopilotKit, e.g. per-user tools or components.

[copilotkit-outpost-bot[bot]]

⚠️ This is an AI-generated response. We've escalated this to our engineering team — someone will follow up in this thread shortly.

This is a really elegant approach to capability scoping — using absence as the restriction mechanism rather than explicit deny-lists is a clean architectural decision, and the eval gate that enforces catalog honesty is a nice touch.

The Angular A2UI path you're building on (@copilotkit/angular + a2ui.catalog) does exactly what you'd expect here: the catalog you pass at runtime is what gets injected into the agent's context, so a component that isn't in the catalog simply doesn't appear in the schema or generation guidelines the model sees. That's the same contract the source enforces — #isA2UIActive() won't register renderers or inject context at all without a configured catalog, and #syncA2UIContexts() builds the model's view of available components exclusively from whatever catalog object you provide. (packages/angular/src/lib/copilotkit.ts)

The Native Federation angle is a natural fit for this — lazy-loading a remote that contributes both a catalog fragment and its Angular renderer component means the shell never needs to know about capabilities it hasn't loaded, and the model's context stays in sync automatically. The eval gate closing the loop on that is the part I'd highlight to anyone building something similar: without it, you're trusting the architecture rather than verifying it.

---

_{🤖 Generated by CopilotKit AI Support · Documentation}

---

Was this helpful? React with 👍 or 👎