← Selected Engineering Work

Embeddable AI product

AI assistants for business websites

An embeddable assistant platform that helps website visitors find information, explore products and complete guided tasks through interactive responses.

The public AI product catalogue showing available and planned business assistants
Public agent catalogue · product website

This embeddable assistant helps website visitors find information, compare products and complete guided tasks. Structured responses can display forms and other interactive content, with business actions restricted to capabilities supported by the application.

01 / The assistant

A conversation that can become a useful next step

The platform supports assistants for roles such as helping visitors and presenting products. Instead of limiting responses to prose, it can render different kinds of content and inputs as part of the conversation.

Assistants are packaged for embedding into third-party websites. The product combines a shared frontend with RAG-backed assistant behavior, structured responses and business-action contracts, so an interaction can progress across several steps as the visitor provides more information.

02 / Response rendering

Render structured responses with known components

I needed to turn changing assistant responses into a usable interface. Hardcoding every response as a page would not scale, while arbitrary generated HTML would give up control over behavior and accessibility.

I designed a typed renderer registry that maps structured assistant responses to known Angular components. I chose this approach to keep control of layout and interaction while allowing the assistant to select suitable content. TypeScript defines the frontend contracts; model responses still require runtime validation.

Each new response type requires a schema and a renderer. That adds implementation work, but gives the team control over layout, keyboard behavior and the actions a response can expose.

03 / Business actions

Keep proposed actions separate from execution

A plausible assistant response may suggest an unsupported operation, and a user may revise or cancel a decision. Conflating generated intent with an executable command would make business behavior unpredictable.

I worked with the backend on a defined set of business-action contracts. In the frontend, I kept proposed actions separate from execution and represented confirmation, cancellation, loading, errors and revision as explicit parts of the conversation.

Invalid model output, an unsupported action and a failed backend request require different responses. The UI must preserve enough context for the user to correct, retry or cancel the step.

04 / Embedding

Embed the assistant as a custom element

The assistant needs to run inside third-party websites that do not share its Angular architecture, routing or state. A direct dependency on those internals would make every integration a separate frontend project.

I packaged the assistant with Angular Elements and used Shadow DOM to isolate its markup and styles. This prevented host-page CSS selectors from changing the internal interface and kept component styles from leaking into the page. I exposed configuration, properties and events as the integration API.

The component carries its own styles instead of relying on the host website’s stylesheet. Host applications cannot customize its internal elements with ordinary CSS selectors; supported changes need to go through the component’s public API. This keeps the embedded interface consistent across different websites.

Evidence & further reading

Technical references