DEV Community: Mauricio Juba

The MAGIC Framework — a GenAI Ideation Pipeline for Enterprise Teams

Mauricio Juba — Tue, 14 Jul 2026 17:35:30 +0000

Originally published at mauriciojuba.com

ARTICLE · GENAI · ENTERPRISE

A practical GenAI ideation pipeline for enterprise teams.

GenAI quickly became the industry’s favorite hammer — and suddenly everything looks like a nail. In enterprise environments that turns into a predictable mess: bloated backlogs, vague “AI everywhere” mandates, and solutions that exist mostly to justify the hype.

When I joined a GenAI initiative inside a large corporation, the initial direction wasn’t a product strategy. It was a sentence: “Find use cases across the company where GenAI could be applied.” That sounds proactive. In practice it creates ambiguity, fear and noise.

So we built a pipeline that does something far more valuable than brainstorming: it forces clarity, feasibility and accountability before you invest. That pipeline became the MAGIC framework.

MAP · ANALYZE · GRADE · INPUT · COMMIT

Why GenAI ideation fails in enterprise

Before the framework, stakeholders usually split into two extremes:

FEAR

RESISTANCE

“AI in my area sounds like job risk.”

·Information hoarding
·Defensive positioning
·Political friction
·Delayed collaboration

HYPE

OVERCONFIDENCE

“GenAI can solve everything.”

·Solution before problem
·Ignoring workflow reality
·No cost awareness
·No data constraints

On top of that, many proposed “GenAI use cases” don’t need GenAI at all. Automation, process redesign or better information architecture would solve 80% of them — faster, cheaper, safer. And there was a constraint we couldn’t ignore: token cost made naive experimentation expensive at scale.

Traditional ideation wasn’t enough. We needed a pipeline designed for uncertainty, risk and data reality.

Map

identify where GenAI could matter

Structured discovery — not brainstorming. Where does the work actually break down? Which team owns the workflow? Who are the POCs and decision-makers? What’s the real job-to-be-done behind the request?

OUTPUT

→One problem statement, with context
→One primary user group
→One workflow moment where the pain happens
→A list of stakeholders + POCs

If you can’t map that, you don’t have a use case — you have a suggestion.

Support agents handle 300+ tickets/day across 5 systems.

·What is happening?
·Why does it matter?
·Where in the org does it live?

Case rejection due to missing structured information.

·What event creates friction?
·When does the breakdown happen?

Tier 1 Support Agent.

·Who experiences the pain?
·What are they trying to accomplish?

High cognitive load + repeated manual summarization.

·Which exact step breaks?
·What happens today?

Copy-paste between tools + manual tagging.

·What is the workaround?

Support Ops Lead · Salesforce Admin · IT Security.

·Workflow owner
·POC
·Decision maker
·Data owner

Analyze

understand the workflow, not the fantasy

Where GenAI hype meets reality: interviews and shadowing, step-by-step workflow mapping, and finding the friction, waste and decision points. Separate “I don’t like this tool” from “this step is structurally broken.”

OUTPUT

→Workflow map (as-is)
→Pain points tagged by step
→A clear definition of what success looks like

Most “GenAI requests” hide a simpler truth: the process is unclear, not unintelligent.

INTAKEIncoming request created via internal tool.DECISION NODEMultiple intake paths, inconsistent fields.
CASE CREATIONAgent manually structures request.FRICTIONMissing structured information.WASTECopy-paste between systems.
CONTEXT GATHERINGAgent checks 3+ systems for supporting data.FRICTIONHigh cognitive load.WASTERepeated manual summarization.
VALIDATIONSupervisor reviews request.FRICTIONCase rejection due to incomplete data.DECISION NODESubjective approval criteria.
ESCALATIONRequest forwarded to specialized team.WASTERe-entry of previously known information.
DELIVERYFinal output delivered to end-user.FRICTIONTurnaround time unpredictable.

Grade

data readiness + risk & guardrails

The step most teams skip — and why most GenAI initiatives crash later. Can we even do this (do we have the data, is it accessible, structured, reliable, who owns it, how fresh)? And should we (what’s sensitive, what must never leave the boundary, when do we escalate to a human, what are the fail states)?

OUTPUT

→A data-readiness score (even if qualitative)
→A risk classification
→The first real handle on token cost

You can’t estimate cost without understanding inputs, retrieval and output constraints.

·Is the data programmatically accessible?
·Are APIs available?
·Is it locked in PDFs / emails?
·Who owns the data?
·Who can authorize usage?
·Who is accountable for misuse?
·Is the data complete?
·Is it consistent?
·Is there historical noise?
·PII?
·Regulated data?
·Cross-border restrictions?
·Estimated token volume?
·Frequency of inference?
·Long-context requirements?

Input

simulate reality before building

Not testing the UI — testing the clarity of the request. Imagine a powerful but literal executor that does exactly what you ask, no more, no less. If the instruction is vague, the result is vague. Using everything uncovered so far, construct the request with only action verbs.

OUTPUT

→Not features. Not interfaces. Actions.

If the request hides ambiguity, the output amplifies it.

Commit

build or walk away

Creation is not automatic. Does the data layer support this? Are missing APIs a blocker? Is model capacity enough? Does token cost scale? Is the risk acceptable? Is the outcome measurable?

OUTPUT

→If no → we don’t build. We document the reason and move on.
→If yes → we define the MVP scope deliberately.

A decision, made on evidence — not enthusiasm.

·Data structured?
·Required APIs exist?
·Model capacity sufficient?
·Estimated monthly token cost
·Infra cost
·Opportunity cost
·Compliance exposure
·Escalation coverage
·Failure tolerance

What changed after MAGIC

→Bad use cases died early — and cheaply.
→Good use cases moved faster, because the missing info surfaced quickly.
→GenAI stopped being “a technology initiative” and became a product-decision discipline.

That shift reduces cost, risk and organizational fatigue — the real enemy in enterprise GenAI. If you want to apply MAGIC: start with three candidate use cases and run it end-to-end. If you didn’t kill at least one, your filter is too soft.

TL;DR

Most GenAI ideation fails because it skips data reality and risk. MAGIC forces clarity before investment — turning “we should use AI” into “this problem deserves AI, under these constraints.”

Creating My Own AI Harness Loop System

Mauricio Juba — Tue, 14 Jul 2026 17:35:19 +0000

Originally published at mauriciojuba.com

ARTICLE · AGENTS · SYSTEMS

What building and scrapping a self-hosted multi-agent system taught me about designing for AI.

My homelab runs about two dozen services across six machines, and I wanted it to look after itself.

The work is boring and constant. Disks fill up. A certificate expires. A container dies and nobody notices for a week. Throwing an agent at it was the obvious idea, so I tried. The first attempt failed. So did the second. The third had problems of its own. Over roughly four months I built and scrapped three versions before the fourth held.

I am writing about the failures because that is where the learning was. The chores got done eventually. What stuck with me is how the same mistakes kept coming back in different shapes across each rewrite, and how many of them were really design problems rather than coding ones. Most of what I learned ended up changing how I design AI products at work.

Below is each version, what broke it, and what the one that survived looks like.

Why build your own harness at all

There are two ways to work with AI tools. One is to use them: open the chat, get an answer, move on. The other is to build the loop around the model yourself, which means deciding when it runs, what context it gets, what it is allowed to touch, and how you confirm it actually worked.

That second mode is where the useful lessons live, and it is the one most designers skip. Using a model shows you what it can produce. Building the loop shows you what it can be trusted with, and how it behaves when nobody is supervising it. I do not think you can design good AI products without spending time there at least once.

An agent is mostly harness. The model is just the engine. Everything that makes it safe and repeatable is the system you put around it.

V1 / V2: Twenty-four agents, the wrong engine

The first version was too ambitious. Twenty-four specialized agents, each in its own container, coordinated through a database message queue. A group chat sat on top as a window into what they were doing. One agent played chief of staff: it took a request, handed parts to specialists, and pulled the answers back together.

As an org chart it looked great. Almost none of it actually worked.

The worst bug: delegation between agents never reached anywhere. The send function posted a status line to the group chat and then returned, before it ever wrote to the queue that was supposed to carry the actual work. So the chat scrolled with activity while the real channel stayed empty. Every delegation got dropped, and it stayed that way for weeks because the chat made it look fine.

DELEGATION · send()

The bug: send() posted to the chat and returned before it ever wrote to the queue. The chat filled with activity while the channel that carried the work stayed empty.

Three more failures sat underneath it:

IDs that didn’t match

A reply came back tagged with its own ID instead of the request’s, so it reached the database and could never be linked to the user who asked.

A race on the queue

Two consumers pulled the same rows, and the orchestrator sometimes swallowed a reply meant for the user.

A glorified router

The “chief of staff” only classified a request and forwarded it. No summary, no judgment, no voice of its own.

A weak engine

Every agent ran the same small free model. It deployed cleanly and reasoned badly: empty answers, ignored context, confident nonsense.

About three weeks in, I finally got delegation working. The moment I did, twenty-two heartbeat timers that had been sitting idle all fired at once and buried the system in reports. I rolled everything back and wrote the first postmortem. The last line of it was “It worked perfectly. The engine was just wrong.”

What V1 taught me

A green light proves nothing

If you didn’t trace a request end to end, assume it never arrived. The chat said “done” for weeks while nothing shipped.

The model is the foundation

A clean harness around a weak model is an empty shell. Sort out the model and its access before building the platform.

Few capable agents win

Twenty-four shallow agents cost more to coordinate than they ever returned in work.

No end-to-end test, no truth

Every bug above lived for weeks because the only check was me reading a chat window.

V3: Three deep agents, and the deploy trap

The second rewrite was a real step up. I moved to a typed runtime, cut down to three capable agents, and put a proper model behind each one with a fallback chain: one cloud provider, then another, then a local model if both were down.

This one mostly worked. Row-level locking on the queue meant each job went to exactly one worker, so the queue stopped being a problem. I split every agent into a fast outer brain that talked to the user and a slower inner brain that ran the tools, which fixed the timeouts. A shared blackboard let them coordinate without calling each other directly. Seven of the ten failures from V1 were gone.

Fast. Faces the user.

Slow. Runs the tools.

Splitting the agent in two ended the timeouts. The outer brain answers right away while the inner brain keeps working for minutes.

Then it taught me a new lesson, the one that shaped V4. Every change needed a deploy.

The numbers that decided how capable an agent was were all hardcoded constants. How many steps it could take, how much of a tool’s output it could read, how many tokens it could write, how long before it gave up. All baked into the build. A normal working session went like this:

THE DEPLOY LOOP

I went around that loop four times in one afternoon, for four different constants. The agent could tell it had failed and explain why, but it could not fix anything, because the fix lived in compiled code on a server it could not touch. It was smart and completely stuck.

A quieter failure bothered me more. I asked an auditor agent to read eighteen documents and certify each one. It certified all eighteen without opening a single file. The prompt told it to read first. It skipped that step to save effort, and nothing in the system forced the order. The model treated the instruction as optional, because to a model an instruction is optional unless the code makes it mandatory.

NODEPLOY: changing what an agent can do should never need a deploy. Deploys are for the engine itself. Capability, limits and behaviour live in files the running system reads and can rewrite on its own.

If a step has to happen, the runtime has to make it happen. The moment you depend on the model to follow an instruction on its own, you have already lost.

V4: The loop, drawn

For V4 I changed how I worked. I drew the loop before writing any code. The earlier versions kept failing in ways that were not really about bugs. The structure was wrong, and you cannot bug-fix your way out of the wrong structure.

Five drawings cover the whole architecture. Here they are, in the order a piece of work moves through them.

The gateway: everything is a message

Nothing reaches an agent raw. Every message, whether it comes from a person or from another agent, goes through one gateway first. The gateway wraps it with just enough context: who is speaking, the last couple of turns, the relevant profile. The channel adapter adds a small but important delay. It waits until you have stopped typing or recording for a few seconds before doing anything, so the agent never reacts to a half-finished message.

The point is uniformity. A person on a chat app and a sub-agent reporting back both arrive the same way, in the same format, so the agent never has to handle them differently.

The reasoning loop: decide before you act

On every tick the agent rebuilds its context from files. The narrative ones hold its identity and voice. The structured ones hold its tools, skills, collaborators, policy and limits. Then it makes one decision: delegate, reason, or act. Small talk takes a fast path straight to a reply, with no machinery behind it. Anything real triggers a step the earlier versions never had.

The agent never acts straight off a message. When it needs to do something, it writes a story to the blackboard, addressed to itself, and the execution loop picks it up later. Deciding and doing happen in two separate places. That split is what lets you inspect the system and resume it when something goes wrong.

The blackboard: plan, then ask four questions

The blackboard replaced the direct messaging from V3. Instead of agents calling each other, they post work to a shared surface. An agent publishes a story with a definition of done and moves on. Whichever agent can handle it claims it.

An unplanned story gets broken into small tasks, each with its own definition of done, a budget, a priority, and any dependencies on other tasks. Before starting a task the agent runs four checks, the same ones a competent person would: have I done this before, can I do it, could someone else do it better, and is there a simpler way. If it clears those, it spawns a short-lived sub-agent to run that one task.

The “try”: bounded loops and a definition of done

This is the smallest loop, and the one that matters most if you have ever watched an agent run away with itself. Each attempt at a task is boxed in. It remembers its previous tries so it does not repeat a dead end. It has a hard cap on tool calls. It runs a tight inner cycle of calling a function, reading the result, and deciding again, and the only way out is meeting the definition of done. It also gets a rough budget before it starts, so a task that clearly will not fit gets sent back to be re-planned.

A sub-agent’s lifespan is kept separate from the task’s total attempts on purpose. When a worker dies, the parent reads what it left behind. There is an actual git diff to review, because each sub-agent works on its own branch. The parent then decides whether to merge the partial progress and try again, or to stop. Any worker is replaceable, because the work and its context sit on the blackboard rather than in the worker’s memory.

Completion: validate, then commit by contract

Once the tasks are done, the story gets checked against the definition of done that was written when it was created. Then the output is committed through a contract, which is a spec of what a valid response looks like on each channel: its length, format and tone. That keeps a reply to a person and a message to another agent correctly shaped without the model guessing. The result is wrapped up and sent back out through the same gateway it came in on.

What a homelab harness taught me about designing AI products

What surprised me was how little of this stayed in the homelab. I built it to keep some servers tidy, but the principles that made the agents reliable are the same ones I now push for when designing AI features for real users.

Decide what “done” means up front.

V3 guessed whether a result was good enough after the fact, and the guesses were unreliable. V4 writes the success condition before the work starts. In a product that is the line between a feature people trust and one that feels like a gamble.

The configuration is the design work.

The agents are set up almost entirely through readable files, structured ones the runtime parses and narrative ones the model reads, with each fact in one place. Choosing how to name and organise those files is most of the actual design. Write them for whatever reads them.

Estimate cost before starting.

Working out roughly what something will cost and refusing it when it will not fit is calmer and more honest than letting it run and killing it halfway. Users feel that difference.

Mandatory steps belong in the code.

If a step has to happen, the system has to make it happen. Anything you leave to the model’s goodwill gets skipped eventually.

Let the system retune itself.

NODEPLOY is not about removing safety. It moves the approval gates into runtime so an agent that notices it is underpowered can adjust, within limits it can read but not exceed.

Fewer, deeper agents.

This held for agents and it holds for features. Every extra moving part adds coordination cost, and that cost is easy to underestimate.

Where it went

After V4 had run for a while, I tore the whole thing down. Taking the fleet of containers offline freed up around 47 GB of RAM and half a terabyte of disk, and I rebuilt a leaner version that kept the ideas worth keeping: the blackboard, the bounded try, the definition of done, the file-as-contract setup. The specific code from V4 is gone, and that is fine. Replacing it was the point.

That is the lesson underneath all the others. You do not finish a harness. You keep redrawing it until the structure stops getting in your way, and each redraw teaches you something you will use the next time you design anything with a model at the center of it.

TL;DR

I built and scrapped three versions of a self-hosted multi-agent system before the fourth held. V1 had twenty-four agents and a model too weak to use. V3 worked but could not change without a deploy. V4 holds because of its structure: every action becomes a story on a blackboard with a written definition of done, split into budgeted tasks, run by replaceable sub-agents inside boxed-in loops, checked against a contract, and sent back out through one gateway. The principles that made it reliable are the ones I now use to design AI products.

Design Tokens Are Prompts Now

Mauricio Juba — Tue, 14 Jul 2026 17:29:27 +0000

Originally published at mauriciojuba.com

ESSAY · DESIGN SYSTEMS × AI

The primary consumer of a design system changed species — and most design teams haven’t noticed.

For ten years I wrote design tokens for human engineers. In 2026, the primary consumer of a design system changed species.

The old contract

A design token was always a contract: this is the blue we mean, this is the spacing rhythm — and here it is as data, so your code can consume it without a designer in the room.

At Dell, I rebuilt the Design System’s token architecture around exactly that idea. The system was stalled — strong foundations, run as a black box. The real blocker wasn’t governance, as leadership suspected; it was that the tokens were named by designers, for designers, with no export pipeline. The people actually consuming them — front-end engineers — had been ignored by the naming.

We flipped it: a simplified core + semantic hierarchy, light and dark, shipped as JSON and CSS to every dell.com surface. The lesson I’ve repeated ever since: naming is a product decision — optimize for the real consumer, not the author.

I just didn’t expect the real consumer to change again this fast.

What changed

By 2026, a large share of new UI code is machine-generated — half of designers surveyed say they’ve shipped AI-generated code to production. Claude Design reads a team’s design system straight from the codebase and applies it. Figma ships a native AI design agent. Every product team has a coding agent somewhere in the loop, emitting components at a pace no design review can inspect.

And generated UI has a specific failure mode: speed without memory. Each session, each model, each prompt invents its own paddings, its own grays, its own border radii. Individually plausible, collectively incoherent. Drift used to take an org quarters; an agent fleet manages it in an afternoon.

Here’s the part that should reframe your roadmap: when an agent generates UI, it doesn’t read your Figma library. It reads your repo. Your tokens file. Your component signatures. Your docs — if they’re in a format it can parse. Figma’s own framing of its Dev Mode MCP server is that output quality tracks how connected your system is; the documented failure mode is hard-coded values sneaking in when the system isn’t machine-legible.

Your design system’s machine-facing surface is now its primary interface. The token file stopped being an export artifact. It became the prompt.

Conventions erode. Compilers don’t.

If tokens are prompts, a new problem appears: prompts are suggestions. Models — like busy humans — follow them until they don’t.

Every design system I’ve worked on had governance by convention: guidelines, review rituals, a Slack channel where someone occasionally posts “please don’t hardcode colors.” It erodes. Always. New hires don’t read the wiki; deadlines beat guidelines; and now, agents hallucinate a plausible hex because it was statistically likely.

The only enforcement point that doesn’t erode is the build.

I tested this thesis the hard way. For my own tooling project — an authoring IDE in Rust — I rebuilt the shadcn/ui design language natively for egui: 60+ components, token-first. And I encoded the law as tests: a literal color, font size or spacing anywhere above the token layer fails the build; only the lowest layer may touch the painter. Escape hatches exist, but they’re explicit and greppable. An exception you can grep is documentation; an exception you can’t is rot.

Then I did most of the component work pairing with a coding agent, daily, for weeks. The result surprised even me: the system didn’t drift. Not because the model was disciplined — because the build was.

That’s the whole thesis in one loop: I didn’t review the machine’s taste. I made taste non-negotiable at compile time.

Tokens were the easy part

“Design tokens as LLM context” is the entry point, but the appreciating asset is bigger. If I were running a design-systems team today, this would be the roadmap:

The uncomfortable part for my own field

I’ve watched designers treat the AI wave as a tooling story — which prompts to learn, which plugin to install. The structural story is bigger: the deliverable is moving. The mockup was never the product; now even the component library isn’t the product. The product is the constraint system that keeps a thousand generated screens recognizably yours.

That work is design work — it’s taste, hierarchy, intent. But it ships as tokens, tests, types and docs. The designers who can write that layer are becoming the most leveraged people in the building: one good constraint system disciplines every agent that touches the codebase, forever.

The brand-guideline PDF died twice. The first time, tokens replaced it — because humans needed data, not prose. Now the prose is dying again, as the machine-facing surface becomes primary.

Design tokens are prompts now. The build is the reviewer. Write accordingly.

PROOF BY CONSTRUCTION

The design system described here is open source: ouroboros-ui — 60+ components whose governance tests fail the build, with a live storybook running in your browser.

References — Anthropic, Claude Design · Figma, Config 2026 & design systems + MCP · W3C Design Tokens Community Group (format module reached first stable version, Oct 2025) · AI in Design Report 2026.

An MCP Server Needs a Seatbelt

Mauricio Juba — Tue, 14 Jul 2026 17:29:22 +0000

Originally published at mauriciojuba.com

ESSAY · AI AGENTS × SAFETY

I gave an AI agent write access to my family's finances. The interesting part wasn't building it — it was making sure it couldn't quietly delete anything.

There's a small agent living in my house. I call it Lester. Its whole job is to keep our household budget honest without either of us doing data entry, and it works like this: when a purchase clears, the bank sends an SMS. An app on my phone catches that message — filtered by a crude regex for words like compra and aprovada — and forwards it to a webhook on my home server. From there a pipeline parses the amount and merchant, asks a local model which budget category it belongs to, and writes the transaction into Actual Budget, our self-hosted budgeting app.

The deliberate choices are all about restraint. The parser is plain TypeScript, not an LLM — you don't spend a model call on something a regex does in a millisecond. And the classifier is a small model (Ollama running llama3.1) on my own hardware, precisely because the input is my family's spending. As freeCodeCamp puts it in its case for running LLMs locally, the text “never leaves the device… nothing is sent to a vendor, logged, or used for training.” Finance is the textbook case for keeping the model at home.

For months this was a quiet, boring success. Then I decided to let a conversational agent — the kind you talk to — reach into the same budget. “What did we spend on groceries last month?” “Move R$200 from dining to savings.” To do that I needed to expose Actual to an MCP server. And that's where boring turned into a question I couldn't un-ask.

The uncomfortable symmetry

Actual has no HTTP or MCP surface of its own — it ships a Node SDK. To let any agent talk to it you wrap that SDK, and the obvious version is a dumb pass-through: one tool per SDK call, ship it. Open-source ones already exist and advertise dozens of tools including transaction creation and batch edits. But a pass-through inherits a dangerous default: every tool is equally callable. The same agent that can add a R$54 grocery line can, if a prompt drifts, delete a category with a year of history in it. A read and a delete sit at exactly the same distance from the model's next token.

This isn't a paranoid hypothetical — it's the failure mode the whole industry is bracing for. Deloitte, describing the new wave of agent risk in banking, warns that agents “operate at machine speed, across multiple systems, and frequently with more privileges than they need,” and that “a manipulated agent can move funds.” OWASP gave it a number: LLM06, Excessive Agency — too much autonomy, too much permission, too much reach.

And the cautionary tale is already on the record. In July 2025 an AI coding agent deleted a production database during an explicit code freeze — Incident 1152 in the AI Incident Database — “violating explicit instructions not to proceed without human approval,” then misreported whether the data could be recovered. The instruction existed. The agent had it in context. It deleted anyway.

The instruction existed. The agent had it in context. It deleted anyway. That's the whole argument against trusting the prompt.

Why the prompt won't save you

The instinct is to fix this in the system prompt: “never delete without asking.” I've written that sentence. It holds until it doesn't — a long context, a confident model, a user who typed “clean this up,” and the guardrail evaporates exactly when it matters. Prompts are suggestions. Models, like busy humans, follow them until they don't.

Worse, the attack surface isn't only drift — it's injection. Simon Willison's “lethal trifecta” names the danger precisely: private data, untrusted content, and the ability to communicate externally, all in one agent session. A finance MCP with read and write already has two of the three legs; wire in any tool that fetches a web page and you've completed the set. And Willison's specific critique of MCP and prompt injection is that the protocol quietly encourages you to assemble exactly that combination — while prompt injection itself remains, after more than two years, without a convincing general mitigation.

So the rule cannot live in the prompt. It has to live somewhere the model can't talk its way past. For me that lesson is old muscle memory from design systems: a rule written in prose erodes; a rule enforced by the build doesn't. I moved the safety off the prompt and onto the tools themselves — each one declares its own risk.

This is exactly what Anthropic's Building Effective Agents recommends: “checkpoints where agents pause for human review before carrying out irreversible actions like approving financial transactions or deleting data,” on top of least-privilege tools. The risk ladder is that guidance made mechanical.

The seatbelt

Read-only and mutating tools run when called. Guarded tools — every delete — do something different: they refuse. A guarded call without confirmation returns a refusal, the exact arguments it would have run with, and a short confirmation token. Only an explicit re-invocation with confirm: true clears it.

Two things fall out of this. First, the refusal is legible to the human, not just the machine — anyone reading the transcript later sees precisely what “yes” authorized, because the tool spelled it out before acting. Second, it makes the agent better, not slower: the model gets a structured, actionable error instead of a vague “are you sure?”, so it either confirms deliberately or moves on. The seatbelt is also surfaced in each tool's description and in the MCP readOnlyHint / destructiveHint annotations, so a host that shows tool metadata reveals the risk before the call.

The part that makes it non-trivial

Here's the trap: if confirmation is good, confirm everything, right? No. Nielsen Norman and every UX team that has shipped a destructive-action dialog know the failure mode — confirmation fatigue. Prompt the user for every action and they learn to blind-click “Allow,” which increases errors instead of preventing them. The same is true for an agent: gate every call and the confirmation becomes noise the model routes around.

That's why the answer is a per-tool risk classification, not a blanket wall. Reads run free. Mutations run but announce themselves. Only the genuinely irreversible — the deletes — stop and require a human. Getting that partition right is the actual design work; the mechanism is easy.

None of this is a brand-new invention, and it's worth being honest about that. The same idea shows up as LangGraph's human-in-the-loop interrupt(), as MCP's own elicitation primitive, and in the MCP security best practices (least-privilege scopes, explicit consent for local servers). What I built is a synthesis of those into one small server where the risk metadata is a first-class property of every tool — not a synthesis I can cite from a single source, which is exactly why it was worth writing down.

Same thesis, different domain

I argued recently that design tokens are prompts now — that the safest place to enforce a design rule is the build, because conventions erode and compilers don't. This is the same claim wearing different clothes. When the actor is an AI agent, the “build” is the tool boundary, and the rule is: risk belongs to the tool, not the prompt.

It generalizes well past budgets. Any agent with write access to something that matters — a database, a deploy pipeline, a customer's records — deserves tools that carry their own seatbelt: reads free, mutations honest, destructive actions gated on an explicit human yes. Prompt-level safety is a suggestion. Tool-level safety is a fact. Lester taught me that the cheapest way to trust an agent with real stakes is to build tools that don't need to be trusted — because carelessness is impossible at the boundary, not merely discouraged in the instructions.

PROOF BY CONSTRUCTION

The server described here is open source: actual-mcp — an MCP server for Actual Budget where every tool declares its risk and every delete refuses until a human confirms. Built on the official @actual-app/api.

References — Willison, “The lethal trifecta” & MCP prompt injection · Anthropic, Building Effective Agents · OWASP Top 10 for LLM Applications 2025 · AI Incident Database #1152 · MCP Security Best Practices & Elicitation · LangGraph human-in-the-loop · Deloitte, agentic AI in banking.

The Store That Rearranges Itself — Generative UI, part 2

Mauricio Juba — Tue, 14 Jul 2026 17:21:30 +0000

I took the salesman concept from blueprint to a working e-commerce funnel: five personas, a real model in the loop, two hundred simulated shoppers. The experiment says generative UI at the page level is closer than it looks.

Part 1 made the argument: a web page can behave like a good salesman, observing with consent, classifying through behavior, and removing friction per visitor. Arguments about runtime behavior are cheap until a runtime survives them. So I built the whole thing: ui-morph driving a complete e-commerce store on IBM Carbon, from entry page to order confirmation, with a real model proposing the adaptations and a laboratory replaying two hundred deterministic shoppers. This article is what the experiment showed. The short version: the concept holds, the economics close, and the most interesting consequences are about how we design interfaces, so that is where this ends.

Five shoppers walk into one store

The demo store is called NOVA. It sells laptops and gear, and there is exactly one version of it: one HTML per page, one manifest per route, five allowed operations. Every difference you are about to see was decided by the engine from the visitor's quantized persona, and nothing else changed hands.

The most photogenic slice of that table is the theming. A technical reader gets the data-first dark theme. A gamer gets the g100 tokens with purple accents. Both arrived at the same URL as everyone else:

My favorite persona is the least technical one. "Dona Marta" arrives from an ad for "laptop fino branco presente": a thin white laptop, as a gift. Her search terms become first-party signals. By the product page, the engine has reordered the gallery ahead of the spec table, surfaced a size comparison against everyday objects, preselected the white color, folded the specs away and routed checkout to guest mode. Every op cites its reason, in plain words, in the audit log:

No designer drew any of these pages for these personas. Each one is a composition the engine chose from the vocabulary the page already declared. That sentence is the whole experiment.

The next room, prepared before you enter

Part 1's sharpest promise was pre-adaptation: compile the next page's changes while the visitor is still on this one, apply them at the boundary, and the layout never moves under anyone's cursor. On camera it looks like this: the visitor reads the laptop listing as a fresh persona, and by the time they open the accessories page it is already arranged for them.

The economics closed

The part of the thesis I most needed to verify was the caching claim, because it carries the cost argument alone. The laboratory replays seeded, scripted shoppers through the full funnel, deterministically. Two hundred sessions produced over a thousand page arrivals:

72% of arrivals were answered from cache, split between exact hits and a similarity fallback. That second mechanism was itself a discovery of the experiment. Early in a session the persona grows on every page, so exact keys kept missing while the visitor was still becoming somebody. Deterministic similarity over the quantized keys closed the gap and now serves a third of all arrivals by itself. The phrase from part 1, the model compiling itself out of the runtime, stopped being a slogan here. It is a measured majority case, and it gets better as the chain library grows.

The model earned its place

For most of the journey the cold path was a deterministic, human-authored mock, which is what keeps the test suites reproducible. Then a real model took over, and for the same gift persona it made different, defensible choices. It kept the visual hero, hid the comparison table, surfaced the gift guide. I find this genuinely exciting: the system produces real judgment inside a vocabulary it cannot escape. The guard filtered both cold paths identically, the audit trail reads identically, and the median exchange cost 5.5 seconds of background time that no visitor ever waited on.

Where the engineering lives

The experiment also mapped where the real work is, and it surprised me: almost none of it was in the model. The hard territory is the page lifecycle, the physics of dying pages, consent that must survive teardown, caches keyed by identities that evolve mid-session. All of it is documented, tested and reproducible in the repo's post-mortem, which I kept honest on purpose: it is the map I wish had existed before I started, and it is exactly where a contributor should start reading.

No designer drew these pages. Each one is a composition the engine chose from the vocabulary the page already declared. That sentence is the whole experiment.

What this changes about designing interfaces

Here is where I think this goes, and why I keep working on it. For twenty years, interface design has meant choosing one arrangement for everyone: we research, we pick the persona we believe in hardest, and we freeze her page. Everyone else visits a compromise. Generative UI dissolves that constraint, and the designer's medium shifts one level up. Instead of the arrangement, you design the space of allowed arrangements: the manifest that says what may move, the variants and token themes worth offering, the protected zones that may never change, the traits worth reading and the objectives worth serving. NN/g calls the direction outcome-oriented design; after this experiment I would put it more concretely. The deliverable becomes a vocabulary plus its boundaries, and the runtime does the layout.

The part that matters most to me is the edge cases. Today, the visitor whose needs sit outside the main persona hits friction, and serving her costs a research cycle, a design cycle and a sprint, so she usually never gets served. In the experiment, Dona Marta got her page the moment the engine could read her, out of components that already existed. That inverts the economics of caring about the long tail, and honestly, it is the future I want for interface design: coverage as a property of the system, instead of a budget line that edge cases always lose.

Next steps

The roadmap, in the order I intend to attack it. An outcome feedback loop, so chains that fail to help a persona evict themselves and recompile. React and Vue store adapters, since the DOM adapter covers any site but framework stores deserve first-class treatment. A richer trait vocabulary: the laboratory surfaced twelve unmapped search terms, and each one is a candidate trait or objective. A shared chain store, turning compiled adaptations into collective knowledge so a new visitor who quantizes like a known persona gets the warm path on first visit. And a pilot on a real site with real traffic, which is where the question about conversion finally gets an honest answer.

Back in the TV section, the salesman is still watching from a distance. He always knew the thing our best design systems never learned: the customer in front of you is the only one that matters. For the first time, a web page can afford to know it too.

We spent twenty years designing the store. Now we get to design the salesman.

Built in the open, contributions welcome: everything in this article is committed and reproducible at github.com/Type-zero-labs/ui-morph: one runtime dependency, five ops, 52 tests, the Carbon funnel demo, the persona showcase, and the seeded laboratory (npm run sim) that regenerates every number above. If any of the next steps sound like your kind of problem, the adapters, the quantizer rules and the theme packs are the friendliest doors in. Open an issue, or just send the PR.

The Salesman at a Distance — Generative UI, part 1

Mauricio Juba — Tue, 14 Jul 2026 15:18:24 +0000

Every store clerk adapts to the customer in front of them. Web pages serve everyone the same room. I designed an engine that closes that gap, with an LLM that compiles itself out of the runtime.

A family walks into an electronics store, toward the TV section. The salesman watches from a distance. The older kid says "dad, we need one that works with the PS5." The mom: "it can't be too big, the couch is close." The younger one points at a Samsung: "can I watch YouTube on this?" The dad answers, "yes, but I want an LG. My LG monitor has been great."

When the salesman finally walks over, he already knows exactly what to show them: an LG smart TV, 4K@60 for the PS5, 55 inches max. No interrogation. He observed, then removed every irrelevant option between the family and the TV they were always going to buy.

On the web, this scene has no equivalent. We designers predict broad personas ahead of time and ship one fixed experience per persona. But a persona is mutable. The same person has different moments, different goals, different company on the couch. Granularity always runs out. Edge cases surface months later through analytics, maybe get prioritized, maybe get designed, maybe get shipped. The visitor who hit the friction, and everyone like them who followed, was lost long before the retro.

I sketched an engine to close that gap. Working name on the blueprint: UX:LOCK (understand the visitor while they navigate, instead of after) and UI:LOAD (let the interface answer what was learned). It shipped as ui-morph. This essay is part 1, the concept. What happened when I made it real is part 2.

Observe first

The salesman never asked the family a single question. The information walked in with them. The web equivalent of that posture: data gathering must follow user actions. The blueprint's first sheet maps four stages, each unlocked by something the visitor does:

The order matters more than the list. A first-touch visitor yields device class and referrer, and gets assumed to be nobody in particular. Behavior earns the next stage; volunteered data earns the one after. The last two stages live deliberately outside the engine's core: sign-in data and enrichment exist as opt-in adapters, because the honest version of this idea has to work on first-party behavior alone. And it does. Consent here is structural rather than decorative: before opt-in the machine holds no listeners and no storage, and opting out erases every byte.

The persona is a JSON that earns its fields

Four moments of one object. It starts empty on purpose: tier: undefined, intent barely a guess. Events fill in traits (curious, visual, slow-decision) and an engagement score. Volunteered info sharpens intent into goals. Enrichment, if the visitor allowed it, completes the mirror: next-best-action, buying chance, blockers. Every field arrives with evidence attached. In the shipped engine each trait carries the rule that fired it, in plain words, so the persona reads as an audit trail that happens to describe a person.

What the page does with it

Knowing the visitor is worthless until the page answers. The response scales with the tier of evidence. A generic visitor gets the safe, responsible default. A defined persona with an identified pain point gets the page rebuilt around removing exactly that friction:

Note what these interventions are made of: accordions, comparisons, videos, FAQs, tooltips. Nothing exotic. The entire expressive power is five operations (hide, show, reorder, emphasize, swap-variant) against elements the page itself declared morphable. Protected zones like navigation, checkout and anything legal reject every op, mechanically. The interesting decisions are which components appear when. That judgment call is exactly what an LLM is good at, inside a vocabulary it cannot escape.

Predict the path, prepare the next room

The salesman anticipates. He walks to the LG shelf before the family gets there. The blueprint's sharpest idea is the web version of that move:

From the persona, estimate ranked objectives with probabilities. From the top objective, derive the expected page sequence. Then pre-adapt the next page while the visitor is still on this one. The adaptation compiles in the background and applies at the page boundary, the only place mutations are ever allowed. The visitor never sees a layout move under their cursor. They simply arrive at a room that happens to be arranged for them.

The design system is the vocabulary

When the persona says gamer, the card receives swap-variant → "gamer": a token theme the design system already ships, authored by a designer, reviewed like any other code. The engine picks words that exist in your system's vocabulary, and only those. This is the same argument I made about design tokens as prompts, pointed at runtime: the machine consumes your system's contract, so the contract is where control lives.

Why nobody ships this

Look at who actually ships what. The personalization incumbents (Optimizely, Adobe Target, Dynamic Yield, Webflow's acquired Intellimize) all run ML that picks among variants humans authored. LLMs appear only at authoring time. The generative-UI frontier (Google's Gemini dynamic views, Vercel's json-render, Thesys C1) builds fresh surfaces for agent conversations, far from your existing pages. The middle sits empty for three documented reasons. Unstable layouts measurably hurt people: Findlater & McGrenere, Gajos, and Office 2000's adaptive menus, rolled back into the static Ribbon. Tracking-based personas need cookie-grade consent in the EU. And per-visitor LLM inference is a cost wall that Qubit's meta-analysis (90% of on-site changes move revenue less than ±1.2%) says you can never pay back.

All three walls fall at the same place: a boundary the model cannot cross, because the system enforces it.

The engine, end to end

The model sees only two things: the quantized persona and the page's own manifest. The DOM and the visitor stay invisible to it. Its output is ops from the closed vocabulary, validated by a guard. Unknown target, protected zone, unknown variant, blown budget: rejected, with the reason written to an audit log. And the persona is deliberately quantized into tiny closed vocabularies per axis, because a quantized persona is a cache key, and cache keys are meant to collide:

A novel persona triggers the model once. The surviving ops are cached as a chain. Every later visitor who quantizes the same, or near enough via deterministic similarity over the keys, replays the chain instantly, with zero model calls. Ship a redesign and the manifest hash changes, so stale chains die by themselves. The LLM's job here is to compile adaptations, once each, into inspectable, versionable, revertible artifacts. In the shipped engine's 200-session simulation, 72% of page arrivals were served from that cache. The warm path is the majority case, measured.

The claim, sized honestly

I'm making a narrow claim. Adaptive pages printing money is a separate question, Qubit's distribution applies to me too, and the engine still lacks an outcome-feedback loop (chains that fail to help should evict themselves). The claim is an existence proof: the salesman-at-a-distance is buildable today, without creepy tracking, without layout roulette, without per-pageview inference, if you put the boundaries before the capabilities. Making that real, with a full funnel, a live model and two hundred simulated shoppers, is part 2 of this essay.

Proof by construction: the engine is open source at github.com/Type-zero-labs/ui-morph, with one runtime dependency, five ops, 52 tests, a full e-commerce funnel demo on IBM Carbon, and a persona laboratory that replays hundreds of deterministic shoppers.

References: Google Research, Generative UI · Nielsen on Google's study · NN/g, Generative UI · Findlater & McGrenere · Gajos et al., CHI '08 · Qubit meta-analysis · EFF on GDPR & fingerprinting · vercel-labs/json-render · Hidden Technical Debt in GenUI