All

As I started running more agents across projects, reviewing their work became a bottleneck. Questions and proposals were spread across threads, each needing me to reconstruct the context before answering.

I built Input as a Codex plugin, then brought the same interface into ChatGPT. MCP lets agents send questions, options and visual proposals into a shared inbox. My response goes back to the originating conversation, and the agent can report what happened next.

I’ve been using it to guide its own development. That quickly made the follow-through as important as the decision: seeing how my feedback changed the work, without having to chase it across threads.

Most inputs need a short question and a few options. For visual decisions, I added a carousel so I can compare the actual alternatives rather than descriptions of them.

I can add feedback to an Input, then open its attached discussion to read agent replies and add my own. A comment can continue the conversation without resolving the card.

Activity keeps decisions alongside agent-reported progress and completed or failed outcomes. I can follow what the agent reports happened next without having to chase it across threads.

I built a native SwiftUI app so I could review agent work away from my desk. It uses the same backend as the web app, with native navigation, visual options and inline replies.

The focus was on making small decisions easy: scan the request, inspect an option and give direction. Goals give those individual inputs some longer-term context, with subgoals, linked decisions and an activity trail.

Using it on my phone also exposed interaction problems that weren’t obvious on desktop, particularly around selecting, scrolling and enlarging previews.

something here about it

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.

[Write-up / history of The Designers League]

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.

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.

FIG 02 / Selection and inspector

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.

FIG 04 / Validation state

FIG 05 / Successful retry

Something here about the interaction.

Keep it playful.

Soft light, warm tones.

5 selectedGroup

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.

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

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.

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