{"id":33324,"date":"2026-05-01T21:28:26","date_gmt":"2026-05-01T19:28:26","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=33324"},"modified":"2026-07-30T08:01:20","modified_gmt":"2026-07-30T06:01:20","slug":"integrating-a2ui-with-ag-ui-in-angular","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/integrating-a2ui-with-ag-ui-in-angular\/","title":{"rendered":"Integrating A2UI with AG-UI and CopilotKit in Angular"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 6 of 10 in the series “Agentic UI with Angular”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Understanding AG-UI: The Standard for Agentic User Interfaces<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. AG-UI in Practice: The SDK for TypeScript<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. AG-UI End to End: Connecting Server and Client<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Agentic UI with Angular, CopilotKit, and AG-UI<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. A2UI: How AI Generates Dynamic UIs at Runtime<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Integrating A2UI with AG-UI and CopilotKit in Angular<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  8. A2UI with a DSL: Controllable Dashboards Optimized for Performance<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  9. Agentic UI with MCP Apps: Tool Results as Interactive Widgets<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  10. MCP Apps in Angular with CopilotKit: Rich Chat Interfaces Instead of Text Responses<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    From the first example to a real agent connection via AG-UI.<\/em><\/p>\n

    In practice, A2UI messages don't come from static code, but from the responses of a real language model \u2013 and these first need to be transported from the agent to the client. AG-UI offers the right transport layer for this, but the official specification leaves open how A2UI is to be transmitted over it. This article shows a pragmatic solution and connects the client using the Angular integration of CopilotKit<\/a>.<\/p>\n

    This second part of the three-part series picks up where the first part left off, where we still ran A2UI and the Angular renderer with hardcoded messages.<\/p>\n

    \ud83d\udcc2 Source Code<\/a> (see branch copilotkit<\/code>)<\/p>\n

    How Do You Transmit A2UI Messages over AG-UI?<\/h2>\n

    So far we've looked at A2UI in isolation. In practice, however, the client communicates with the agent via HTTP calls. This is exactly where the protocol AG-UI<\/a>, mentioned in the previous article in this series, comes into play, standardizing the communication between frontend and agent.<\/p>\n

    We can elegantly embed A2UI into this world by transmitting the A2UI messages inside an AG-UI message of type ACTIVITY_SNAPSHOT<\/code>. The browser's developer tools show such a snapshot:<\/p>\n

    \"Browser<\/p>\n

    In textual form, the snapshot looks like this:<\/p>\n

    {\n  "type": "ACTIVITY_SNAPSHOT",\n  "messageId": "srf-france-confirm",\n  "activityType": "a2ui-surface",\n  "content": {\n    "operations": [\n      {\n        "version": "v0.9",\n        "createSurface": {\n          "surfaceId": "srf-france-confirm",\n          "catalogId": "https:\/\/a2ui.org\/specification\/v0_9\/basic_catalog.json"\n        }\n      },\n      {\n        "version": "v0.9",\n        "updateComponents": {\n          [...]\n        }\n      },\n      {\n        "version": "v0.9",\n        "updateDataModel": {\n          "surfaceId": "srf-france-confirm",\n          "path": "\/dummy",\n          "value": ""\n        }\n      }\n    ]\n  }\n}<\/code><\/pre>\n
    Unfortunately, there is no official definition for how A2UI messages are to be transmitted over AG-UI. The solution shown here, an ACTIVITY_SNAPSHOT<\/code> with a corresponding activityType<\/code>, fits well with the semantics of AG-UI, however, and matches exactly the interpretation of CopilotKit<\/a>, whose Angular integration we also use on the client side below. Since the makers of CopilotKit are among the initiators of AG-UI, their interpretation of the standard naturally carries significant weight.<\/p>\n
    As an alternative to an ACTIVITY_SNAPSHOT<\/code>, a server-side tool call would also be conceivable, especially since AG-UI informs the client about tool calls and their results. In this case, however, the client and agent would have to agree on the name of such a tool that delivers A2UI as its result.<\/p>\n
    The Building Blocks: A2UI Renderer, CopilotKit, and a Server-Side Layer<\/h2>\n
    For the implementation, we rely on two building blocks: the Angular renderer for A2UI discussed in the first part, and the Angular integration of CopilotKit (@copilotkit\/angular<\/code>), which takes care of the AG-UI communication.<\/p>\n
    The server-side agent<\/a>, which we won't look at in detail here, guides the language model via prompting to produce A2UI structures \u2013 not directly for the client, however, but as input for a server-side tool. This tool plays a central role: it validates the A2UI messages generated by the LLM and ensures that only consistent and executable structures are processed further.<\/p>\n
    The prompt does not limit itself to the request to produce A2UI. In addition, it contains a few complete example surfaces the model can orient itself on, as well as a reference to the schema of the Basic Catalog, which the agent can retrieve when needed. This way, the model doesn't just know the rough structure of an A2UI response, but can also look up the details of the individual components.<\/p>\n
    This is crucial, because LLMs are not guaranteed to deliver valid results. If validation fails, the feedback is sent back to the model so that it can try again. Only when a valid structure is available is it forwarded.<\/p>\n
    The server-side implementation<\/a> then transforms the validated A2UI messages into an ACTIVITY_SNAPSHOT<\/code>. This becomes part of the regular AG-UI stream and can therefore be processed uniformly by CopilotKit on the client side.<\/p>\n
    Client-Side Integration with CopilotKit<\/h2>\n
    On the client side, CopilotKit takes care of the connection to the agent. The central construct here is an agent store: a signal-based object that manages the chat history, executes client-side tool calls, and provides the received messages.<\/p>\n
    This store is initialized in the function injectTicketingAgentStore<\/code>. It registers the agent with its URL and the offered client tools, among other things, and then returns the store (slightly simplified):<\/p>\n
    import { inject } from '@angular\/core';\nimport { injectAgentStore } from '@copilotkit\/angular';\n\nimport { initAgentStore } from '..\/..\/shared\/util-copilotkit\/init-agent-store';\n\n[...]\n\nexport const TICKETING_AGENT_ID = 'ticketingAgent';\n\nexport function injectTicketingAgentStore() {\n  initAgentStore({\n    agentId: TICKETING_AGENT_ID,\n    url: inject(ConfigService).agUiUrl,\n    useServerMemory: true,\n    frontendTools: [\n      findFlightsTool,\n      getLoadedFlightsTool,\n      toggleFlightSelectionTool,\n      getCurrentBasketTool,\n      displayFlightDetailTool,\n    ],\n  });\n\n  return injectAgentStore(TICKETING_AGENT_ID);\n}<\/code><\/pre>\n
    The helper function initAgentStore<\/code><\/a> belongs to a lean glue layer of the example project (folder util-copilotkit<\/code>). For the given URL, it creates an agent derived from the AG-UI SDK's HttpAgent<\/code>, registers it in the CopilotKit runtime as a so-called self-managed agent, and announces the passed client tools via CopilotKit's registerFrontendTool<\/code>. The flag useServerMemory<\/code> ensures that only new messages are transmitted to the server, because the server stores the history itself.<\/p>\n
    The actual centerpiece, however, comes directly from CopilotKit: injectAgentStore<\/code> provides the signal-based AgentStore<\/code>, through which the application accesses the chat history (messages<\/code>), the execution status (isRunning<\/code>), and the agent itself.<\/p>\n
    A service of the ticketing domain uses this function and additionally registers the event handlers for the A2UI surfaces:<\/p>\n
    import { inject, Injectable } from '@angular\/core';\nimport { CopilotKit, injectInterrupt } from '@copilotkit\/angular';\n\n[...]\n\n@Injectable({ providedIn: 'root' })\nexport class TicketingChatService {\n  private readonly chatRegistry = inject(ChatRegistry);\n  private readonly copilotKit = inject(CopilotKit);\n  private readonly store = injectTicketingAgentStore();\n  [...]\n\n  constructor() {\n    registerHandlers({\n      checkIn: (action) => checkInAction(action),\n      submitAnswer: (action) =>\n        submitAnswerAction(action, this.copilotKit, this.store),\n    });\n  }\n\n  public init(): void {\n    this.chatRegistry.setChat({\n      store: this.store,\n      [...],\n    });\n  }\n}<\/code><\/pre>\n
    The helper function registerHandlers<\/code> defines the event handlers and internally delegates to the onAction<\/code> property of the A2UI renderer discussed in the first part. To send a message, the function sendMessage<\/code> comes into play:<\/p>\n
    await sendMessage(\n  this.copilotKit,\n  this.store,\n  'Did I book my flight to France?',\n);<\/code><\/pre>\n
    It appends the message to the agent and triggers a new run via the CopilotKit runtime:<\/p>\n
    export async function sendMessage(\n  copilotKit: CopilotKit,\n  store: Signal<AgentStore>,\n  input: SendMessageInput,\n): Promise<void> {\n  const agent = store().agent;\n  agent.addMessage({ id: randomUUID(), role: 'user', content: input });\n  await copilotKit.core.runAgent({ agent });\n}<\/code><\/pre>\n
    NOTE<\/p>\n
    New: Agentic UI with Angular<\/h3>\n
    If you don\u2019t just want to integrate A2UI but embed it into a scalable architecture:
    \nIn my book Agentic UI with Angular, I cover the underlying patterns and trade-offs in depth.<\/p>\n
    \"Cover<\/a><\/p>\n
    Learn more about the eBook \u2192<\/a>\n<\/div>\n<\/p>\n
    Providing an A2UI Activity Renderer<\/h3>\n
    For messages with the role activity<\/code>, CopilotKit provides so-called activity renderers: Angular components that define, per activityType<\/code>, how the content of a snapshot is to be displayed.<\/p>\n
    CopilotKit does already come with its own A2UI support. At the time this article was written, however, it was built on a renderer for web components, so custom catalogs could only be implemented with web components. Instead, we want to plug in the Angular renderer from the first part \u2013 and that turns out to be pleasantly little work, since the actual rendering is still handled by that renderer.<\/p>\n
    Let's start with the content<\/code> of the ACTIVITY_SNAPSHOT<\/code>. CopilotKit requires a schema for it and uses that to check the received content before it is displayed. We implement this schema here with Zod<\/a> \u2013 in the case of A2UI, the content consists merely of the list of operations:<\/p>\n
    import { z } from 'zod';\n\nexport const a2uiSurfaceContentSchema = z.object({\n  operations: z.array(z.custom<A2uiMessage>()),\n});\n\nexport type A2uiSurfaceContent = z.infer<typeof a2uiSurfaceContentSchema>;<\/code><\/pre>\n
    The schema is deliberately compact: it makes sure that operations<\/code> is an array at all, but doesn't check the individual operations any further. The z.custom<A2uiMessage>()<\/code> merely specifies the TypeScript type without validating at runtime. This satisfies CopilotKit's requirement for now; the content-level checking of the operations is handled by the A2UI renderer anyway. If you like, you can of course provide a stricter schema here.<\/p>\n
    Conveniently, z.infer<\/code> also gives us the matching TypeScript type A2uiSurfaceContent<\/code>.<\/p>\n
    With that, we can now implement the actual activity renderer. It passes the received A2UI operations to the A2uiRendererService<\/code>, displays the resulting surface via the SurfaceComponent<\/code> discussed in the first part, and manages its lifecycle (abridged):<\/p>\n
    import { A2uiRendererService, SurfaceComponent } from '@a2ui\/angular\/v0_9';\n\n[...]\n\n@Component({\n  selector: 'app-a2ui-activity-renderer',\n  imports: [SurfaceComponent],\n  host: { class: 'a2ui-surface' },\n  template: `\n    @let surface = surfaceId();\n    @if (surface) {\n      <a2ui-v09-surface [surfaceId]="surface" \/>\n    }\n  `,\n})\nexport class A2uiActivityRenderer\n  implements ActivityRenderer<A2uiSurfaceContent>\n{\n  readonly activityType = input.required<string>();\n  readonly content = input.required<A2uiSurfaceContent>();\n  readonly message = input.required<ActivityMessage>();\n  readonly agent = input.required<AbstractAgent | undefined>();\n\n  private readonly renderer = inject(A2uiRendererService);\n  private renderedSurfaceId: string | null = null;\n\n  constructor() {\n    effect(() => {\n      const operations = this.content().operations;\n      const surfaceId = getRenderedSurfaceId(operations);\n      if (!surfaceId || surfaceId === this.renderedSurfaceId) {\n        return;\n      }\n\n      this.releaseSurface();\n      this.renderedSurfaceId = surfaceId;\n      this.renderer.processMessages(operations);\n    });\n\n    inject(DestroyRef).onDestroy(() => {\n      this.releaseSurface();\n    });\n  }\n\n  private releaseSurface(): void {\n    if (this.renderedSurfaceId) {\n      this.renderer.surfaceGroup.deleteSurface(this.renderedSurfaceId);\n      this.renderedSurfaceId = null;\n    }\n  }\n\n  protected readonly surfaceId = computed(() =>\n    getRenderedSurfaceId(this.content().operations),\n  );\n}<\/code><\/pre>\n
    So that CopilotKit can address this component as an activity renderer, it implements the interface ActivityRenderer<\/code> coming from @copilotkit\/angular<\/code>. The type parameter determines the structure of the snapshot content \u2013 in our case, A2uiSurfaceContent<\/code>. The interface prescribes four inputs:<\/p>\n