The End of Permanent UI

Agents that understand your data should generate interfaces on demand, not force you into pre-built dashboards. Here's how ephemeral UI works today.

The Dashboard Problem

You have 14 tabs open. Three are dashboards you built last quarter. One shows metrics nobody checks anymore. Another displays a project tracker that drifted from reality two sprints ago. The third is a settings page you'll visit once a year.

This is the dirty secret of internal tooling: most UI is built to last but used once. Teams spend weeks building admin panels, status pages, and reporting dashboards. They maintain them for months. Then requirements shift, data sources change, and the cycle starts over.

And every one of those dashboards is another repository to manage. Another codebase that agents need to navigate without accidentally editing the wrong one. Another branch to juggle when you're running parallel work — which, on a local machine, means one branch at a time unless you layer on worktrees, container-based dev environments, or multi-checkout tooling. You end up adding complexity on top of complexity to manage complexity. The tool you built for visibility becomes its own maintenance burden.

What if the interface only existed when you needed it?

Ephemeral UI: Interfaces That Appear and Disappear

Ephemeral UI is exactly what it sounds like: user interfaces generated on demand, used for a task, then gone. No repository. No dependency tree. No maintenance burden. An agent reads your data, understands what you need to see or do, generates a functional interface, and opens it in a native window. When you close the window, the interface ceases to exist.

This isn't theoretical. Google's A2UI protocol, CopilotKit, and Microsoft's AG-UI framework are all building production-ready generative UI systems. But most of these approaches still assume a traditional app architecture underneath — generating components within React or similar toolchains.

What if the entire application is ephemeral too?

Three Levels of Ephemeral UI

We built an ephemeral UI system inside HQ, Indigo's open-source framework for AI-orchestrated work. It operates at three distinct levels, each more powerful than the last.

Level 1: Ad-Hoc Generation

The simplest case. You need to see something, so you ask your agent to build it.

"Show me a dashboard of all projects with their completion status." The agent generates the UI, and a native desktop window opens with your dashboard already rendered. No browser tab to manage. No URL to copy-paste. You get a functional dashboard in seconds. When you're done, close the window. The generated code is cleaned up automatically.

This works because the agent already has access to your data. It knows your project structure, your file formats, your preferences. Under the hood, it generates vanilla HTML, CSS, and JavaScript — and a lightweight Tauri shell opens it as a native window. No browser required. The interface feels like a desktop app, but nothing was installed and nothing persists. Every internal tool you've ever built for "quick visibility" could have been this instead.

Level 2: Spec-Driven Generation

Ad-hoc works for one-off needs. But some interfaces you want repeatedly — the same project dashboard every Monday, the same metrics view before each standup. Re-describing it every time defeats the purpose.

Level 2 solves this with declarative specs: markdown files that describe what the UI should show, what data it reads, how interactions should work, and what the visual design looks like. The spec is knowledge, not code. It lives in your knowledge base alongside documentation and protocols.

In HQ, running /ui projects-dashboard reads two files: a runtime protocol (how to build any ephemeral UI) and a UI spec (what this specific dashboard should display). The agent generates a fresh interface from scratch every time — and it opens immediately in a native window. The spec describes data sources, visual components, and interactions — but contains zero JavaScript. An agent reading the spec and the protocol can generate a working dashboard without any prior context.

The spec is the product. The code is disposable.

This is a fundamental inversion. Traditional development treats code as the artifact and documentation as the afterthought. Ephemeral UI flips it: the spec is the artifact, the code is generated fresh each time. When data sources change, update the spec. When you want a different visualization, describe it. The next generation incorporates the changes automatically.

Level 3: Cross-Functional Intelligence

This is where ephemeral UI gets genuinely interesting — and where it diverges from every existing generative UI framework.

An agent that generates your interfaces also has context about your broader work: project statuses, communication patterns, team velocity, open decisions. It doesn't just render what you ask for. It can surface what you didn't know to ask for.

Imagine opening your Monday dashboard and seeing a section you never requested: a "Stalled Projects" view that cross-references project orchestration state with your last activity timestamps, highlighting three projects where no work has happened in 10 days. Or a "Decision Queue" panel that pulls unresolved questions from across your workspace and ranks them by downstream impact.

This is a natural consequence of the agent having access to your full workspace. It can incorporate cross-functional signals that a static dashboard could never surface — because a static dashboard was built once by a developer who couldn't anticipate every future need.

Level 3 is where the agent starts delivering unexpected value. Not because it was programmed to, but because it understands the shape of your work well enough to notice patterns you haven't.

Why Not Just Use React?

Fair question. If you're generating UI, why not generate React components?

Three reasons:

Dependency burden. A React app needs node_modules, a build step, a bundler, and a process manager. An ephemeral UI needs a Tauri shell and generated HTML. Adding 200MB of dependencies for a temporary view is architecturally absurd.

Agent simplicity. An agent generating a single file with inline HTML, CSS, and JS needs to understand one pattern. An agent generating React components needs JSX, hooks, state management, component lifecycle, and your specific build toolchain. Simpler generation means more reliable output.

True ephemerality. When the interface is generated HTML in a disposable window, cleanup is closing the window. When it's a full application scaffold, you've recreated the maintenance problem you were trying to solve.

Repo sprawl. Every permanent UI is another repository. Another codebase your agents need to index, understand, and avoid confusing with the five other repos in your workspace. We've watched agents edit the wrong project because the codebase count grew past what the context window could track cleanly. Ephemeral UI produces zero repositories. The interface exists in a native window, serves its purpose, and leaves no trace in your version control.

The goal isn't to build a worse React app. It's to build a different kind of thing — an interface that exists exactly as long as it's useful.

What This Means for Your Team

If you're building internal tools, dashboards, or admin panels, consider which of them actually need to be permanent applications. The honest answer for most teams: fewer than you think.

Start with Level 1. The next time someone asks for "a quick way to see X," don't spin up a new repo. That repo becomes another thing your agents navigate, another branch to manage, another source of confusion when you're working across projects. Instead, ask your agent to generate it. If your agent framework supports code execution (Claude Code, Cursor, Windsurf — most do now), this works today with no special tooling.

Graduate to Level 2 for interfaces you regenerate often. Write a spec that describes the data and layout. The spec is cheaper to maintain than code, easier to update than a component tree, and readable by anyone on the team — not just frontend developers.

Aim for Level 3 as your agent layer matures. The more context your agent has, the more valuable its generated interfaces become — UI that gets smarter because the agent gets smarter, without touching a line of frontend code.

The Spec Is the New Codebase

We're watching the same pattern that played out with infrastructure. DevOps moved from manually provisioned servers to declarative infrastructure-as-code. The servers became ephemeral; the specs became permanent. UI is following the same trajectory — except UI specs don't need the precision of Terraform. An agent can fill in reasonable defaults for spacing, typography, and layout. This tolerance for ambiguity is what makes the pattern practical.

HQ's ephemeral UI system is open source. If you're running Claude Code or any agent framework that can execute code, you can build the same pattern today. Define a runtime protocol. Write declarative specs. Let your agent handle the rest.

The best dashboard is the one that doesn't exist until you need it.

Build with HQ. Indigo's open-source framework for AI-orchestrated work includes ephemeral UI, project management, and worker orchestration out of the box. Get started on GitHub.