AI-Native Interfaces — Conversation Meets Visual

The Product Spectrum

Not every product needs to be fully agentic, and human-readable interfaces aren't going away just yet. But the design principles differ depending on where a product sits.

Traditional: the human is the direct consumer of data. The product renders information on screen and the human reads, interprets, acts. A static portfolio. A documentation site. Visual hierarchy, layout, whitespace — all designed for human eyeballs.

AI-native: the human interacts through an AI-powered interface, but the interface is still human-facing. The AI mediates the data — generating responses, surfacing relevant information, handling natural language — but the human sees the output and guides the conversation. Mosaic's web app is AI-native. A visitor types a question, Claude responds based on persona data, and the visitor reads the response. The AI mediates; the human is in the loop.

Agentic: the human provides intent. The agent decides what to read, what to ask, how to act — autonomously. The human may never see the raw data. They see the outcome. A recruiter's agent queries a candidate's Mosaic agent. No human reads the persona profile. Agent to agent, data to decision, human at the end for the final call.

Most products today are in the AI-native transition space. The visual surface is being augmented by conversation. A mature product likely operates across all three: a traditional layer for humans who want to browse, an AI-native layer for visitors who want to interact, an agentic layer for agents that need programmatic access.

The Portal Concept

A web page is flat. One-dimensional. Everything it has to say is rendered on the surface. You scan it, extract what you can, move on.

Adding a conversational agent woven into the content opens a portal to additional dimensions. The page still has its visual surface — the rendered content, the layout, the design. But now there's depth behind it. Ask a question and you go deeper than what's on the surface. The agent draws from the full content pool, reasons over it, and delivers something the page alone couldn't.

Conversation hooks are portal entry points. They signal to the visitor: there's more here than what you see. A case study page renders the project overview, but a hook like "How does the agent-as-CMS pattern work?" invites the visitor into a conversation that draws on the article explaining dual-voice architecture, the learnings from building edit flows, the technical details of operation-based mutations.

This isn't about chatbots bolted onto websites. A chat widget in the corner of a dashboard is the anti-pattern — it's a traditional interface with a chatbot added. The AI-native approach weaves conversation into the content itself. The two surfaces — visual and conversational — work together, each doing what it does best.

The Agent-UI Relationship

The relationship between agent and interface isn't fixed — it depends on the product and the intent.

In Mosaic, the agent controls the visual surface directly. The two-layer content system: pre-distilled visual sections generated at edit time, and a conversation-driven selection mechanism at chat time. The interviewer agent receives the list of available section IDs. When a visitor asks about projects, the agent responds conversationally and simultaneously selects the Projects section to reveal on the display. The surface accumulates — it never shows everything at once. It reveals itself progressively through dialogue. The agent is the picker, not the generator. Zero distillation cost per question. This fits Mosaic's nature as a personal identity product — the conversation shapes how the persona is revealed.

In Gramercy, the relationship is different. The site renders structured content — articles, case studies, pages — through familiar navigation and layouts. The agent doesn't control what's displayed. Instead, the agent provides the conversational depth behind the visual surface. The rendered page is the first dimension; the agent is the second. They coexist rather than one controlling the other.

The principle isn't "the agent must control the surface." It's "challenge every UI element and ask whether the agent should handle it." Sometimes the answer is yes — Mosaic's progressive reveal replaced a static profile layout. Sometimes the answer is no — Gramercy's article pages benefit from traditional rendering with conversational depth added. The design question is always: what does this specific product and intent require?

Challenging Traditional Patterns

The intent-driven thesis from Article 4 extends to interface design. Instead of presenting a dashboard with buttons, toggles, and menus, ask: what does the user want to do? If the answer is "update my bio," an agent that understands natural language and has edit tools is more capable than a form. If the answer is "explore this person's background," a conversation that progressively reveals content is more engaging than a static profile page.

This doesn't mean removing all familiar UI. Navigation still helps orientation. Pages still benefit from visual hierarchy. But every traditional UI element should earn its place. A toggle is a product decision — someone decided users need this view mode, designed it, built it, maintains it. A conversational request — "show me this differently" — scales with whatever the agent can reason about. No design, no build, no maintenance.

The practical expression: Mosaic has no admin dashboard. No CMS. Content management happens through natural language conversation. The owner says "add that I work with Python," the agent proposes the change, the owner approves, the agent executes. Want to preview? Ask. Want to undo? Say so. The agent replaces the CMS entirely.

Gramercy takes this further in a different direction. The site has familiar pages and navigation — that's what the content requires. But the conversational layer challenges the assumption that a visitor can only consume what's rendered. Every page becomes a starting point for deeper exploration. The interface finds its balance between what's familiar and what AI enables.

The Autonomous Loop and Serverless Reality

The typical approach to putting an AI behind a web interface is straightforward: an ephemeral worker or server component calls the Claude API, gets a response, returns it. The model answers a question and the frontend renders the answer.

Neo tested something fundamentally different with the Claude Agent SDK. The SDK introduces an autonomous loop — the agent calls tools, reads the results, reasons, decides what to do next, calls more tools — without a human approving each step. No confirmation gates. The agent reads a file, decides it needs another file, reads that, spots a pattern, searches for related code, synthesizes an answer. True autonomy: the agent determines the path.

This autonomy creates an infrastructure problem. A standard API call is stateless — request in, response out. An autonomous agent loop needs state: a filesystem to read from, a shell to execute in, a process that persists across multiple tool calls. Standard serverless can't provide this. The Agent SDK needs a container — a Cloudflare Sandbox instance where the agent can run its full loop.

The architecture: frontend on Vercel, agent execution on Cloudflare Sandbox, a worker orchestrating between them. Each request spins up a fresh, isolated container. But each container is also stateless across requests — the agent has zero memory of prior conversations. The solution is conversation history prepending: the frontend collects recent messages and sends them with each request. Simple, effective, and aligned with the ephemeral model that makes serverless cost-effective.

The NDJSON streaming protocol carries the agent's process back to the browser: text chunks, tool usage events, turn markers, usage metrics. The visitor watches the agent explore, reason, and respond — transparency that builds trust in the autonomous process.

The Thread

Interface design connects to everything else. The agent providing conversational depth uses the same intent-driven architecture from Article 4 — the voice and capabilities follow from what the visitor wants to do. The content it reasons over was authored using the content engineering principles from Article 2 — structured so any agent can work with it effectively. Via MCP (Article 3), external agents access the same structured content, consuming it however their client supports.

The evolution from Neo to Mosaic to Gramercy isn't a straight line from less to more agentic. It's an exploration of where autonomy fits and where familiar patterns still serve. Neo gave the agent full autonomy within a sandbox. Mosaic gave the agent control of the visual surface. Gramercy gives the agent conversational depth behind a browsable site. Each product found its own balance.

The question that drives the evolution: what can conversation do that screens alone cannot? The answer is dimensionality. Screens show what's there. Conversation reveals what's behind it.