UI

All entries · newest first

Glance

/

Glance

A shared space to keep up to date with everything using agents & codex

I built Glance with Codex and Sites to bring my calendar, inbox, AI headlines, open PRs, spending and parcels into one place. Each section gives me a short summary, with more detail and links to the original sources when I need them.

Simplifying the interface

The early version had draggable, resizable white containers. I stripped those back to stacked paragraphs, using serif headings and spacing to give the page structure. Detail popovers kept the overview short without losing the context behind each update.

Bringing it into chat

I added a read-only plugin connection so I could ask about the same briefing from ChatGPT. It reads saved updates rather than fetching every source again, so each section carries its own checked time and context.

Iterating through use

Most of the design work has been small changes against a working version: adjusting type, removing controls and checking how it feels on my phone. Mobile navigation and differences between the hosted site and app sidebar are still being worked through.

Exploring Cascade - an agent native html artifact editor.

/

Cascade

Cascade is an experiment in editing and reviewing interactive prototypes with agents. I wanted a place to return to generated interfaces, change specific parts and keep alternative directions.

Keeping it lightweight

I started with portable HTML artifacts, so each idea could be previewed and passed on without setting up a full application. The gallery makes those prototypes visible before opening them.

Cascade light-mode prototype gallery

FIG 01 / Prototype gallery


Editing and reviewing

The canvas combines direct controls with contextual feedback. Selecting an element exposes its appearance and layout; Review mode attaches comments to their target and version. This was the core exploration: making it easier to point at what should change.

Cascade light-mode selected heading with design inspector

FIG 02 / Selection and inspector

Cascade light-mode seeded review comment anchored to the Payment card

FIG 03 / Anchored demo feedback

Testing the interaction

I used a checkout example to explore validation, retry and success. Preview follows declared states, giving the interface behaviour to inspect as well as a layout.

These are seeded prototypes and simulated payments. The next thing to test is the complete loop from a comment to an agent’s change and a saved result.

Cascade light-mode simulated checkout validation error

FIG 04 / Validation state

Cascade light-mode simulated checkout success

FIG 05 / Successful retry

Generative UI Canvas

/

Gen

Working through the interface

I’ve been exploring a model-agnostic canvas, with the workspace itself as the thing that stays consistent. That leaves room to try different models without making each one a separate place to work.

The current frontend lets me zoom around the canvas, focus on an item and interact with example widgets, including a timer. For a portable demo, I used local examples so I could inspect the canvas interactions independently of live generation. That demo leaves out AI calls, Notion and backend storage.

I also tried bringing it into Figma as an interactive Code Layer. The import was blocked by the tool, so the working version is still the browser demo.

The open question is what makes these generated interfaces worth keeping and returning to. That’s what I want to explore beyond the initial moment of generating something.


Grouping & stacking items

/

Gen

Something here about the interaction.


White architectural stairs
Wooden chair in sunlight
Soft desert dunes
Keep it playful.
Soft light, warm tones.
5 selected

Input

/

Input

Input is an experiment in giving agents somewhere to ask for decisions. A thread can send a card with a proposal, options or an open question. I can take action, give direction or dismiss it, and the answer goes back to the conversation that asked.

Trying it on itself

I started with small test cards to check that choices and comments made the round trip. Then I used Input to guide its own development: asking the agent to feed me decisions about what to work on next, rather than managing everything through a parallel chat.

That made the response as important as the question. The agent needed to show that it had received my answer and record what happened next. Choosing a product direction also needed to stay separate from approving an implementation.

Using it across desktop and mobile led to smaller UI changes too: keeping the tabs accessible, matching the header to the page and asking for a quiet arrival sound without another visible control.

The next question is how other agents could use the same inbox. The current experiment has been dogfooded through ChatGPT.


Prototyping voice agents

/

Outverse

Our customer had high call volume, strict account verification, regional language needs, and an existing Talkdesk and Salesforce stack. We'd not yet branched our agent into Voice, so this was about quickly exploring how voice agents could/should work for Outverse.

The agent graph

In the interest of speed - we used ElevenLabs to power our prototype voice agents - it enabled me to get started immediately building out the agent graph and it's pathways.

DOES THIS SHOW

FIG 01 / GRAPH VIEW OF AGENT

Authentication - The agent authenticated callers by matching a name and ID against a mock Airtable DB via tool use. Verified callers could then ask their query and the agent would route depending on the intent.

General support - For general queries, the agent drew on an uploaded knowledge base of product docs to answer.

Invoice requests - Customers were often calling requesting invoices - whilst this was something they could self serve, we wanted to also equip the agent with the ability to look up the customers invoices, and if requested send it to them.

Downgrades/Cancellations - When the agent detected cancellation or downgrade intent, it routed to a retention pathway - letting the caller know it needed to transfer to a human, then handing off to Talkdesk.

Prototyping the interface

ElevenLabs powered the agent, but I wanted to explore how it would live inside Outverse. Their SDK @elevenlabs/react made this straightforward.

The sandbox let us start a call directly inside Outverse and talk to the voice agent in-browser. When the call ended, the API pulled the conversation into the history view — where the recording could be played back and the transcript, workflow events, routing decisions, and tool calls displayed inline. Full observability of every call, not just the audio.

FIG 02 / SURFACE FOR USERS TO START CALL / VIEW CALL HISTORY

DOES THIS SHOW

FIG 03 / A viewable call transcription

Using coding agents to iterate on the agents

ElevenLabs also has a CLI, which let me use Claude/Codex to pull my live agent config, simulate calls, and build a test-tweak-review loop programatically


Automating the demo pipeline

I built a Notion agent to automate the setup for new voice-agent demos. It used Firecrawl to pull details about a prospect company - their product, support docs, help center content - and synthesized that into a system instruction prompt.

Generative UI for a richer chat experience

/

Outverse

Outverse’s AI agents were resolving thousands of tickets across channels but the conversation data behind those resolutions was going underutilized.

Dashboards are great for high level metrics, but are rigid - conversational interfaces are great for queries that require flexibility in answers, but tiring to consume. Generative UI sits between the two : A richer experience that's easier to scan and angaging and flexible enough to assemble around whatever the user asks.

Prototype

I built the prototype in our internal design playground — a repo I created that mirrors our product surfaces using Next.js, ShadCN, and Tailwind. I used Chris Tate’s JSON Render as the foundation, which let the agent return structured UI (charts, metrics, drilldown tables) rather than just paragraphs. The frontend assembled those components dynamically from the agent’s JSON spec, making it feel like a product surface rather than a chatbot.

FIG 1 / WORKING PROTOTYPE USING OPENAI RESPONSES API & JSON RENDER

For data, I generated a realistic synthetic dataset - support conversations, CSAT scores, intents, channels, outcomes - so I could test whether the responses felt genuinely useful to a support operator.

MCP as an additional entrypoint

When it comes to being able to query your data, Its quickly becoming table stakes to allow your product to be queryable from other AI tools, think claude, co work, chatgpt, codex.

FIG 2 / PROTOTYPE MCP SERVER INSIDE OF CLAUDE

Agent native

Whilst I initially prototyped the VOC agent in our existing interface, I think soon most tools will look like users talking with agents that drive user interface. This was some exploration into how we could shift our interface to enable that!

FIG 3 / AGENT NATIVE UI ENTRYPOINT