{"id":33332,"date":"2026-05-01T21:34:53","date_gmt":"2026-05-01T19:34:53","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=33332"},"modified":"2026-07-30T08:01:42","modified_gmt":"2026-07-30T06:01:42","slug":"custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/","title":{"rendered":"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 7 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<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs<\/span><\/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

    Domain-specific widgets as first-class building blocks for the language model.<\/em><\/p>\n

    As soon as domain-specific concepts come into play, A2UI's Basic Catalog rarely suffices: a flight booking, a boarding pass, or a bonus program quickly look arbitrary as generic cards and lists. With Custom Catalogs<\/em>, A2UI therefore provides a clear mechanism to make your own domain-appropriate components and functions available to the language model \u2013 without sacrificing the lean, declarative character of the protocol.<\/p>\n

    This third and final part of the series shows how to define such Custom Catalogs in Angular, register them with the renderer, and integrate them with the CopilotKit integration introduced in the second part.<\/p>\n

    \ud83d\udcc2 Source Code<\/a> (see branch copilotkit<\/code>; the standalone renderer example can be found in the folder projects\/a2ui-demo<\/code>)<\/p>\n

    What Are Custom Catalogs in A2UI?<\/h2>\n

    A Custom Catalog<\/em> extends A2UI with your own, domain-driven components and functions that the language model may reference like any other component. Custom Catalogs often represent a superset of the Basic Catalog, so that in addition to your own building blocks they also include the well-known general-purpose UI building blocks. From the renderer's perspective, processing remains the same; the LLM merely receives a larger toolbox.<\/p>\n

    In what follows, we extend the passenger card introduced in the first part with our own MilesProgress<\/code> component, which visualizes the progress to the next bonus tier:<\/p>\n

    \"Custom<\/p>\n

    Creating Your Own Components for the Custom Catalog<\/h2>\n

    At its core, an A2UI component in Angular is just a regular Angular component. However, it receives the inputs that the agent transmits via A2UI through a defined Context<\/em> object. The following listing shows the definition of such a context for our MilesProgress<\/code> component. The passenger<\/code> property is declared as a BoundProperty<\/code>: it can hold either concrete data or represent a binding to the data model:<\/p>\n

    import type { BoundProperty } from '@a2ui\/angular\/v0_9';\n\nexport interface MilesProgressContext {\n  passenger: BoundProperty<Passenger>;\n}<\/code><\/pre>\n
    The corresponding component receives this context via the props<\/code> InputSignal<\/code>:<\/p>\n
    @Component({\n  selector: 'app-miles-progress',\n  changeDetection: ChangeDetectionStrategy.OnPush,\n  imports: [DecimalPipe],\n  template: `\n    <section class="miles-progress">\n      <p class="eyebrow">Miles Progress<\/p>\n      <p class="current">{{ passenger().bonusMiles | number }}<\/p>\n      <p class="remaining">\n        {{ remainingMiles() | number }} miles to {{ nextThreshold() | number }}\n      <\/p>\n      <div aria-hidden="true" class="track">\n        <div class="fill" [style.width.%]="progressPercent()"><\/div>\n      <\/div>\n    <\/section>\n  `,\n  styleUrl: '.\/miles-progress.css',\n})\nexport class MilesProgress {\n  readonly props = input<MilesProgressContext>(initialContext);\n  readonly surfaceId = input.required<string>();\n  readonly componentId = input.required<string>();\n  readonly dataContextPath = input('\/');\n\n  protected readonly passenger = computed(() => this.props().passenger.value());\n\n  protected readonly nextThreshold = computed(() =>\n    calcNextThreshold(this.passenger().bonusMiles),\n  );\n\n  protected readonly remainingMiles = computed(() =>\n    calcRemainingMiles(this.nextThreshold(), this.passenger().bonusMiles),\n  );\n\n  protected readonly progressPercent = computed(() =>\n    calcProgressPercent(this.nextThreshold(), this.passenger().bonusMiles),\n  );\n}<\/code><\/pre>\n
    Besides props<\/code>, the renderer sets three further inputs when it creates the component dynamically: surfaceId<\/code> names the surface the component belongs to, componentId<\/code> identifies it within that surface, and dataContextPath<\/code> provides the base path in the data model against which relative bindings are resolved. Our MilesProgress<\/code> component does not need this information; it becomes interesting for widgets that write to the data model themselves or trigger actions.<\/p>\n
    Currently, there is no dedicated interface for this set of inputs.<\/p>\n
    The MilesProgress<\/code> component shown reads the current bonus miles from the context and uses a computed signal to calculate the number of miles still needed to reach the next bonus tier. It also displays a progress indicator for that goal.<\/p>\n
    So that the renderer knows the MilesProgress<\/code> component and can instantiate it correctly, a description of its inputs in the form of a schema is also required. The renderer from the A2UI team uses the popular library Zod<\/a> for this:<\/p>\n
    import type { AngularComponentImplementation } from '@a2ui\/angular\/v0_9';\nimport { z } from 'zod\/v3';\n\n[...]\n\nconst passengerSchema = z.object({\n  id: z.number(),\n  firstName: z.string(),\n  lastName: z.string(),\n  bonusMiles: z.number(),\n});\n\nconst milesProgressSchema = z\n  .object({\n    passenger: binding(passengerSchema).optional(),\n  })\n  .strict();\n\nexport const milesProgressEntry = {\n  name: 'MilesProgress',\n  component: MilesProgress,\n  schema: milesProgressSchema as unknown,\n} as unknown as AngularComponentImplementation;\n\/\/ ^^^ Cast works around a typing issue in the current version<\/code><\/pre>\n
    The schema specifies that the passenger<\/code> property can be passed either as an object (passengerSchema<\/code>) or as a data binding with a path<\/code> property. The constant milesProgressEntry<\/code> bundles the component's name and implementation as well as the schema into a single unit that the catalog can later include.<\/p>\n
    Since every property may take either a concrete value or a data binding, the example project ships a small helper function binding<\/code> that pairs a value schema with the alternative of a path<\/code> binding:<\/p>\n
    export function binding<T extends z.ZodTypeAny>(schema: T) {\n  return z.union([schema, z.object({ path: z.string() }).strict()]);\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 cleanly into larger architectures:
    \nIn my book Agentic UI with Angular, I cover exactly these patterns and trade-offs in depth.<\/p>\n
    \"Cover<\/a><\/p>\n
    Learn more about the eBook \u2192<\/a>\n<\/div>\n<\/p>\n
    Your Own Functions for the Custom Catalog<\/h2>\n
    In addition to components, a Custom Catalog can also provide its own functions. These complement the standard functions included in the Basic Catalog, such as formatNumber<\/code> and formatDate<\/code>. The following listing shows a small helper function formatId<\/code>, which converts a numeric ID into a readable string like P-0042<\/code>. The factory createFunctionImplementation<\/code> from @a2ui\/web_core<\/code> takes the metadata \u2013 name, return type, and a Zod schema for the expected arguments \u2013 as well as the actual implementation:<\/p>\n
    import {\n  createFunctionImplementation,\n  type FunctionImplementation,\n} from '@a2ui\/web_core\/v0_9';\nimport { z } from 'zod\/v3';\n\nconst formatIdSchema = z\n  .object({\n    value: z.number(),\n  })\n  .strict();\n\nexport const formatIdImplementation = createFunctionImplementation(\n  {\n    name: 'formatId',\n    returnType: 'string',\n    schema: formatIdSchema as unknown as FunctionImplementation['schema'],\n  },\n  ({ value }) => {\n    const normalizedValue = Math.max(0, Math.trunc(value));\n\n    return `P-${String(normalizedValue).padStart(4, '0')}`;\n  },\n);<\/code><\/pre>\n
    With components and functions, the two central building blocks of a Custom Catalog are defined. As the next step, we need to make the catalog available to the renderer.<\/p>\n
    Registering a Custom Catalog with the A2UI Renderer<\/h2>\n
    A Custom Catalog is an instance of BasicCatalogBase<\/code> that receives a unique id, the list of additional components, and a list of functions in its constructor:<\/p>\n
    import { BASIC_FUNCTIONS, BasicCatalogBase } from '@a2ui\/angular\/v0_9';\n\nimport { formatIdImplementation } from '.\/format-id';\nimport { milesProgressEntry } from '.\/miles-progress';\n\nexport const customCatalog = new BasicCatalogBase({\n  id: 'https:\/\/example.com\/catalogs\/flights42-a2ui-demo',\n  extraComponents: [milesProgressEntry],\n  functions: [...BASIC_FUNCTIONS, formatIdImplementation],\n});<\/code><\/pre>\n
    Unfortunately, the API behaves somewhat asymmetrically in the version discussed here: extraComponents<\/code> complements the standard components, whereas functions<\/code> replaces the standard functions, which is why BASIC_FUNCTIONS<\/code> has to be spread in by hand.<\/p>\n
    So that the renderer uses the new catalog, the instance just needs to be referenced in the configuration \u2013 a dedicated Angular service is not required for this:<\/p>\n
    import {\n  A2UI_RENDERER_CONFIG,\n  A2uiRendererService,\n  provideMarkdownRenderer,\n} from '@a2ui\/angular\/v0_9';\nimport {\n  ApplicationConfig,\n  provideBrowserGlobalErrorListeners,\n} from '@angular\/core';\nimport { marked } from 'marked';\n\nimport { customCatalog } from '.\/custom-catalog\/custom-catalog';\n\nexport const appConfig: ApplicationConfig = {\n  providers: [\n    provideBrowserGlobalErrorListeners(),\n    {\n      provide: A2UI_RENDERER_CONFIG,\n      useValue: {\n        catalogs: [customCatalog],\n      },\n    },\n    provideMarkdownRenderer(async (markdown) =>\n      marked.parse(String(markdown ?? '')),\n    ),\n    A2uiRendererService,\n  ],\n};<\/code><\/pre>\n
    Once the catalog is registered, the example application can use the MilesProgress<\/code> component like any other component in an A2UI message. The following listing shows an excerpt of an updateComponents<\/code> message in which the MilesProgress<\/code> component is displayed alongside the existing passenger card:<\/p>\n
    updateComponents: {\n  surfaceId,\n  components: [\n    {\n      id: 'root',\n      component: 'Column',\n      children: ['passenger-card', 'miles-progress'],\n    },\n    [...]\n    {\n      id: 'miles-progress',\n      component: 'MilesProgress',\n      passenger: { path: '\/passenger' },\n    },\n  ],\n}<\/code><\/pre>\n
    Wiring Custom Components into the CopilotKit Integration<\/h2>\n
    So far we've registered Custom Components for the standalone A2UI renderer. In combination with the CopilotKit integration introduced in the second part, the approach looks similar but somewhat more convenient: in the folder util-copilotkit<\/code>, the example project provides its own helper functions that encapsulate both the component description and its registration. How these helpers are built internally is shown in the section "Under the Hood: The Schema Helpers in Detail" at the end of this article.<\/p>\n
    So that the A2UI renderer in the sidecar can show not only the components of the Basic Catalog but also your own widgets, Custom Components can be added. The example project used here contains a TicketWidget<\/code> that represents a boarding pass:<\/p>\n
    \"Custom<\/p>\n
    The helper function used here, createCustomComponent<\/code>, takes the name, the description, the component implementation, and a Zod schema that describes the component's properties:<\/p>\n
    import { z } from 'zod\/v3';\n\nimport {\n  binding,\n  createCustomComponent,\n} from '..\/..\/..\/shared\/util-copilotkit\/a2ui\/a2ui-schema';\nimport { A2uiCustomCatalogComponent } from '..\/..\/..\/shared\/util-copilotkit\/a2ui\/types';\nimport { TicketWidget } from '.\/ticket\/ticket-widget';\n\nexport const ticketWidgetEntry = createCustomComponent({\n  name: 'TicketWidget',\n  description: 'A boarding-pass-style widget ...',\n  component: TicketWidget,\n  schema: z\n    .object({\n      ticketId: binding(z.union([z.string(), z.number()])),\n      from: binding(z.string()),\n      to: binding(z.string()),\n      date: binding(z.string()),\n      delay: binding(z.number()).optional(),\n    })\n    .strict(),\n});\n\nexport const ticketingExtraComponents: A2uiCustomCatalogComponent[] = [\n  ticketWidgetEntry,\n];<\/code><\/pre>\n
    The helper function binding<\/code> corresponds to the variant shown earlier: it marks those fields that the LLM may either set directly or wire to values from the data model via a path<\/code> binding. In addition, createCustomComponent<\/code> uses its type parameters to ensure that the props<\/code> signal of the given component matches the schema.<\/p>\n
    By the way, it's worth taking a look at the full description<\/code> in the example project: it not only describes what the widget displays, but also gives the language model clear usage rules \u2013 for instance, that it should only use the TicketWidget<\/code> when explicitly asked, and at most once per request. The description thus becomes a building block of the prompt.<\/p>\n
    The helper function createCustomCatalog<\/code> bundles the components and the catalog id into a catalog descriptor:<\/p>\n
    import { createCustomCatalog } from '..\/..\/..\/shared\/util-copilotkit\/a2ui\/types';\nimport { ticketingExtraComponents } from '.\/ticketing-extra-components';\n\nexport const customCatalog = createCustomCatalog({\n  id: 'https:\/\/example.com\/catalogs\/flights42-a2ui-demo',\n  components: ticketingExtraComponents,\n});<\/code><\/pre>\n
    As the id, the example project assigns \u2013 as is customary for A2UI catalogs \u2013 a URL from its own domain in order to guarantee uniqueness. This id is more than just a label: the renderer looks up the catalog by its id, and the agent has to use exactly this id in its createSurface<\/code> operations. To make this work, the client transmits the id together with the catalog description to the agent; how it makes its way into the system prompt there is shown in the next sections.<\/p>\n
    For registration, the function provideA2uiCatalog<\/code> known from the second part is sufficient, which now takes the catalog descriptor:<\/p>\n
    import { provideMarkdownRenderer } from '@a2ui\/angular\/v0_9';\nimport { provideCopilotKit } from '@copilotkit\/angular';\nimport { marked } from 'marked';\n\nimport { a2uiActivityRendererConfig } from '.\/domains\/shared\/util-copilotkit\/a2ui\/a2ui-activity-renderer';\nimport { provideA2uiCatalog } from '.\/domains\/shared\/util-copilotkit\/a2ui\/provide-a2ui-catalog';\nimport { customCatalog } from '.\/domains\/ticketing\/ai\/custom-catalog\/catalog';\n\n[...]\n\nexport const appConfig: ApplicationConfig = {\n  providers: [\n    [...]\n    provideCopilotKit({\n      renderActivityMessages: [a2uiActivityRendererConfig],\n    }),\n    provideA2uiCatalog(customCatalog),\n    provideMarkdownRenderer(async (markdown) =>\n      marked.parse(String(markdown ?? '')),\n    ),\n  ],\n};<\/code><\/pre>\n
    Without arguments, provideA2uiCatalog<\/code> merely registers the Basic Catalog. Given a descriptor, the function extends this catalog with the provided components and functions:<\/p>\n
    export const A2UI_CUSTOM_CATALOG = new InjectionToken<A2uiCustomCatalog>(\n  'A2UI_CUSTOM_CATALOG',\n);\n\nexport function provideA2uiCatalog(\n  catalog?: A2uiCustomCatalog,\n  options?: ProvideA2uiCatalogOptions,\n): EnvironmentProviders {\n  if (!catalog) {\n    return makeEnvironmentProviders([\n      {\n        provide: A2UI_RENDERER_CONFIG,\n        useFactory: (): RendererConfiguration => ({\n          catalogs: [inject(BasicCatalog)],\n        }),\n      },\n      A2uiRendererService,\n    ]);\n  }\n\n  const { sendCatalogDescription = true } = options ?? {};\n\n  const rendererCatalog = new BasicCatalogBase({\n    id: catalog.id,\n    extraComponents: catalog.components.map(toAngularComponentImplementation),\n    functions: [\n      ...BASIC_FUNCTIONS,\n      ...(catalog.functions ?? []).map(toFunctionImplementation),\n    ],\n  });\n\n  const storedCatalog: A2uiCustomCatalog = sendCatalogDescription\n    ? catalog\n    : { id: catalog.id, components: [] };\n\n  return makeEnvironmentProviders([\n    { provide: A2UI_CUSTOM_CATALOG, useValue: storedCatalog },\n    {\n      provide: A2UI_RENDERER_CONFIG,\n      useValue: { catalogs: [rendererCatalog] },\n    },\n    A2uiRendererService,\n  ]);\n}<\/code><\/pre>\n
    The local helpers toAngularComponentImplementation<\/code> and toFunctionImplementation<\/code> are plain remappings of the descriptor entries onto the renderer structures shown at the beginning; their details can be found in the source code. The function also takes care of merging in BASIC_FUNCTIONS<\/code> \u2013 the asymmetry mentioned earlier thus remains an implementation detail. In addition, it stores the descriptor in the injection token A2UI_CUSTOM_CATALOG<\/code>; the next section shows the role this plays. The option sendCatalogDescription<\/code> determines whether a description of the entire catalog or only its id is sent to the server.<\/p>\n
    The Activity Renderer introduced in the second part remains untouched by all of this: it still forwards the received A2UI operations to the A2uiRendererService<\/code>, which resolves the Custom Components via the registered catalog.<\/p>\n
    Telling the Agent About Custom Components<\/h2>\n
    The renderer can now display the TicketWidget<\/code> \u2013 but how does the language model know that this component exists in the first place? This task is handled by the glue function initAgentStore<\/code> introduced in the second part: when registering an agent, it reads the descriptor stored at the injection token A2UI_CUSTOM_CATALOG<\/code> and registers it as a context entry for that agent (abridged):<\/p>\n
    import { type Context } from '@ag-ui\/core';\nimport { inject } from '@angular\/core';\nimport { connectAgentContext } from '@copilotkit\/angular';\n\nimport {\n  catalogIdToContextEntry,\n  catalogToContextEntry,\n} from '.\/a2ui\/catalog-context';\nimport { A2UI_CUSTOM_CATALOG } from '.\/a2ui\/provide-a2ui-catalog';\n\n[...]\n\nexport function initAgentStore(config: InitAgentStoreConfig): void {\n  [...]\n\n  connectCatalogContext(config.agentId, config.catalogIdOnly ?? false);\n\n  [...]\n}\n\nfunction connectCatalogContext(agentId: string, idOnly: boolean): void {\n  const catalog = inject(A2UI_CUSTOM_CATALOG, { optional: true });\n  if (!catalog) {\n    return;\n  }\n\n  const entry = idOnly\n    ? catalogIdToContextEntry(catalog.id)\n    : catalogToContextEntry(catalog);\n\n  connectAgentContext(() => ({ ...entry, agentIds: [agentId] }) as Context);\n}<\/code><\/pre>\n
    Context entries are a generic mechanism provided by AG-UI for passing additional information to the agent. The function connectAgentContext<\/code> from @copilotkit\/angular<\/code> registers a factory with the CopilotKit runtime, whose result flows into the context when the requests are assembled. The property agentIds<\/code> restricts the entry to the agent just registered \u2013 in an application with several agents, each one thus receives exactly its own catalog entry. Since the catalog remains unchanged at runtime, it is serialized once during initialization.<\/p>\n
    The individual agent stores therefore get by without any catalog knowledge: the function injectTicketingAgentStore<\/code> shown in the second part remains unchanged; the catalog flows in automatically as soon as provideA2uiCatalog<\/code> has stored it at the injection token. For agents that don't need any component descriptions but merely have to reference the catalog id, initAgentStore<\/code> additionally offers the option catalogIdOnly: true<\/code>.<\/p>\n
    The serialization is handled by the helper function catalogToContextEntry<\/code>: it converts the catalog id, the names and descriptions of the Custom Components, and \u2013 with the help of zodToJsonSchema<\/code> \u2013 their schemas into a context entry. Its implementation can also be found in the section at the end of this article.<\/p>\n
    The Server Perspective: Using the Custom Catalog from Context<\/h2>\n
    On the server side, the agent has to evaluate the received context entry again. In the example project, this task is handled by the function addCustomCatalogInstructions<\/code> from the folder libs\/ag-ui-server<\/code>. The Mastra agent used here wires it directly into its instructions<\/code>:<\/p>\n
    export const ticketingAgent = new Agent({\n  id: 'ticketingAgent',\n  name: 'Flight42 Ticketing Assistant',\n  instructions: addCustomCatalogInstructions({\n    systemInstructions: ticketingAgentPrompt,\n  }),\n  [...]\n});<\/code><\/pre>\n
    Noteworthy here is the signature of ticketingAgentPrompt<\/code>: the system prompt is no longer a static string but a factory that takes the catalog id and weaves it into the instructions \u2013 for instance where the prompt prescribes the structure of the createSurface<\/code> operations:<\/p>\n
    export function ticketingAgentPrompt(catalogId: string): string {\n  return `\n[...]\n- renderA2uiTool expects { messages: A2uiMessage[] } \u2014 one self-contained A2UI\n  v0.9 surface that MUST contain:\n  - one createSurface message with a fresh surfaceId and catalogId\n    "${catalogId}";\n[...]\n`;\n}<\/code><\/pre>\n
    Behind the call to addCustomCatalogInstructions<\/code> sits an instructions<\/code> factory that extracts the catalog id from the runtime context, builds the base prompt with it, and appends the component description as an additional section (abridged):<\/p>\n
    import {\n  A2UI_DEFAULT_CATALOG_ID,\n  catalogToPromptSection,\n  extractCatalogId,\n} from '.\/catalog-to-prompt.js';\n\n[...]\n\nexport interface AddCustomCatalogInstructionsOptions {\n  \/** Builds the system prompt for the catalog id the client registered. *\/\n  systemInstructions: (catalogId: string) => string;\n  [...]\n}\n\nexport function addCustomCatalogInstructions(\n  options: AddCustomCatalogInstructionsOptions,\n): (params: InstructionsParams) => string {\n  const { systemInstructions } = options;\n\n  return ({ requestContext }) => {\n    const agUi = requestContext.get('ag-ui') as AgUiRuntimeContext | undefined;\n    const catalogId =\n      extractCatalogId(agUi?.context) ?? A2UI_DEFAULT_CATALOG_ID;\n    const catalogSection = catalogToPromptSection(agUi?.context);\n    const baseInstructions = systemInstructions(catalogId);\n\n    return catalogSection\n      ? `${baseInstructions}\\n\\n${catalogSection}`\n      : baseInstructions;\n  };\n}<\/code><\/pre>\n
    The context entries transmitted by AG-UI are available under the key ag-ui<\/code> in Mastra's runtime context. The helper function extractCatalogId<\/code> reads the id of the client-side registered catalog from it; if the client does not announce a Custom Catalog, A2UI_DEFAULT_CATALOG_ID<\/code> kicks in as a fallback with the id of the Basic Catalog. The helper function catalogToPromptSection<\/code> looks through the same context entries for the entry with the description A2UI Custom Catalog<\/code>, parses the serialized catalog definition, and turns it into a prompt section. This section lists the available Custom Components including their descriptions and derives simple example props from the JSON schemas that the model can orient itself on.<\/p>\n
    This closes the loop: the client describes its Custom Components together with the catalog id, the agent takes both into the prompt, the language model references id and components in its A2UI messages, and the renderer displays them via the registered catalog.<\/p>\n
    Security Aspect: sendCatalogDescription<\/code> and Prompt Injection<\/h2>\n
    By default, the solution shown transmits the textual descriptions and schemas of the components to the agent, which embeds them into the system prompt. This approach is very convenient for development, but in production it can be abused for prompt injection. In such an attack, an attacker injects malicious instructions into the system prompt and thereby tricks the language model into performing unintended actions.<\/p>\n
    Therefore, in production it is advisable to set the sendCatalogDescription<\/code> option of provideA2uiCatalog<\/code> to false<\/code>:<\/p>\n
    provideA2uiCatalog(customCatalog, { sendCatalogDescription: false }),<\/code><\/pre>\n
    In this case, the client keeps the full catalog definition for local rendering only; as a context entry it transmits merely the catalog id, which the agent needs for its createSurface<\/code> operations anyway. The agent instead obtains the catalog's schema based on this id from a trusted registry \u2013 for example, via an internal API or database \u2013 validating the id against a list of approved catalogs in the process.<\/p>\n
    Under the Hood: The Schema Helpers in Detail<\/h2>\n
    To conclude, it's worth taking a look at the implementation of those helper functions that take care of the Custom Catalog's schema on the client side. Anyone who simply adopts them from the example project can safely skip this section; anyone who wants to adapt them to their own project will find the central building blocks here.<\/p>\n
    The implementation of createCustomComponent<\/code> is deliberately plain:<\/p>\n
    export interface CustomCatalogEntry<\n  TName extends string = string,\n  TSchema extends z.ZodObject<z.ZodRawShape> = z.ZodObject<z.ZodRawShape>,\n> {\n  name: TName;\n  description: string;\n  schema: TSchema;\n  component: Type<{\n    props: Signal<ContextFromSchema<TSchema>>;\n  }>;\n}\n\nexport function createCustomComponent<\n  const TName extends string,\n  const TSchema extends z.ZodObject<z.ZodRawShape>,\n>(\n  entry: CustomCatalogEntry<TName, TSchema>,\n): CustomCatalogEntry<TName, TSchema> {\n  return entry;\n}<\/code><\/pre>\n
    The function returns the given entry unchanged \u2013 its value lies in the type checking: the mapped type ContextFromSchema<\/code> derives from the Zod schema the context type that the component has to accept via its props<\/code> signal; each property is expected as a BoundProperty<\/code>. If the schema does not match the component, compilation already fails.<\/p>\n
    createCustomCatalog<\/code> is likewise a pure typing helper that returns the given descriptor unchanged. Besides the id, the descriptor comprises the components as well as optional functions:<\/p>\n
    export interface A2uiCustomCatalog {\n  id: string;\n  components: A2uiCustomCatalogComponent[];\n  functions?: A2uiCustomCatalogFunction[];\n}<\/code><\/pre>\n
    Finally, the function catalogToContextEntry<\/code> serializes this descriptor for transmission to the agent:<\/p>\n
    import { type Context } from '@ag-ui\/core';\nimport { zodToJsonSchema } from 'zod-to-json-schema';\n\nimport { type A2uiCustomCatalog } from '.\/types';\n\nexport const A2UI_CATALOG_CONTEXT_DESCRIPTION = 'A2UI Custom Catalog';\n\nexport function catalogToContextEntry(catalog: A2uiCustomCatalog): Context {\n  const components = Object.fromEntries(\n    catalog.components.map((component) => [\n      component.name,\n      {\n        description: component.description,\n        schema: zodToJsonSchema(component.schema, { $refStrategy: 'none' }),\n      },\n    ]),\n  );\n\n  return {\n    description: A2UI_CATALOG_CONTEXT_DESCRIPTION,\n    value: JSON.stringify({ catalogId: catalog.id, components }),\n  };\n}<\/code><\/pre>\n
    The option $refStrategy: 'none'<\/code> keeps the generated JSON schemas free of $ref<\/code> references, so that the server side can process them further without additional resolution. The constant A2UI_CATALOG_CONTEXT_DESCRIPTION<\/code> serves as the identifying marker: based on exactly this description, the server side identifies the catalog entry among the transmitted context entries.<\/p>\n
    It's worth noting that the function also yields an entry for a catalog without components: this way the catalog id reaches the server in any case \u2013 for instance when sendCatalogDescription: false<\/code> withholds the descriptions. For agents that only need the id in the first place, the example project additionally offers the short form catalogIdToContextEntry(catalogId)<\/code>, which initAgentStore<\/code> uses when the option catalogIdOnly: true<\/code> is set.<\/p>\n
    Summary<\/h2>\n
    Custom Catalogs extend A2UI in a targeted way with your own components and functions that the language model may use like any other building block. This makes it possible to translate generic responses into domain-appropriate interfaces without losing the character of a lean, declarative protocol. Schema validation via Zod ensures clean contracts between agent and client, while the split into components and functions keeps the catalog flexible.<\/p>\n
    In combination with the CopilotKit integration, Custom Components can be described compactly with createCustomComponent<\/code> and wired in through a single call to provideA2uiCatalog<\/code>. The catalog description travels, together with the catalog id, to the agent as an AG-UI context entry; the agent weaves the id into its system prompt and uses it in its createSurface<\/code> operations from then on \u2013 the Activity Renderer from the second part remains unchanged in the process. Anyone planning the move to production should also consider the security aspect around sendCatalogDescription<\/code> and source catalog schemas from a trusted source.<\/p>\n
    Anyone who combines protocol, renderer, CopilotKit integration, and Custom Catalogs has a solid foundation to have language models deliver not just text but real UI responses \u2013 and in a way that fits their own application.<\/p>\n
    \n
    <\/p>\n
    Interested in production-ready Agentic UI architectures?<\/h3>\n
    In my workshop, we dig into AG-UI, A2UI, MCP Apps, HITL patterns, and modern Angular architectures for real-world agentic systems.<\/p>\n
    \"Workshop:<\/a><\/p>\n
    See all details \u2192<\/a>\n<\/div>\n<\/p>\n
    FAQ<\/h2>\n
    What is a Custom Catalog in A2UI?<\/h3>\n
    A Custom Catalog extends A2UI with your own, domain-driven components and functions. It often includes the Basic Catalog as a superset and additionally provides domain-specific building blocks to the language model, which the renderer processes like any other A2UI component.<\/p>\n
    How do you describe your own A2UI component?<\/h3>\n
    The implementation is a regular Angular component that receives its inputs via a Context<\/code> object. In addition to the component itself, a Zod schema is defined that describes the expected properties. Component, name, and schema are added together as an entry in the Custom Catalog \u2013 in the CopilotKit integration in a type-safe way via the helper function createCustomComponent<\/code>.<\/p>\n
    How do you register a Custom Catalog in Angular?<\/h3>\n
    For the standalone renderer, an instance of BasicCatalogBase<\/code> referenced in the A2UI_RENDERER_CONFIG<\/code> token is sufficient. In the CopilotKit integration, this is handled by the provideA2uiCatalog<\/code> function, to which a descriptor created with createCustomCatalog<\/code>, containing components and optional functions, can be passed directly.<\/p>\n
    How does the agent learn about the Custom Components?<\/h3>\n
    The glue function initAgentStore<\/code>, which registers the agent stores, reads the catalog stored at the token A2UI_CUSTOM_CATALOG<\/code>, serializes it with catalogToContextEntry<\/code>, and registers it via connectAgentContext<\/code> as an AG-UI context entry for the respective agent. On the server side, addCustomCatalogInstructions<\/code> extracts the catalog id, builds the system prompt with it, and appends the component descriptions along with example props derived from them.<\/p>\n
    What is sendCatalogDescription<\/code> for and when should you disable the option?<\/h3>\n
    By default (sendCatalogDescription: true<\/code>), the client transmits the component descriptions and schemas to the agent, which embeds them into the system prompt. That is very convenient, but it can lead to prompt injection. In production, it is therefore advisable to set the option to false<\/code>: the client then only transmits the catalog id, and the server obtains the schemas from a trusted registry.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This is post 7 of 10 in the series “Agentic UI with Angular” Understanding AG-UI: The Standard for Agentic User Interfaces AG-UI in Practice: The SDK for TypeScript AG-UI End to End: Connecting Server and Client Agentic UI with Angular, CopilotKit, and AG-UI A2UI: How AI Generates Dynamic UIs at Runtime Integrating A2UI with AG-UI […]<\/p>\n","protected":false},"author":25,"featured_media":33334,"comment_status":"open","ping_status":"open","sticky":true,"template":"","format":"standard","meta":{"_acf_changed":false,"_price":"","_stock":"","_tribe_ticket_header":"","_tribe_default_ticket_provider":"","_ticket_start_date":"","_ticket_end_date":"","_tribe_ticket_show_description":"","_tribe_ticket_show_not_going":false,"_tribe_ticket_use_global_stock":"","_tribe_ticket_global_stock_level":"","_global_stock_mode":"","_global_stock_cap":"","_tribe_rsvp_for_event":"","_tribe_ticket_going_count":"","_tribe_ticket_not_going_count":"","_tribe_tickets_list":"[]","_tribe_ticket_has_attendee_info_fields":false,"footnotes":""},"categories":[18],"tags":[],"class_list":["post-33332","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","post_series-agentic-angular"],"acf":[],"yoast_head":"\nCustom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects<\/title>\n<meta name=\"description\" content=\"How do you extend A2UI with your own domain-specific components? Using Angular as an example, this article shows how to define Custom Catalogs, secure them with Zod schemas, register them with the renderer, and wire them into the CopilotKit integration from the second part.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects\" \/>\n<meta property=\"og:description\" content=\"How do you extend A2UI with your own domain-specific components? Using Angular as an example, this article shows how to define Custom Catalogs, secure them with Zod schemas, register them with the renderer, and wire them into the CopilotKit integration from the second part.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\" \/>\n<meta property=\"og:site_name\" content=\"ANGULARarchitects\" \/>\n<meta property=\"article:published_time\" content=\"2026-05-01T19:34:53+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-30T06:01:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/series-1024x536.png\" \/>\n<meta name=\"author\" content=\"Manfred Steyer\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/series-1024x536.png\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Manfred Steyer\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\"},\"author\":{\"name\":\"Manfred Steyer\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a\"},\"headline\":\"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs\",\"datePublished\":\"2026-05-01T19:34:53+00:00\",\"dateModified\":\"2026-07-30T06:01:42+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\"},\"wordCount\":2778,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\",\"url\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\",\"name\":\"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects\",\"isPartOf\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg\",\"datePublished\":\"2026-05-01T19:34:53+00:00\",\"dateModified\":\"2026-07-30T06:01:42+00:00\",\"description\":\"How do you extend A2UI with your own domain-specific components? Using Angular as an example, this article shows how to define Custom Catalogs, secure them with Zod schemas, register them with the renderer, and wire them into the CopilotKit integration from the second part.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage\",\"url\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg\",\"contentUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg\",\"width\":1000,\"height\":667},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.angulararchitects.io\/en\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#website\",\"url\":\"https:\/\/www.angulararchitects.io\/en\/\",\"name\":\"ANGULARarchitects\",\"description\":\"AngularArchitects.io\",\"publisher\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.angulararchitects.io\/en\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#organization\",\"name\":\"ANGULARarchitects\",\"alternateName\":\"SOFTWAREarchitects\",\"url\":\"https:\/\/www.angulararchitects.io\/en\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg\",\"contentUrl\":\"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg\",\"width\":644,\"height\":216,\"caption\":\"ANGULARarchitects\"},\"image\":{\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/github.com\/angular-architects\",\"https:\/\/www.linkedin.com\/company\/angular-architects\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a\",\"name\":\"Manfred Steyer\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g\",\"caption\":\"Manfred Steyer\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects","description":"How do you extend A2UI with your own domain-specific components? Using Angular as an example, this article shows how to define Custom Catalogs, secure them with Zod schemas, register them with the renderer, and wire them into the CopilotKit integration from the second part.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/","og_locale":"en_US","og_type":"article","og_title":"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects","og_description":"How do you extend A2UI with your own domain-specific components? Using Angular as an example, this article shows how to define Custom Catalogs, secure them with Zod schemas, register them with the renderer, and wire them into the CopilotKit integration from the second part.","og_url":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/","og_site_name":"ANGULARarchitects","article_published_time":"2026-05-01T19:34:53+00:00","article_modified_time":"2026-07-30T06:01:42+00:00","og_image":[{"url":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/series-1024x536.png","type":"","width":"","height":""}],"author":"Manfred Steyer","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/series-1024x536.png","twitter_misc":{"Written by":"Manfred Steyer","Est. reading time":"20 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#article","isPartOf":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/"},"author":{"name":"Manfred Steyer","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a"},"headline":"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs","datePublished":"2026-05-01T19:34:53+00:00","dateModified":"2026-07-30T06:01:42+00:00","mainEntityOfPage":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/"},"wordCount":2778,"commentCount":0,"publisher":{"@id":"https:\/\/www.angulararchitects.io\/en\/#organization"},"image":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage"},"thumbnailUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg","inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/","url":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/","name":"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs - ANGULARarchitects","isPartOf":{"@id":"https:\/\/www.angulararchitects.io\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage"},"image":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage"},"thumbnailUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg","datePublished":"2026-05-01T19:34:53+00:00","dateModified":"2026-07-30T06:01:42+00:00","description":"How do you extend A2UI with your own domain-specific components? Using Angular as an example, this article shows how to define Custom Catalogs, secure them with Zod schemas, register them with the renderer, and wire them into the CopilotKit integration from the second part.","breadcrumb":{"@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#primaryimage","url":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg","contentUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2026\/05\/shutterstock_2383749427.jpg","width":1000,"height":667},{"@type":"BreadcrumbList","@id":"https:\/\/www.angulararchitects.io\/en\/blog\/custom-catalogs-in-a2ui-your-own-components-for-ai-generated-uis\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.angulararchitects.io\/en\/"},{"@type":"ListItem","position":2,"name":"Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs"}]},{"@type":"WebSite","@id":"https:\/\/www.angulararchitects.io\/en\/#website","url":"https:\/\/www.angulararchitects.io\/en\/","name":"ANGULARarchitects","description":"AngularArchitects.io","publisher":{"@id":"https:\/\/www.angulararchitects.io\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.angulararchitects.io\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.angulararchitects.io\/en\/#organization","name":"ANGULARarchitects","alternateName":"SOFTWAREarchitects","url":"https:\/\/www.angulararchitects.io\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/","url":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg","contentUrl":"https:\/\/www.angulararchitects.io\/wp-content\/uploads\/2023\/07\/AA-Logo-RGB-horizontal-inside-knowledge-black.svg","width":644,"height":216,"caption":"ANGULARarchitects"},"image":{"@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/github.com\/angular-architects","https:\/\/www.linkedin.com\/company\/angular-architects\/"]},{"@type":"Person","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/f3de69c1e2bdb5ba04d8d2f5f998b81a","name":"Manfred Steyer","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.angulararchitects.io\/en\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/8778dfb353992fa3a0d909beee085a088891e5bfce65cdb3631801da527cf11b?s=96&d=mm&r=g","caption":"Manfred Steyer"}}]}},"_links":{"self":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts\/33332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/comments?post=33332"}],"version-history":[{"count":7,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts\/33332\/revisions"}],"predecessor-version":[{"id":34536,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/posts\/33332\/revisions\/34536"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/media\/33334"}],"wp:attachment":[{"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/media?parent=33332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/categories?post=33332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.angulararchitects.io\/en\/wp-json\/wp\/v2\/tags?post=33332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}