Happy Coffee: The Agent-Native Data Developer Portal

Dataset details
Costs
Development
Quality checks
Home page
Sources

Inspiration

Data developers spend too much time moving between catalog pages, lineage graphs, SQL editors, quality dashboards, and pipeline runs. This project shows what changes when an agent can use a data developer portal directly - not by guessing from the UI, but through explicit WebMCP tools.

Happy Coffee is built around the idea that the agent does the routine development work while people can see, understand, and control the outcome.

What it does

Happy Coffee is an agent-native data developer portal powered by WebMCP.

It gives AI agents structured tools to understand and operate the portal without relying on screenshots, DOM scraping, or UI automation. An agent can:

discover the portal’s capabilities and safeguards;
search datasets, sources, quality checks, pipeline runs, logs, lineage, and costs;
inspect schemas and preview bounded samples of data;
open a browser-local DuckDB workspace and write or run SQL;
create temporary derived tables and data-quality checks;
prepare a table for publication with metadata, field descriptions, transformations, schedule, and attached quality checks.

At the same time, the portal gives people visual feedback for every meaningful step. They can inspect the source data, review the SQL, see result grids, follow lineage, understand quality-check failures, and observe mocked staging runs.

On critical decisions, such as publishing a table to production, the agent is not doing it automatically. A human must intentionally review and approve it.

How we built it

Happy Coffee is built with React, TypeScript, Vite, and Tailwind CSS.

The development experience runs on DuckDB-Wasm inside the browser. Generated catalog data is loaded into the happy_coffee schema, while temporary derived data is created in a local workspace schema. This means the SQL experience is immediate, portable, and does not require a server-side database.

The portal registers structured tools through document.modelContext, and each tool returns a versioned contract with stable IDs, bounded data previews, navigation context, and explicit safeguards. This lets an agent reason about the portal as an application—not as a collection of pixels.

The app is deployed on Cloudflare Pages. Every merge to main produces a new production deployment, and pull requests receive preview deployments.

                         Happy Coffee architecture

     Developer                              AI agent
         │                                     │
         │ sees evidence and approves          │ uses structured tools
         ▼                                     ▼
┌──────────────────┐                  ┌──────────────────┐
│ Happy Coffee UI  │◀────────────────▶│ WebMCP site tools │
│ React + Vite     │  shared live UI  │ document.modelContext
└────────┬─────────┘                  └────────┬─────────┘
         │                                     │
         │                                     │
         ├───────────────┬─────────────────────┤
         ▼               ▼                     ▼
┌────────────────┐ ┌────────────────┐ ┌─────────────────────┐
│ Data portal    │ │ Develop        │ │ Agent-safe actions  │
│                │ │ workspace      │ │                     │
│ • catalog      │ │ • notebooks    │ │ • search & inspect  │
│ • sources      │ │ • SQL cells    │ │ • preview data      │
│ • lineage      │ │ • quality      │ │ • create/run SQL    │
│ • pipelines    │ │ • DuckDB-Wasm  │ │ • stage publishing  │
│ • costs        │ │   in browser   │ │                     │
└───────┬────────┘ └───────┬────────┘ └─────────────────────┘
        │                  │
        ▼                  ▼
┌────────────────┐ ┌─────────────────────────────┐
│ Generated demo │ │ Browser-local workspace      │
│ data and       │ │ Temporary tables and SQL     │
│ realistic      │ │ state are disposable/reset   │
│ relationships  │ │ with the local session       │
└────────────────┘ └─────────────────────────────┘

                    Human approval boundary
                              │
                              ▼
                  ┌────────────────────────┐
                  │ Table Publishing       │
                  │ Agent prepares:        │
                  │ metadata, schedule,    │
                  │ transformations, and   │
                  │ quality checks         │
                  │                        │
                  │ Human clicks Publish   │
                  └────────────────────────┘

 GitHub repository Cloudflare Pages ──▶ Live demo

Challenges we ran into

The main challenge on the implementation was balancing autonomy with intent. It was tempting to expose one more tool that would publish a table automatically, for example. Instead, we made publishing a deliberate boundary. The agent can do all preparatory work, but it cannot cross the final line without a person.

Accomplishments that we're proud of

We built a portal that an agent can understand through structured capabilities rather than visual inference.
We made the human-agent experience observable: the agent acts, while the portal explains and visualizes the work.
We designed a complete development arc—from catalog discovery to SQL, quality checks, publishing preparation, and mocked execution.
We added data-integrity guarantees specifically because agent workflows need trustworthy relationships, not merely realistic-looking data.
We kept DuckDB-Wasm local to the browser, making the SQL workspace fast, private, and easy to deploy.
We established a meaningful safety boundary: agents can prepare a publishable table, but people retain the final publishing decision.

What we learned

We learned that agent-native UX is not about adding a chat box to an existing product.

The real work is deciding what an agent should know, what it should be able to change, what context it needs to make safe decisions, and how the human can verify the result without reading a wall of tool output.

We also learned that visual feedback is not a fallback for agents - it is the collaboration layer for people. Sample rows, lineage graphs, quality cards, result tables, and run logs turn invisible agent actions into something a developer can inspect, challenge, and trust.

Finally, we learned that safe autonomy is a design advantage. The human publish step does not weaken the agent experience; it makes the experience credible.

What's next for Happy Coffee: The Agent-Native Data Developer Portal

Next, we want to make the collaboration model even richer:

reusable agent workflows for common data-development tasks;
visual explanations for query plans and quality-check failures;
richer staging and production simulation;
shared ephemeral workspaces for team review;
better ways to compare an agent’s proposed data product against existing catalog assets.