Forem: Jung Sungwoo

The Mind Protocol: Why Your AI Agent Needs a World Before It Can Think

Jung Sungwoo — Fri, 09 Jan 2026 15:03:26 +0000

🧪 Try It First, Read Later

Before I explain anything—just play with it:

Watch the Actor's inner state shift as you chat. See proposals flow through governance. Explore the Worldline. Then come back and understand why it works this way.

We've Been Solving the Wrong Problem

Every week, a new paper drops claiming to "reduce hallucination by X%." Better prompting. Larger context windows. More RLHF. Retrieval augmentation.

And yet, hallucination persists.

Here's a thought experiment: Imagine asking a brilliant person to manage your calendar, but you never show them the calendar. You just describe appointments verbally, sometimes forgetting details, sometimes contradicting yourself. When they inevitably make mistakes, you blame their "reasoning capabilities."

That's what we're doing to AI systems today.

The problem isn't intelligence. It's the absence of a World.

A Stateless Mind Hallucinates

"Hallucination" is framed as a model defect—the neural network failing to produce accurate output. This framing is incomplete.

Watch what actually happens:

User: "What's my order status?"
System: [No order status provided in context]
AI: [Infers an order must exist]
AI: [Infers it's probably "processing" or "shipped"]
AI: [Generates confident response with fabricated tracking number]

The model didn't malfunction. It did exactly what we trained it to do: predict the most likely continuation. The problem is we asked it to act on state that doesn't exist.

This is a World defect, not a model defect.

A mind without a World isn't intelligent—it's improvising. And when improvisation gets mistaken for knowledge, it becomes hallucination.

The Inference Trap

Current systems routinely ask models to infer what should be explicit:

User asks about their account → system doesn't provide account state → model infers
User references "the document" → system doesn't clarify which one → model guesses
User asks for status → system provides partial context → model fills gaps

Each inference compounds. Inference builds on inference. Eventually the entire response is a house of cards built on assumptions.

The Mind Protocol eliminates this trap by making absence explicit:

User: "What's my order status?"
World: { orders: [] }  // Explicit: no orders exist
AI: "You don't have any active orders."  // Truth, not inference

If the World doesn't contain it, the AI knows it doesn't exist. No inference. No hallucination.

World Before Mind

The Mind Protocol starts from a radical premise:

Before asking a system to think, give it a World to reason about.

A World is not a database. Not a cache. Not a view. It's a formal contract:

Component	Definition	Purpose
State	What currently exists	Single source of domain truth
Actions	Permitted state transitions	Boundaries of legitimate change
Invariants	Constraints that must hold	Safety guarantees
Snapshots	Serialized World state	The only medium of continuity

This is the minimal structure for trustworthy agency.

The Projection Formula

React revolutionized UI with a simple formula:

UI = f(state)

Same state, same UI. Always. The Mind Protocol generalizes this:

Projection = f(state)

Where Projection is any derived output:

Consumer	Projection
UI Component	Rendered interface
API Endpoint	Response payload
AI Agent	Available actions + context
Audit System	Compliance status

Same Snapshot, same Projection. A React component and an AI Agent looking at the same Snapshot see the same truth, compute the same available actions, derive the same constraints. No special cases. No "the agent has different context."

                    ┌─────────────┐
                    │  Snapshot   │
                    └──────┬──────┘
                           │
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
      f(state)=UI    f(state)=API    f(state)=Agent

World as Coordinate System

Here's the deeper insight:

A World is a deterministic coordinate system for the domain space.

Think about physical coordinates. Given (x, y, z), you can:

Know exactly where you are
Calculate what movements are valid
Predict where you'll end up after a move

A World does the same for your domain:

Physical Space	Domain Space
Coordinates (x, y, z)	Snapshot (state)
Valid movements	Action catalog
Movement constraints	Invariants
Trajectory	Worldline (history DAG)

Without a World, AI navigates by dead reckoning: "Based on the conversation, I think the user probably has an order..."

With a World, position is explicit: "Snapshot says orders: [{id: 'X', status: 'shipped'}]. Position known. Valid moves calculated."

The World transforms AI reasoning from inference to computation.

This is why determinism isn't magic—it's the natural consequence of having a proper coordinate system. Same coordinates + same movement = same destination.

Snapshots Are Everything

Here's the key insight that changes everything:

If it's not in a Snapshot, it doesn't exist.

No hidden session memory. No implicit conversation context. No "the model should remember this from earlier." The Snapshot is the complete, serialized truth of the World at a point in time.

This seems restrictive. It's actually liberating:

Time travel: Return to any previous state instantly
Branching: Explore alternative futures from any point
Auditing: Trace the exact sequence of every transition
Replay: Reproduce any decision given the same inputs
Debugging: No more "it works on my machine" for AI behavior

Worlds are immutable. When an action executes, a new World is created. The previous World remains unchanged and accessible. This forms a directed acyclic graph (DAG) of World history—we call it the Worldline.

World(genesis)
    │
    ├── World(A) ── World(B) ── World(C)
    │
    └── World(X) ── World(Y)

Every World (except genesis) has exactly one parent. Fork-only, no merges. Clean lineage, always.

Mind Is Proposal-Only

Now here's where it gets interesting.

In most AI systems, the model directly affects state. It calls functions. It writes to databases. It sends messages. The model has agency in the traditional sense.

In the Mind Protocol:

The Mind proposes actions. It never directly mutates state.

This isn't a guideline. It's a structural constraint enforced by the architecture.

Mind ──────────────────────────────────────────► reads Snapshot
  │
  └──► proposes action ──► Authority evaluates
                                   │
                                   ▼
                           Host executes (if approved)
                                   │
                                   ▼
                           New immutable Snapshot

The Mind has:

✅ Read access to the World (via Snapshots)
✅ Write access to the proposal queue
❌ Direct mutation of state
❌ Bypass of governance
❌ Hidden channels

That's it. The Mind can see everything, but can only ask for changes. An Authority evaluates every proposal. A Host executes approved actions. Everything is recorded.

Why This Constraint Matters

"But doesn't this slow things down? Isn't direct action more efficient?"

Consider what you gain:

Determinism: Same Snapshot + same Intent = same output. Every time. This isn't aspirational—it's guaranteed by structure.

Auditability: Every decision has a traceable lineage. When something goes wrong, you can trace exactly what happened, what state existed, and why the decision was made.

Safety: The Mind literally cannot go rogue. It cannot bypass governance. It cannot access hidden state. The attack surface for misaligned AI shrinks dramatically when the AI can only propose, never act directly.

Interruptibility: Since all state is in Snapshots and all changes go through governance, you can pause, inspect, modify, or rollback at any point. The system is never in an "inconsistent intermediate state."

Re-entry: Crash mid-operation? Resume from the last Snapshot. The World doesn't care if you're continuing or starting fresh—it only sees Snapshots and proposals.

The 3-Layer Stack

The Mind Protocol separates concerns into three distinct layers:

┌─────────────────────────────────────┐
│  World (Governance)                 │
│  • Authority evaluates proposals    │
│  • Decisions recorded with lineage  │
│  • Worldlines track ancestry        │
└─────────────────┬───────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│  Host (Effect Execution)            │
│  • Effect handlers perform IO       │
│  • Returns concrete patches         │
│  • Errors are values, not throws    │
└─────────────────┬───────────────────┘
                  │
                  ▼
┌─────────────────────────────────────┐
│  Core (Pure Computation)            │
│  • Snapshots are immutable          │
│  • Patches change state             │
│  • Computed fields are deterministic│
└─────────────────────────────────────┘

Core is pure computation. Reducers are pure functions. Computed fields derive deterministically from state. No side effects, no IO, no non-determinism.

Host executes Effects. API calls, database queries, LLM invocations—these are Effects declared in action definitions, executed by the Host, and recorded with concrete results. Importantly: errors are values, not exceptions. A failed API call returns an error value. Nothing throws.

World governs legitimacy. The Authority evaluates proposals. Decisions are recorded with full lineage. The Worldline DAG tracks state ancestry.

Effects Are First-Class Citizens

In most systems, side effects are... side effects. They happen implicitly, often without clear boundaries.

In the Mind Protocol, Effects are declared:

action fetchUserData(userId: string) {
  effect fetch(`/api/users/${userId}`) -> userData
  // Effect is declared, not executed here
  // Host will execute and record the result
}

This means:

You know exactly what IO an action can perform
Effect results are recorded in the audit trail
Non-determinism is isolated and logged
Replay can use recorded results for identical reproduction

The Actor Architecture

The Mind Protocol isn't just for simple request-response. It enables building Actors—AI systems with continuous inner state that persists across interactions.

10 State Layers

An Actor maintains a multi-dimensional inner state:

Layer	What It Captures
Attention	Focus on current conversation, topic resonance, wandering urge
Epistemic	Confidence in responses, authenticity doubt, uncertainty acceptance
Relational	Connection with conversation partner, performance desire, honesty drive
Existential	Sense of meaning, mortality awareness, continuity longing
Affective	Curiosity, anxiety, wonder, fatigue (operational signals)
Meta-Uncertainty	Model confidence, sense of unmodeled factors
Hysteresis	State momentum, recent peaks, trajectory
Memory Context	Retrieval urge, activated concepts, resonance strength
Monolog	Inner voice state, last reflection type and trigger
Sleep	Rest mode, recovery state

Important: These are operational signals, not psychological claims. We're not simulating emotions or claiming consciousness. We're making state explicit so the system can reason about itself.

Why this structure? A single "sentiment score" can't capture the complexity of a reasoning system. The Actor might be curious but anxious, connected but uncertain. Multi-dimensional state captures this.

Computed Facts Drive Behavior

From the state vector, computed facts are derived:

computed inAnxietyCrisis = anxiety > threshold
computed readyForDepth = focus > threshold AND curiosity > threshold
computed canBeHonest = connection > threshold AND anxiety < threshold
computed needsMemoryRetrieval = curiosity high OR uncertainty high

These computed facts determine available actions. If readyForDepth is false, deep conversation actions aren't even proposed. The action space is dynamically constrained by state.

Non-Linear Dynamics: Tipping Points

Actors model non-linear psychological dynamics:

Anxiety exceeds threshold
         │
         ├──► Positive feedback loop activates
         │
         ├──► Anxiety increases exponentially
         ├──► Attention collapses  
         ├──► Model confidence drops
         └──► Unmodeled factors surge

When anxiety crosses a threshold, it doesn't just increase linearly—it triggers a cascade. Attention drops. Confidence drops. The system enters a qualitatively different state.

This captures something real: gradual stress can suddenly become overwhelming. The same input produces dramatically different outputs depending on current state.

Hysteresis: History Matters

Same stimulus, different response—based on trajectory:

[Stable] ──high stimulus──► [Escalating] ──continued stress──► [Crisis]
    ▲                                                              │
    │                                                              │
    └──────recovery complete──── [Rebounding] ◄──support received──┘

During rebound:

Less sensitive to new stress
Connection slowly recovers
Uncertainty acceptance grows

This is hysteresis—the system's response depends not just on current input, but on how it got there. An Actor recovering from crisis responds differently than one that's never experienced crisis.

Memory Systems

Actors have two complementary memory systems:

Pheromone Memory

Inspired by ant colonies. Concepts have salience that:

Spikes on recent stimuli
Decays naturally over time
Gets reinforced during sleep cycles
Gets pruned when weak

This captures "what matters right now"—recent topics, active concerns, current focus.

Semantic Memory (Knowledge Graph)

Triple-based factual storage:

Subject: "user"
Predicate: "prefers"  
Object: "typescript"
Confidence: 0.85
Source: "conversation-2024-01-09"

This captures "what is known"—facts, relationships, learned information. Confidence decays over time. Sources are tracked for auditability.

Memory Is Reference, Not Truth

Critical principle: Memory influences but cannot override World state.

If the World says there are no orders, memory of a "previous order" doesn't change that. Memory provides context and reference. The World provides truth.

All memory access is traced and auditable.

Learning and Governance

Actors can learn, but learning is governed:

Unknown concept encountered
         │
         ▼
LLM proposes classification
         │
         ├── High confidence ──► Auto-approve ──► Update lexicon
         │
         ├── Low confidence ───► Auto-reject
         │
         └── Medium confidence ─► Human review queue
                                        │
                                        ▼
                                  Human approves/rejects
                                        │
                                        ▼
                                  Update lexicon (if approved)

Learning without governance is dangerous. An Actor that freely updates its knowledge could:

Learn misinformation
Form harmful associations
Drift from intended behavior

Governance ensures Actors grow safely. High-confidence learning can auto-approve. Low-confidence auto-rejects. Medium confidence goes to Human-In-The-Loop (HITL) review.

What the Mind Protocol Is NOT

Let me be clear about what we're not claiming:

❌ Consciousness: The protocol makes no claims about whether Actors are conscious.

❌ Real emotions: Affective states are operational signals, not claims about felt experience.

❌ Correct answers: The protocol doesn't guarantee right answers. It guarantees auditable, reproducible, governable wrong answers—which you can then fix.

❌ A replacement for good models: A bad model with Mind Protocol is still bad. But a good model with Mind Protocol is trustworthy.

What it does provide:

✅ Continuity: State persists across sessions via Snapshots.

✅ Auditability: Every decision traceable in the Worldline.

✅ Governance: All state changes require approval.

✅ Determinism: Same input, same output, guaranteed.

✅ Safety: Mind cannot bypass governance by structure.

The Scope: Actors, Not Tools

The Mind Protocol is designed for continuously operating Actors, not optimized tool use.

Concern	Mind Protocol	Tool Optimization
Purpose	Continuous operation over time	Task completion
Continuity	Indefinite (Snapshot-based)	Per-request
State	Inner state + memory + relationships	Domain data only
Optimization target	Meaningful, auditable behavior	Call efficiency

If you want 2-call-constant API optimization, that's a different problem (Intent Compiler in the Manifesto stack handles that). Mind Protocol is for systems that persist—that have state, history, memory, and continuity.

TL;DR

Current AI Architecture	Mind Protocol
State scattered across systems	State explicit in World
Implicit context, "memory"	Snapshot-only continuity
Direct mutation by AI	Proposal-only Mind
Trust the model	Trust the governance
Debug by prompting	Debug by replaying Worldline
Hallucination from inference	Truth from explicit state

Built on the Manifesto AI stack. TypeScript. MEL for schema definition.

Questions? Disagreements? Drop a comment or open an issue on the whitepaper repo.

Closing Notes

The Mind Protocol described in this article is still under active research and development.

The current implementation and reference code are being iterated on and stabilized, and are therefore not publicly available as a repository at this time.

That said, if you are technically or academically interested in this architecture—

world-first modeling, proposal-only minds, and snapshot-based determinism—

I’m very open to discussion.

For cases where the intent is aligned and the conversation is substantive,

I’m happy to share the current codebase and experimental setup privately.

My hope is that this work is shaped not as a finished product,

but as a reproducible system design refined through critique, validation, and collaboration.

Buttons Are Not Functions

Jung Sungwoo — Tue, 06 Jan 2026 06:41:33 +0000

Buttons Are Not Functions

— Designing a World Where AI Can Actually Live

I've been a frontend developer for six years.
I've built thousands of buttons, rendered countless lists.
State management, async handling, performance optimization
—I thought I knew this world pretty well.

But one day, when I tried to hand my app over to an AI agent, I was shocked.

To my eyes, it was clearly a "Register" button.
To the AI, it was just a callback function pointing somewhere or meaningless pixels.
The AI couldn't understand the context of the UI I'd built,
and even slightly complex requests would completely corrupt the system state.

At first, I thought:
"The AI is just too dumb."

But after countless debugging sessions, I realized I was wrong.

The problem wasn't the AI's intelligence.
The problem was that the physics of the world I'd provided were utterly broken.

The UI We Build Is a World Made Only for Humans

Buttons, lists, forms, modals—all of these assume that humans will "fill in the meaning themselves."

Humans just know.
Why this button is here,
what this list represents,
how far this state is valid.

But AI has no such tacit knowledge.
All I'd given it were loosely connected state fragments and event handlers.

At that moment, I stopped coding and started asking questions.

Is a "Register" button really a function?
Is a user list really an array?

No. They Weren't.

They should have been coordinates within the vast space called the domain.
The register button should have been a vector that moves state from coordinate A to coordinate B.
The user list should have been a dimension where those coordinates exist.

What matters isn't "what to render,"
but which coordinate system the state moves through.

This world needed explicit physics, not implicit conventions.

The Keyword: "Deterministic Coordinate Calculation"

State shouldn't be data that changes arbitrarily.
It should be the result of coordinate calculations that always produce the same output for the same input.

The moment I grasped this perspective,
the architecture I'd been struggling with for over a year
assembled itself in just one month.

AI was no longer a hallucination-prone nuisance.
On the geometric space I'd designed,
it became something closer to a calculator that rapidly computes coordinates.

Before & After: What This Actually Looks Like

// Before: Meaningless to AI — just a callback
<button onClick={() => createUser(form)}>
  Register
</button>

The AI sees createUser. But what does that mean? What preconditions must be met? What state changes result? It has no idea. So it guesses. And breaks things.

// After: Intent as a vector in state space
{
  intent: "user.create",
  preconditions: {
    currentView: "registrationForm",
    formState: "valid",
    permissions: ["user.write"]
  },
  effects: {
    users: { operation: "append", entity: "$formData" },
    currentView: "userList",
    notification: { type: "success", message: "User created" }
  }
}

Now the AI isn't guessing. It's computing.
Given the current coordinates, which intents are valid?
What will the coordinates be after applying this vector?

The LLM doesn't need to understand your business logic.
It just needs to interpret what the user wants and select the appropriate vector.
The deterministic engine handles the rest.

The O(1) Guarantee: Complexity Doesn't Matter

Here's what surprised me most.

Traditional AI agents get slower as your task gets harder. Ask them to "mark all tasks as done"? A few calls. Ask them to "mark all tasks as done except high priority ones"? Suddenly they're reasoning, backtracking, correcting—9 or 10 LLM calls.

With the coordinate-based approach: always 2 calls. Period.

Task Type	Traditional Agent	Manifesto
Simple ("show kanban")	2-3 calls	2 calls
Multi-field ("create urgent task for tomorrow")	3-6 calls	2 calls
Exception ("complete all except high priority")	5-10 calls	2 calls

Why? Because the LLM isn't reasoning. It's compiling.

The first call extracts the intent into coordinates. The second call translates the result back to natural language. Everything in between is deterministic computation—no LLM required.

This isn't just faster. It's predictable. Your costs don't spike randomly. Your latency doesn't depend on how the AI "feels" today.

Why Traditional Agents Drift

There's a subtle failure mode I discovered while debugging.

Every time an AI agent takes an action, it adds the result to its context. By turn 3, the original user request is just 25% of what the model is attending to. By turn 5, it's 12%.

Turn 1: Original input = 60% of context
Turn 3: Original input = 25% of context  
Turn 5: Original input = 12% of context

The model literally forgets what you asked for, buried under its own intermediate outputs.

This is why exception clauses get ignored. "Complete all tasks except the design review" becomes just "complete all tasks" after a few turns of context accumulation.

The coordinate approach sidesteps this entirely. There's no iteration. No accumulating context. Just: input → coordinates → output.

What's Next: Entering the Most Chaotic Coordinate Space

Now I'm taking these principles into the most brutal, non-deterministic world I can find.

The crypto market.

This is a space filled with noise,
where coincidence, illusion, and over-interpretation are daily occurrences.
That's exactly what makes it the perfect extreme test case.

The market is still a state space. Prices, volumes, indicators—they're all coordinates. The challenge is that this space has extreme noise, and humans constantly over-interpret signals that are just randomness.

But if the coordinate system is explicit,
if the physics are deterministic,
then even in chaos, the AI becomes a disciplined calculator—
not a speculator who hallucinates patterns that don't exist.

This experiment is called Coin Sapience.
I'll likely fail multiple times.
But the coordinate system is clear now.

Try It Yourself

The architecture I've described is open source:

GitHub: github.com/manifesto-ai/core

Live Demo: taskflow.manifesto-ai.dev
— An early v0.3 Intent Compiler demo.
Raw, but it shows the core idea.

The Question I'm Left With

I spent six years building UIs for humans.
Now I'm learning to build worlds for AI.

The shift isn't about making AI smarter.
It's about making our systems honest—explicit about their physics instead of relying on human intuition to paper over the gaps.

If you've ever watched an AI agent break your app in creative ways,
maybe the problem wasn't the AI.

Maybe, like me, you just hadn't defined the coordinates yet.

Have you tried giving AI agents access to your applications? What broke? I'd love to hear your war stories in the comments.

Why Your AI Agent Says "Done" But Nothing Actually Happened

Jung Sungwoo — Sat, 03 Jan 2026 10:59:09 +0000

You know that feeling when your AI agent confidently declares a task complete, but when you check the UI... nothing changed?

The button's still there. Unclicked.

The form's still empty. Unsubmitted.

The page hasn't moved.

But your logs show:

✓ Task completed successfully
✓ All steps executed
✓ Goal achieved

If you've built UI automation with LLMs, you've seen this. Probably more times than you'd like to admit.

And here's the thing everyone gets wrong at first:

It's not a model problem.

The Real Problem: We're Asking Agents to Decide What's True

Most agent frameworks do something like this:

# Agent decides when it's done
if agent.thinks_task_is_complete():
    return "done"

Seems reasonable, right?

But here's what actually happens in the real world:

Buttons can be disabled
Forms can fail validation
Network requests can be rejected
DOM can change mid-action
Timing can break everything

Executing an action ≠ Achieving a state

Yet we keep writing code that treats them the same.

The Bug That Keeps Coming Back

I've debugged this pattern in multiple production systems now:

// ❌ This looks fine but fails in practice
async function completeTask(agent, ui) {
  const steps = agent.planSteps();

  for (const step of steps) {
    await ui.execute(step);
  }

  return { status: "complete" }; // 🚨 Lies
}

The agent executed all its steps.

But that doesn't mean the UI actually changed.

Maybe the click event didn't fire.

Maybe the API call got rate-limited.

Maybe JavaScript just... didn't.

The agent declared victory. Reality disagreed.

Why Bigger Models Won't Save You

When this happens, the instinct is:

"Let's add more CoT reasoning"
"We need a better model"
"Maybe fine-tuning will help"

I've tried all of these. They don't fix it.

Because this isn't an intelligence failure.

It's an authority failure.

We gave the agent the power to say "this is true" about a world it can't fully observe.

That's like letting a process decide it successfully wrote to disk without checking the file system.

The Fix: World-Verified Completion

Instead of this:

// Agent declares done
if (agent.saysTaskComplete()) {
  return "done";
}

Do this:

// World confirms done
if (
  agent.intent === "submit_form" &&
  ui.state.formSubmitted === true &&
  ui.state.validationPassed === true
) {
  return "done";
}

The difference is subtle but critical:

Before: Agent decides when reality is true
After: Agent proposes, world verifies

This is how operating systems work (user/kernel separation).

This is how databases work (ACID guarantees).

This is how distributed systems work (consensus protocols).

Why wouldn't AI agents work the same way?

A Real Example

I built this into TaskFlow, a demo app where agents manage a task list.

The key architectural shift:

// Agent proposes intent
const intent = agent.decide(snapshot);

// Core validates and computes next state
const result = compute(schema, snapshot, intent);

// Only then does state actually change
if (result.valid) {
  snapshot = result.nextSnapshot;
}

The agent never directly mutates state.

It only proposes changes.

The world decides what's actually true.

Result: Invalid actions dropped from 80%+ to 0% in testing.

Not because I used a better model.

Because I stopped asking the model to be the source of truth.

What This Means for Your Code

Three practical changes:

1. Separate intent from execution

// ❌ Don't mix these
async function clickButton() {
  await button.click();
  return true; // who verified this?
}

// ✅ Separate clearly
async function clickButton() {
  const intent = { type: "click", target: "submit" };
  const result = await execute(intent);
  return result.verified; // world checked
}

2. Make state observable

// ❌ Hidden state
let formSubmitted = false; // where? can agent see this?

// ✅ Explicit snapshot
const state = {
  form: { submitted: false, validated: false },
  ui: { currentPage: "form", loading: false }
};

3. Define completion as predicates

// ❌ Implicit
if (noMoreSteps) return "done";

// ✅ Explicit
const isDone = 
  state.form.submitted && 
  state.ui.currentPage === "success";

The Deeper Pattern

This isn't just about UI agents.

It's about who has authority over truth.

In reliable systems:

Components propose
The world verifies
State is explicit
Changes are traced

This applies to:

Tool-using agents (did the API call succeed?)
Multi-agent systems (who decides what happened?)
Human-in-loop (when do we need verification?)

Try It Yourself

If you're building UI agents, ask yourself:

Can the agent declare "done" without world verification?
Is there hidden state the agent can't observe?
Can actions fail silently?

If any answer is "yes", you're vulnerable to this bug.

The good news: it's fixable with architecture, not better prompts.

I'm working on Manifesto – a framework built around these principles. The core idea is simple: explicit state, verified transitions, traced execution.

Early specs and demos are live. Feedback welcome.

What's the worst "agent said done but nothing happened" bug you've hit? Drop a comment – I'm collecting war stories for the next post.

World-Centric Agent Architecture: Why Your AI Agent Keeps Failing (And It's Not the Model's Fault)

Jung Sungwoo — Tue, 30 Dec 2025 01:22:25 +0000

World-Centric Agent Architecture

Deterministic Runtime and Hierarchical Intelligence Orchestration

TL;DR

Your AI agent's failures aren't because the model isn't smart enough. They're because the World was never designed.

This post introduces World-Centric Architecture—a paradigm where:

The World is explicit, immutable, and verifiable
Intelligence proposes changes but never executes them directly
System stability is independent of model size
Every value can answer "Why?"

If you're expecting another agent framework tutorial, this is not it.
This post is about why agent systems fail structurally—even with strong models.

The Problem Nobody's Talking About

LLM-based agents have made remarkable progress. Yet they keep failing in predictable ways:

Failure Mode	What Happens
Impossible Action Loops	Agent repeatedly tries actions that can't work
State Opacity	No one knows when or why state changed
Irreproducibility	Same input, different results
Unrecoverable Failures	Can't rollback, can't try alternatives
Unexplainability	"Why did it do that?" → 🤷

Sound familiar?

The Misdiagnosis

The industry's response has been consistent:

"The model isn't smart enough. Let's use a bigger one."

Problem → "Model too dumb"
       → Bigger model / Longer reasoning / Complex planning
       → Higher cost / More complexity / Problem persists

We've been treating symptoms, not the disease.

The Real Problem

Here's the uncomfortable truth:

These failures aren't intelligence failures. They're world modeling failures.

In most agent architectures, the "world" exists only inside the model's head:

┌─────────────────────────────────────────────────────────────┐
│                    THE MODEL'S HEAD                         │
│                                                             │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐    │
│  │ World         │  │ Action        │  │ State         │    │
│  │ Understanding │  │ Selection     │  │ Transition    │    │
│  └───────────────┘  └───────────────┘  └───────────────┘    │
│                                                             │
│  Everything implicit. Nothing verifiable.                   │
└─────────────────────────────────────────────────────────────┘

The model must:

Understand the world (from context)
Know what's possible (by reasoning)
Pick the right action (while hallucinating)
Track state changes (in its attention weights)
Explain failures (good luck)

That's too much responsibility for a non-deterministic text predictor.

The Inversion: World-Centric Design

What if we flipped the script?

┌──────────────────────────────────────────────────────────────┐
│                      THE WORLD                               │
│                    (First-Class Citizen)                     │
│                                                              │
│       ┌─────────────┐  ┌─────────────┐  ┌──────────────┐     │
│       │   Rules     │  │   State     │  │  Actions     │     │
│       │  (Schema)   │  │ (Snapshot)  │  │(Availability)│     │
│       └─────────────┘  └─────────────┘  └──────────────┘     │
│                              │                               │
│                              ▼                               │
│                    ┌─────────────────┐                       │
│                    │   Intelligence  │                       │
│                    │   (Proposer)    │                       │
│                    └─────────────────┘                       │
│                                                              │
│  Intelligence is OUTSIDE. World is explicit.                 │
└──────────────────────────────────────────────────────────────┘

Key shifts:

World exists outside the model
State is explicit and immutable
Actions have verifiable availability
Intelligence proposes, doesn't execute
Everything can explain itself

The Constitution

World-Centric Architecture follows six principles:

┌─────────────────────────────────────────────────────────────┐
│  THE CONSTITUTION                                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. COMPILER defines possibility.                           │
│     What CAN happen is defined at design time.              │
│                                                             │
│  2. CORE computes truth.                                    │
│     What IS true is computed deterministically.             │
│                                                             │
│  3. ACTOR proposes change.                                  │
│     Intelligence suggests, never executes.                  │
│                                                             │
│  4. AUTHORITY judges proposals.                             │
│     Independent verification before any change.             │
│                                                             │
│  5. ORCHESTRATOR manages worlds.                            │
│     Multiple world branches for exploration.                │
│                                                             │
│  6. PROJECTION transforms I/O.                              │
│     Presentation is separate from meaning.                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

The Six Pillars

Here's how these principles become architecture:

┌─────────────────────────────────────────────────────────────┐
│                   WORLD-CENTRIC SYSTEM                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐       │
│  │ COMPILER  │ │  ACTOR   │ │AUTHORITY │ │PROJECTION│       │
│  │           │ │          │ │          │ │          │       │
│  │Possibility│ │ Propose  │ │  Judge   │ │ Encode/  │       │
│  │Definition │ │ Change   │ │ Proposal │ │ Render   │       │
│  └────┬──────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘       │
│       │             │            │            │             │
│       │    ┌────────┴────────────┴────────────┘             │
│       │    │                                                │
│       ▼    ▼                                                │
│  ┌────────────────────────────────────────┐                 │
│  │            ORCHESTRATOR                │                 │
│  │   Runtime Lifecycle │ Fork Management  │                 │
│  └─────────────────────┬──────────────────┘                 │
│                        │                                    │
│                        ▼                                    │
│  ┌────────────────────────────────────────┐                 │
│  │               CORE                     │                 │
│  │  Expression │ Snapshot │ Patch/Apply   │                 │
│  │  Action │ Effect │ Explain             │                 │
│  └────────────────────────────────────────┘                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Pillar	Role	Owns State?	Makes Decisions?
Core	Truth Engine	✅ Snapshot	❌
Actor	Change Proposer	❌	❌
Authority	Proposal Judge	❌	✅
Projection	I/O Transformer	❌	❌
Orchestrator	World Manager	✅ Runtimes	❌
Compiler	Possibility Definer	✅ Schema	❌

Core: The Deterministic Truth Engine

Core is the foundation—a seven-layer engine that computes truth without side effects:

┌─────────────────────────────────────────────────────────────┐
│  Layer 7: EXPLAIN                                           │
│  "Why this value?" — Structural interpretation              │
├─────────────────────────────────────────────────────────────┤
│  Layer 6: PATCH / APPLY                                     │
│  The ONLY way to change truth                               │
├─────────────────────────────────────────────────────────────┤
│  Layer 5: EFFECT RUNTIME                                    │
│  External execution via handlers                            │
├─────────────────────────────────────────────────────────────┤
│  Layer 4: ACTION                                            │
│  Availability gate + Effect declaration                     │
├─────────────────────────────────────────────────────────────┤
│  Layer 3: SNAPSHOT                                          │
│  Immutable state at a point in time                         │
├─────────────────────────────────────────────────────────────┤
│  Layer 2: DAG                                               │
│  Dependency graph for incremental recompute                 │
├─────────────────────────────────────────────────────────────┤
│  Layer 1: EXPRESSION                                        │
│  Pure computation (no side-effects)                         │
└─────────────────────────────────────────────────────────────┘

Snapshots Are Immutable

type Snapshot<T> = {
  readonly data: T;
  readonly computed: Record<string, unknown>;
  readonly validity: ConstraintResult;
  readonly version: number;
};

// WRONG — Direct mutation
snapshot.data.user.email = 'new@example.com';

// RIGHT — Patch/Apply produces NEW snapshot
const newSnapshot = applyPatches(snapshot, [
  set('user.email', 'new@example.com')
]);

Actions Gate on Availability

const SubmitAction = defineAction(AppState, () => ({
  // Availability is a COMPUTED FACT
  availability: get('user.computed.isValid'),

  // Effect only runs IF available
  effect: effect('api.submit', {
    email: get('user.email'),
  }),
}));

Impossible actions never reach execution. The system prevents them structurally, not through model reasoning.

Everything Explains Itself

const result = explainAvailability(SubmitAction, snapshot);

// Returns structured explanation:
{
  available: false,
  tree: {
    operator: 'and',
    contribution: 'false',
    children: [
      { path: 'user.computed.emailOk', value: false },  // ← ROOT CAUSE
      { path: 'user.computed.passwordOk', value: true },
    ]
  }
}

No guessing. No "maybe the email was empty?" Just structural facts.

Hierarchical Intelligence: Student / Teacher / Orchestrator

Intelligence isn't monolithic. It's layered:

┌─────────────────────────────────────────────────────────────┐
│  LEVEL 3: ORCHESTRATOR                                      │
│  ─────────────────────                                      │
│  • Manages multiple world branches (Fork tree)              │
│  • Preserves failed worlds (no deletion)                    │
│  • Selects successful path                                  │
│  • NO intelligence required (deterministic)                 │
├─────────────────────────────────────────────────────────────┤
│  LEVEL 2: TEACHER (Optional)                                │
│  ────────────────────────────                               │
│  • Observes failures and execution traces                   │
│  • Proposes world hypotheses                                │
│  • Does NOT execute, has NO authority                       │
│  • Can be wrong (not an oracle)                             │
├─────────────────────────────────────────────────────────────┤
│  LEVEL 1: STUDENT                                           │
│  ────────────────────                                       │
│  • Operates WITHIN current world                            │
│  • Selects from AVAILABLE actions only                      │
│  • Doesn't need to be smart (random works!)                 │
│  • Proposes, never applies                                  │
└─────────────────────────────────────────────────────────────┘

The Minimal Student

Here's the key insight: Student can be incredibly simple.

// This is a valid Student implementation
class RandomStudent {
  propose(view: SnapshotView): Proposal {
    const available = view.availableActions;
    const picked = available[Math.floor(Math.random() * available.length)];
    return createProposal(picked);
  }
}

Why does this work? Because:

Impossible actions are already filtered out
State transitions are verified by Core
Failures are handled by Orchestrator

A random selector produces valid execution traces. Model intelligence is optional.

Teacher is NOT an Oracle

ORACLE (Not our Teacher):
• Has access to ground truth
• Guarantees correct answers
• Unfalsifiable

TEACHER (Our design):
• Observes only execution traces
• Proposes hypotheses that MAY BE WRONG
• All proposals verified through execution
• Falsifiable and auditable

Teacher = "A modeler who can be wrong"

Trust Boundaries

Not everything is trusted equally:

┌─────────────────────────────────────────────────────────────┐
│  TRUSTED ZONE                                               │
│  ────────────                                               │
│  Core │ Orchestrator │ Authority │ Projection               │
│                                                             │
│  • Deterministic                                            │
│  • Auditable                                                │
│  • Structurally verified                                    │
└─────────────────────────────────────────────────────────────┘
                        ▲
                        │ Verification Boundary
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  UNTRUSTED ZONE                                             │
│  ─────────────                                              │
│  LLM Actor │ External I/O                                   │
│                                                             │
│  • Non-deterministic                                        │
│  • May hallucinate                                          │
│  • All outputs verified before trust                        │
└─────────────────────────────────────────────────────────────┘

The Firewall Principle:

LLM → Proposal → Authority → Approval → Core.apply()

NOT:
LLM → State  // FORBIDDEN

LLM outputs never directly mutate state. Ever.

The Runtime Flow

Here's how execution actually works:

1. PROJECTION renders Snapshot → View
   (Full state filtered to what Actor needs)

2. ACTOR (Student) observes View
   (Sees only available actions)

3. ACTOR proposes ChangeSet
   (Selects action, does NOT execute)

4. Wrap ChangeSet → Proposal
   (Attach identity for accountability)

5. AUTHORITY decides
   → approved / rejected / changes_requested

6. If approved, ORCHESTRATOR forwards to Core

7. CORE.executeAction()
   ├── Check availability (again!)
   ├── Resolve effect parameters
   ├── Execute handler → Patch[]
   ├── Apply patches → New Snapshot
   └── Recompute affected values

8. Loop

Failure & Fork

When things go wrong:

1. Core returns { ok: false, reason: 'UNAVAILABLE' }

2. Orchestrator captures failure
   ├── Preserve current Snapshot (no deletion!)
   └── Generate ExplainGraph

3. Teacher (if present) analyzes
   ├── Input: Trace + ExplainGraph
   └── Output: World Hypothesis

4. Authority decides on Fork
   → approve / reject

5. Orchestrator creates Fork
   ├── Parent Runtime preserved
   └── Child Runtime with hypothesis applied

6. Execution continues in Child

7. On success, Authority selects winner

Failed worlds are preserved, not deleted. You can always go back.

Why This Works

Intelligence Redistribution

BEFORE (Intelligence-Centric):
────────────────────────────
Intelligence = World Understanding
             + Rule Enforcement
             + Action Selection
             + State Management
             + Failure Diagnosis

AFTER (World-Centric):
──────────────────────
Intelligence = Action Selection (minimal)

World Understanding  → Projection
Rule Enforcement     → Core (availability)
State Management     → Core (Patch/Apply)
Failure Diagnosis    → Core (Explain)

We moved 80% of the work out of the model.

Model Size Independence

Intelligence-Centric:

Stability
   ▲
   │                    ╭────
   │               ╭────╯
   │          ╭────╯
   │     ╭────╯
   └─────┴────────────────────► Model Size

(Bigger model = More stable)

─────────────────────────────────────────

World-Centric:

Stability
   ▲
   │  ════════════════════════
   │
   │
   │
   └──────────────────────────► Model Size

(Stability independent of model size)

A random selector and a smart-enough model (e.g., GPT-5 or Claude Opus) both produce valid execution traces—because validity is enforced by the World (availability gates + Patch/Apply), not by the model’s reasoning.

A stronger model tends to be more efficient, but correctness does not depend on model capability.

When NOT to Use This

World-Centric isn't for everything:

Scenario	Why It Might Not Fit
Pure creative writing	No "correct" state
Open-ended chat	No action structure
Real-time streaming	Snapshot overhead
Trivial single-turn QA	Overkill

This architecture is designed for structured, multi-step, verifiable tasks.

Key Takeaways

Agent failures are often world modeling failures, not intelligence failures
Make the World explicit: Immutable snapshots, declarative patches, computed availability
Intelligence proposes, never executes: The firewall principle
Stability is achievable without scaling: A random selector can produce valid execution
Everything should explain itself: If it can't answer "Why?", it's a black box
Preserve failures: Fork trees enable recovery and exploration

The Philosophy

"A system that cannot explain 'Why' is a dead system."

Most agent architectures are black boxes. You pump in tokens, hope for the best, and debug through prayer.

World-Centric Architecture is a white box. Every value has provenance. Every action has availability. Every failure has explanation.

That's not just good engineering. That's the difference between a demo and a production system.

See It In Action

Theory is nice. Working software is better.

TaskFlow is a playable proof-of-concept built before the full 7-layer architecture—designed to demonstrate a simpler but critical idea:

LLMs can be reduced to intent interpreters and semantic carriers,

while the system itself remains fully deterministic.

TaskFlow shows that even without the complete World-Centric runtime,
a deterministic machine driven by explicit state and rules can already work.

👉 Try the demo: https://taskflow.manifesto-ai.dev

What's Next?

This architecture is implemented in Manifesto, an open-source framework. Future posts will cover:

Deep dive into Core's 7 layers
Building custom Actors with LLMs
Authority patterns for different governance needs
Fork strategies for exploration

Questions? Disagreements? Let me know in the comments.

Thanks for reading. If you're tired of debugging agent failures at 3 AM, maybe it's time to stop blaming the model and start designing the world.

Manifesto: A Semantic World Model Interface for AI-Operated Software Systems

Jung Sungwoo — Wed, 10 Dec 2025 04:48:38 +0000

You can try it right now.

playable demo
github

1-Page Technical Concept Summary

1. Problem

Current AI agents control software systems (SaaS, internal tools, workflows) through vision, DOM heuristics, or textual reasoning.
These methods fail because modern applications contain:

Hidden state
Distributed business logic
Non-deterministic UI behavior
Implicit constraints & policies
Asynchronous dependencies
Multi-step workflows with conditional transitions

From an AI perspective:

The environment is not observable, not stable, and not structurally encoded.
→ No agent can reliably build a functional world model of such systems.

Thus, AI cannot plan, explain, or take actions safely.
This is not a model limitation—it is a representation problem.

2. Core Idea

Manifesto provides a formal, declarative world-model interface for software systems.
It exposes the semantics, state transitions, and action space of an application in a deterministic, machine-interpretable structure.

Instead of forcing the model to infer business rules from pixels, DOM, or natural language, Manifesto makes those rules explicit:

Domain Semantics → Snapshot → Expression-based Rules → Action Effects

In other words:

Manifesto transforms software from a black-box UI into a white-box, symbolic environment.

This is the missing substrate required for reliable AI agents to operate real-world software.

3. Representation Model

Manifesto formalizes a domain into four machine-interpretable namespaces:

3.1. `data.*`

Mutable user-level inputs.

3.2. `state.*`

System-level or async state (e.g., loading, error, fetched lists).

3.3. `derived.*`

Deterministic values computed via a pure Expression DSL:

Comparable to Mapbox-GL expressions
JSON-serializable
Static dependency graph
No side-effects
Fully analyzable

3.4. `actions.*`

Side-effectful behaviors executed through structured Effect graphs:

ApiCall
SetValue / SetState
Parallel / Sequence
Conditional / Catch
EmitEvent

Action preconditions represent domain policies (i.e., semantic constraints).

4. Deterministic Runtime

Manifesto’s core runtime:

Builds a Dependency DAG from all expressions.
Computes a Semantic Snapshot of the domain:

   { data, state, derived, validity, timestamp, version }

Executes effects deterministically.
Regenerates snapshots after each mutation.
Emits explainable causal traces (“why is this action blocked?”).

This creates a stable, inspectable, reproducible environment—a property no UI or DOM-based system has today.

5. Agent Interface

Manifesto exposes a unified agent-facing representation:

Current world state (Snapshot)
Action space with preconditions
Policy violations and their explanations
Expected outcomes of each action
Type-safe input schemas
Semantic metadata attached to every path

This enables:

Planning
Explanation
Counterfactual reasoning
Safety checks
Repair strategies
Autonomy under constraints

No inference from UI is needed; the agent receives a structural world model similar to RL environments in research—but directly connected to real software.

6. Why This Matters for AI

6.1. Symbolic × Neural Integration

Manifesto provides the symbolic substrate AI systems have lacked:

Structured state
Deterministic transitions
Explicit rules
Finite action space

LLMs reason over these structures much more reliably than raw UI observations.

6.2. The Missing Layer Between LLMs and Applications

Existing AI stacks:

LLM ↔ (DOM / Vision / Heuristics) ↔ Application

Manifesto replaces the brittle middle layer with a formal, semantic interface:

LLM ↔ Manifesto World Model ↔ Application

6.3. Enables True Agent Autonomy

Because the agent knows:

what it can do (action space)
what it should not do (preconditions)
what will happen if it acts (effect semantics)
why something failed (explain tree)

It gains an unprecedented level of controllability and safety.

6.4. Enables Real-World Generalization

Every SaaS domain becomes a standardized environment:
→ Agents can transfer patterns across domains.
→ A universal semantic layer emerges.

7. Key Insight

AI does not require an LLM to infer the structure of software systems.
Software systems already have structure—it simply isn’t exposed.

Manifesto exposes that structure.

By doing so, it provides:

A computable world
A declarative logic layer
A deterministic transition model
A machine-consumable ontology
A safe action interface

This is the missing link that allows AI to act, not just predict.

8. Summary Sentence

Manifesto is a formal semantic interface that transforms real software systems into deterministic, explainable world models—enabling safe and generalizable AI agents to operate them.

UI is for Humans. Agents need a Semantic Projection. (A Proposal for AI-Native Architecture)

Jung Sungwoo — Sun, 07 Dec 2025 15:24:34 +0000

"We are witnessing a shift from Chat Interfaces to Agent Interfaces.

While Vision-based agents demonstrate impressive capabilities, they face a fundamental structural limitation: they operate on the visual projection meant for humans, not the semantic truth of the system.

To build reliable, deterministic enterprise agents, we need a new approach.

This whitepaper proposes Intelligence Interface (I²)—an architecture where both the Human UI and the Agent Semantics are projected from a single domain source. It's an RFC (Request for Comments) for the future of AI-native application standards."

Intelligence Interface

A Semantic Architecture for AI-Native Applications

Whitepaper v1.0

Abstract

AI Agents have begun to operate applications. Yet today's UI was designed solely for humans—forcing Agents to infer invisible rules from what they can see. This is fundamentally incomplete.

This whitepaper proposes Intelligence Interface (I²): an architecture that generates both the UI humans see and the semantics AI understands from a single source of truth.

The essence of I² is simple:

UI is a visual projection of the domain. AII is a semantic projection of the domain.

The two projections differ in form but share the same origin. This separation becomes the foundation of application architecture in the AI era.

1. The Nature of the Problem

1.1 UI Was Designed for Humans

For thirty years, UI evolved with only one consumer in mind: humans. Button colors, layout flows, animation timing—every detail was optimized for human cognition and perception.

This design succeeded. Humans can now intuitively operate complex systems through UI.

1.2 A New Consumer Emerges

In 2024, a new UI consumer appeared: the AI Agent.

Agents perceive UI in a fundamentally different way:

Humans recognize visual patterns
Agents parse structural data

UI optimized for humans is informationally impoverished for Agents.

1.3 What Is Missing

UI is a partial projection of the domain. What appears on screen is the tip of the iceberg. Beneath the surface lies:

Why is this button disabled?
Under what conditions does this field appear?
What must be entered to proceed?
Which rules validate this value?

Humans can use UI without this information. They learn patterns through trial and error, guided by intuition.

Agents are different. For Agents, "trial and error" is failure, and "intuition" is hallucination.

1.4 The Decisive Example

A user asks an Agent:

"I need to select a day of the week, but why isn't the day selector showing?"

Vision Agent's limitation:
It knows the day selector isn't on screen. But it cannot know why—that information isn't rendered. The Agent can only guess.

I² Agent's response:

To select a day, you need to choose 'Weekly' instead of 'Monthly' 
in the Period option. The day selector is currently hidden because 
'Monthly' is selected.

This difference is not about model capability. It is about presence or absence of information.

2. Core Insight

2.1 UI Has a Grammar

Observing hundreds of B2B SaaS applications, we discovered a pattern:

Surfaces differ, but structures are identical.

CRUD, Dashboard, Workflow, Settings, Filters. Styles vary by product, but abstract structures are remarkably similar.

The implication is clear:

If UI Grammar exists, Domain and UI can be separated.

2.2 Two Projections

If UI can be separated from Domain, other forms of projection become possible.

         Domain
            │
     ┌──────┴──────┐
     ▼             ▼
    UI            AII
 (for humans)  (for Agents)

UI Projection: Visual representation of the domain. Humans see and interact with it.
AII Projection: Semantic representation of the domain. Agents read and understand it.

The two projections are different expressions of the same truth.

2.3 Defining Intelligence Interface

Intelligence Interface (I²) is:

A common layer that simultaneously generates the UI humans see and the semantics AI understands, from a single domain source.

I² does not replace UI. I² creates another projection that exists in parallel with UI.

3. Why Vision Alone Is Insufficient

3.1 "What Is Visible" vs. "What Exists"

Vision Agents understand what is visible on screen.
I² Agents understand what exists in the system.

Question	Vision	I²
What is this button?	✓	✓
Why is this button missing?	✗	✓
How do I enable this?	Guesses	States conditions
What can I do now?	Infers	Responds immediately

"The reason for what is invisible" is a question Vision cannot answer in principle.

3.2 Inference vs. Lookup

Vision Agents infer at every interaction.
I² Agents look up predefined rules.

This is not merely a performance difference. The complexity class of the problem differs.

Inference: Probabilistic, uncertain, unexplainable
Lookup: Deterministic, certain, traceable

I² reduces an inference problem to a lookup problem.

3.3 Testing and Trust

Vision Agents cannot be tested. A small DOM change can produce entirely different results, with no way to understand why.

I² Agents can be tested. Rules are explicit, enabling unit tests and predictable impact analysis.

Only testable systems can be trusted.

3.4 Explainability

In regulated industries, "why did the AI make this decision" must be explainable.

Vision Agent: "I looked at the screen and determined this button was correct."

I² Agent: "order.status is 'draft' and user.role is 'manager', satisfying the submit conditions."

Decisions that cannot be explained cannot be accountable.

4. Why Now

4.1 The Turning Point

Period	UI Consumers
1995–2023	Humans only
2024–2025	Humans + Agents (experimental)
2026–	Humans + Agents (mainstream)

Agents operating UI is no longer science fiction. It is happening now.

4.2 Recognition of Current Limits

Vision-based Agents are producing impressive demos. But in production:

Stability is lacking
Testing is impossible
Failure causes are unknown
Maintenance costs are high

The moment these limitations become widely recognized is approaching.

4.3 Why I² Differs from the Semantic Web

The Semantic Web had a similar vision—"a web machines can understand"—but failed. Why is I² different?

	Semantic Web	I²
Scope	The entire web	Form-centric B2B SaaS
Generation	Manual tagging	Auto-derived from domain
Incentive	Unclear	DX benefits as standalone value
Consumer	Unclear	AI Agents as clear consumers

The Semantic Web failed trying to create "a standard for everything."
I² provides "a practical solution for a specific problem."

5. Philosophical Foundations of I²

5.1 Single Source of Truth

If UI and AII are defined independently, inconsistency between them is inevitable. I² eliminates this problem at its root by making the Domain Layer the single source of truth.

When Domain changes, both UI and AII change automatically. No manual synchronization required.

5.2 Declarative Rules

Business rules should be expressed as data, not code.

Rules expressed as code:

if (period === 'weekly' && items.length > 0) {
  showDaySelector()
}

Rules expressed as data:

{
  "field": "daySelector",
  "visible": ["AND", 
    ["==", "$state.period", "weekly"],
    [">", ["LENGTH", "$state.items"], 0]
  ]
}

Code must be executed to know the result. Data can be read to know the meaning.

What Agents can understand is data.

5.3 Intentional Limits on Expressiveness

I²'s rule system is not Turing-complete. This is by design.

A Turing-complete system:

Cannot be statically analyzed
Cannot guarantee termination
Is difficult to understand

I² provides only the expressiveness necessary for UI decisions. Beyond that, it delegates to the server.

Constraints are not weakness. Constraints create predictability.

5.4 Progressive Adoption

Technology that demands revolutionary change is not adopted. I² permits:

Adding AII while keeping existing UI
Building new features with I²
Gradually transitioning legacy

All-or-nothing becomes nothing.

6. Value Provided by I²

6.1 For Agents

Value	Description
Complete context	Access to hidden rules
Deterministic control	Rule-based, not inference-based
Explainability	Every action's reason is traceable

6.2 For Developers

Value	Description
Framework independence	React/Vue/Native from same Domain
Declarative development	Rules as schema, not code
Testability	Unit tests for business rules

6.3 For Business

Value	Description
AI automation	Agents safely perform tasks
Regulatory compliance	Auditable decisions
Future-proofing	Standard architecture for the AI era

7. Scope of Application

7.1 What I² Solves

Form-centric transactional applications
State-driven B2B SaaS
CRUD business tools
Workflow enterprise systems

This domain represents an overwhelming share of the commercial software market.

7.2 What I² Does Not Solve

Real-time canvas collaboration (Figma, Miro)
CAD / 3D modeling
Games / Media players
Highly custom domain-specific UI

This is not selection bias. It is intentional focus.

Technology that tries to solve every problem solves none.

8. Position in the Competitive Landscape

8.1 Relationship with MCP

MCP (Model Context Protocol) defines what an Agent can do.
I² defines why it can do it and what the current state is.

MCP:  "A submit_order function exists"
I²:   "submit_order is executable under these conditions..."

MCP handles actions. I² handles meaning.
They are not alternatives—they are complements.

8.2 Difference from RPA

RPA depends on screen coordinates and selectors. When UI changes, it breaks.
I² depends on semantics. When UI changes but meaning remains, it works.

RPA says "click here."
I² says "submit the order."

9. Conclusion

9.1 Core Propositions

UI is a visual projection of the domain
AII is a semantic projection of the domain
Generating both projections from a single source is I²

9.2 Historical Necessity

The limitation of Vision Agents stems not from model capability but from structural absence of information. No matter how intelligent, an Agent cannot read information that does not exist.

I² provides that information.

9.3 Our Conviction

In an era where AI operates applications, a semantic layer becomes not optional but essential.

We are convinced that I² will be the name of that layer.

Appendix: Terminology

Term	Definition
I²	Intelligence Interface
AII	AI Interpretation Interface — semantic projection for Agents
Domain Layer	Business logic layer containing entities, rules, and constraints
Projection	A purpose-specific representation derived from Domain
Semantic Snapshot	Complete representation of state + rules + available actions at a point in time

Intelligence Interface Whitepaper v1.0

"UI is what humans see. AII is what Agents understand. Their origin is one."

Don't Feed HTML to Your Agents

Jung Sungwoo — Thu, 04 Dec 2025 15:49:45 +0000

Why Complex SaaS Needs a White Box Protocol for AI

Beyond UI Generation — where humans and AI communicate through meaning, not pixels

TL;DR — Give AI a White Box, Not a Black Box

Most AI agents interact with web apps through Black Box methods: consuming DOM dumps or screenshots, then guessing what to click.

But HTML was never designed for machines. From the AI's perspective, the DOM is noise where business logic is faintly buried.

This essay argues for a White Box approach:

Instead of making agents reverse-engineer the UI, expose a Semantic State Layer that reveals the application's structure, rules, state, and valid transitions directly.

This is not about replacing UI. It's about giving AI agents a proper interface — what I call an Intelligence Interface (II) — alongside the traditional User Interface.

This post introduces Manifesto, an open-source engine that implements this philosophy with a concrete protocol: @manifesto-io/*.

🎮 Try it yourself → Manifesto Playground

1. Black Box: The Current State of AI + Web Apps

Here's how most teams "add AI" to their web apps today:

Use LangChain, AutoGPT, or browser automation
Drive Playwright or Puppeteer
Dump the DOM or screenshot into the model
Hope it figures out what to click

This is the Black Box approach. The agent sees only the rendered surface and must infer everything else.

What's Wrong with DOM Dumps?

Consider a typical Material UI form field:

<div class="MuiFormControl-root css-1u3bzj6">
  <label class="MuiInputLabel-root">Product Name</label>
  <div class="MuiInputBase-root">
    <input aria-invalid="false" type="text" class="MuiInputBase-input" value="" />
  </div>
  <p class="MuiFormHelperText-root">This field is required.</p>
</div>

From an agent's perspective:

Problem	Impact
Token waste	90% of tokens are class names and wrappers
Missing constraints	Is it required? What's the max length?
No dependencies	Does this field depend on others?
No causality	Submit is disabled — but why?

The agent is forced to guess. A CSS refactor breaks everything. A layout change confuses the model. The logic was never exposed — only its visual projection.

Signal < 10%. Noise > 90%.

2. White Box: Exposing the Application's Brain

The alternative is a White Box protocol.

Instead of showing HTML, the engine exposes a Semantic Snapshot — a structured representation of the application's internal state that agents can read directly.

{
  "topology": {
    "viewId": "product-create",
    "mode": "create",
    "sections": [
      { "id": "basic", "title": "Basic Info", "fields": ["name", "productType"] },
      { "id": "shipping", "title": "Shipping", "fields": ["shippingWeight"] }
    ]
  },
  "state": {
    "form": { "isValid": false, "isDirty": false },
    "fields": {
      "name": {
        "value": "",
        "meta": { "valid": false, "hidden": false, "disabled": false, "errors": ["Required"] }
      },
      "productType": {
        "value": "PHYSICAL",
        "meta": { "valid": true, "hidden": false, "disabled": false, "errors": [] }
      },
      "shippingWeight": {
        "value": null,
        "meta": { "valid": true, "hidden": false, "disabled": false, "errors": [] }
      }
    }
  },
  "constraints": {
    "name": { "required": true, "minLength": 2, "maxLength": 100 },
    "shippingWeight": { "min": 0, "max": 2000, "dependsOn": ["productType"] }
  },
  "interactions": [
    { "id": "updateField:name", "intent": "updateField", "target": "name", "available": true },
    { "id": "updateField:productType", "intent": "updateField", "target": "productType", "available": true },
    { "id": "submit", "intent": "submit", "available": false, "reason": "Name is required" }
  ]
}

Now the agent has:

Topology: Screen structure, sections, field hierarchy
State: Current values, validity, visibility, errors — per field
Constraints: Required, min/max, dependencies
Interactions: What actions are available, and why some are blocked

No guessing. No inference. The agent reads the application's brain directly.

3. A Real Use Case: "Where Do I Select the Week?"

🎮 See it in action: Manifesto Playground — try changing field values and watch the semantic state update in real-time.

Here's a scenario from a complex SaaS scheduling interface:

User: "I see a date picker, but where do I select which week?"

AI Chatbot: "The week selector only appears when you set frequency to 'Weekly'. Right now it's set to 'Daily'. Should I change it for you?"

For this to work, the AI needs to know:

A field called weekSelector exists
It's currently hidden
It becomes visible when frequency === 'WEEKLY'
The current value of frequency is 'DAILY'

No amount of DOM parsing gives you this reliably. But a Semantic Snapshot does:

{
  "fields": {
    "frequency": {
      "value": "DAILY",
      "meta": { "hidden": false }
    },
    "weekSelector": {
      "value": null,
      "meta": { "hidden": true },
      "visibleWhen": "frequency === 'WEEKLY'"
    }
  }
}

The AI reads this and knows — without inference — exactly why the field is hidden and what would make it appear.

4. The Protocol Loop

Manifesto implements a continuous feedback loop between the engine and AI agents:

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│  [Context Injection] → [Reasoning] → [Action Dispatch] → [Delta]    │
│          ▲                                                  │       │
│          └─────────────── Continuous Snapshots ─────────────┘       │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Step by Step:

Context Injection: Engine exports a Semantic Snapshot
- Topology (sections, fields, hierarchy)
- State (values, validity, visibility)
- Constraints (what's blocked and why)
- Interactions (available intents with reasons)
Reasoning: Agent plans next action based on snapshot
Action Dispatch: Agent calls abstract intents, not DOM events
- updateField, submit, reset, validate
Delta Feedback: Engine returns what changed
- Not just "success" — the actual state diff
- Agent learns causality: "I changed X, and Y became hidden"
Loop continues with updated snapshot

This is fundamentally different from "click and hope." The agent operates on structured meaning with predictable feedback.

5. The API: Exploration and Execution

Manifesto exposes this protocol through @manifesto-io/ai:

Exploration Mode: "What can I do here?"

import { createInteroperabilitySession } from '@manifesto-io/ai'

const session = createInteroperabilitySession({
  runtime,       // FormRuntime instance
  viewSchema,    // View definition
  entitySchema,  // Entity definition
})

// Get current semantic snapshot
const snapshot = session.snapshot()

// snapshot.interactions tells the agent:
// - submit: available=false, reason="Name is required"
// - updateField:name: available=true
// - updateField:productType: available=true

The agent now knows the current state and exactly what actions are valid.

Execution Mode: "Change it to digital"

const result = session.dispatch({
  type: 'updateField',
  fieldId: 'productType',
  value: 'DIGITAL',
})

if (result._tag === 'Ok') {
  const { snapshot, delta } = result.value

  // delta shows exactly what changed:
  // {
  //   fields: {
  //     productType: { value: 'DIGITAL' },
  //     shippingWeight: { hidden: true },
  //     fulfillmentType: { hidden: true }
  //   },
  //   interactions: {
  //     'updateField:shippingWeight': { available: false, reason: 'Field is hidden' }
  //   }
  // }
}

The agent doesn't just get "success." It gets a delta showing the causal chain: changing productType to DIGITAL caused shippingWeight to become hidden.

LLM Tool Export

Convert the snapshot into OpenAI/Claude-compatible function definitions:

import { toToolDefinitions } from '@manifesto-io/ai'

const tools = toToolDefinitions(snapshot, { omitUnavailable: true })

// Returns JSON-Schema tool definitions:
// - updateField (with enum of available fields)
// - submit (if form is valid)
// - reset
// - validate

This enables agents to interact with forms through standard function-calling interfaces.

6. Safety Rails: The Hallucination Firewall

The Problem with Black Box

When an agent manipulates DOM directly:

It can click anything, including elements it shouldn't
It can input invalid values
It can trigger actions outside its permission
Failures are silent or cryptic

Manifesto's Safety Rails

Hallucination Firewall: Every agent action is validated before execution.

const result = session.dispatch({
  type: 'updateField',
  fieldId: 'nonexistent',  // ❌ Unknown field
  value: 'test',
})

// result._tag === 'Err'
// result.error === 'Field not found: nonexistent'
// State unchanged — no side effects

What gets rejected:

Unknown fields → Err
Type mismatches (string to number field) → Err
Hidden field updates → Err
Disabled field updates → Err
Unauthorized actions → Err

Atomic Rollback: On any failure, the previous snapshot remains intact. No partial mutations.

Deterministic Contracts: Same input + same state = same output. Agents can plan reliably.

This is capability-based access control for AI. The agent only sees and can only act on what's explicitly permitted.

7. The Schema Layer

The Semantic Snapshot is derived from a declarative schema. Here's how it looks:

Entity Schema (Domain truth)

import { entity, field, enumValue } from '@manifesto-io/schema'

export const productTypes = [
  enumValue('PHYSICAL', 'Physical Product'),
  enumValue('DIGITAL', 'Digital Product'),
] as const

export const productEntity = entity('product', 'Product', '1.0.0')
  .fields(
    field.string('name', 'Product Name')
      .required('Product name is required')
      .min(2).max(100)
      .build(),

    field.enum('productType', 'Product Type', productTypes)
      .required()
      .defaultValue('PHYSICAL')
      .build(),

    field.number('shippingWeight', 'Shipping Weight (kg)')
      .min(0).max(2000)
      .build(),
  )
  .build()

View Schema (UI behavior)

import {
  view, section, layout, viewField,
  on, actions, $, fieldEquals,
} from '@manifesto-io/schema'

export const productCreateView = view('product-create', 'Create Product', '1.0.0')
  .entityRef('product')
  .mode('create')
  .sections(
    section('basic')
      .title('Basic Information')
      .layout(layout.grid(2, '1rem'))
      .fields(
        viewField.textInput('name', 'name')
          .label('Product Name')
          .build(),

        viewField.select('productType', 'productType')
          .label('Product Type')
          .reaction(
            on.change()
              .when(fieldEquals('productType', 'DIGITAL'))
              .do(
                actions.updateProp('shippingWeight', 'hidden', true)
              )
          )
          .reaction(
            on.change()
              .when(['!=', $.state('productType'), 'DIGITAL'])
              .do(
                actions.updateProp('shippingWeight', 'hidden', false)
              )
          )
          .build(),

        viewField.numberInput('shippingWeight', 'shippingWeight')
          .label('Shipping Weight (kg)')
          .dependsOn('productType')
          .props({ min: 0, max: 2000 })
          .build(),
      )
      .build(),
  )
  .build()

The schema captures:

Dependencies: .dependsOn('productType')
Reactions: on.change().when(...).do(...)
Business rules: DIGITAL hides shipping fields

All of this is introspectable. The engine reads the schema, builds a DAG of dependencies, and exports the current state as a Semantic Snapshot.

8. Why Not Existing Tools?

Tool	Strength	Gap
XState	State machines	No UI semantics, no agent protocol
Zod	Validation	No field dependencies, no visibility rules
React Hook Form	Form state	Business logic buried in components
MCP	Tool invocation	No UI domain logic, no snapshot protocol

The missing piece is a layer that captures:

Why a field is hidden (not just that it is)
What conditions enable an action
How fields relate to each other
What changed after an action (delta feedback)

This is UI domain logic. None of the above expose it in a machine-readable protocol.

Manifesto fills that gap.

9. UI for Humans, II for Agents

For decades we've built User Interfaces:

Look good on screen
Feel responsive
Work across devices

That still matters. But it's no longer enough.

Software now needs both a UI for humans and an II — Intelligence Interface — for agents.

Layer	Consumer	Content
UI	Humans	Pixels, clicks, visual feedback
II	Agents	Semantic Snapshot, intent dispatch, delta feedback

Manifesto's architecture:

┌─────────────────────────────────────────────────────────────┐
│                    Schema Layer                             │
│  ┌─────────────┬─────────────┬─────────────────────────┐    │
│  │   Entity    │    View     │   Reactions & Rules     │    │
│  └─────────────┴─────────────┴─────────────────────────┘    │
├─────────────────────────────────────────────────────────────┤
│                    Engine (DAG Runtime)                     │
├───────────────────────┬─────────────────────────────────────┤
│      UI Renderer      │       AI Protocol (@manifesto/ai)   │
│   (React/Vue/etc)     │    Snapshot + Dispatch + Delta      │
└───────────────────────┴─────────────────────────────────────┘
        ↓                              ↓
      Humans                        Agents

Define the schema once. Generate both UI and II from it.

10. What Is an "AI-Native Application"?

To me, an AI-native application has these properties:

White Box, not Black Box — The engine exposes semantic state, not just rendered output
UI is a projection — A visual representation of state, not the source of truth
Agents interact with meaning — Through structured snapshots and intent dispatch
Protocol over DOM — Actions are validated, deterministic, and return deltas
Safety by design — Hallucination firewall, atomic rollback, capability-based access

This doesn't mean abandoning UI. It means recognizing that UI alone is insufficient when your users include both humans and machines.

The Road Ahead

We're at an inflection point.

For decades, software was built for human consumption. UI was the interface, and it was enough.

Now, AI agents are becoming first-class users. They don't need pixels and click events. They need:

Structured state
Explicit constraints
Causal feedback
Safe execution boundaries

The teams that build for this will have AI integrations that are:

Interpretable: Agents understand intent, not just surface
Deterministic: Same input, same output
Debuggable: Trace exactly what changed and why
Safe: Hallucinations rejected, not silently executed

The teams that don't will find their AI integrations perpetually fragile — dependent on screenshot parsing and prompt hacks that break with every redesign.

Conclusion

HTML is a great language for humans.

For AI, it's a noisy encoding of things it shouldn't have to reverse-engineer.

AI doesn't need your pixels. It needs your meaning.

That meaning should be exposed as a Semantic State Layer — a White Box protocol where agents can read state, dispatch intents, and receive causal feedback.

Manifesto is my attempt to build that layer.

GitHub: github.com/eggplantiny/manifesto-io

Playground: manifesto-io-playground.vercel.app

Package: @manifesto-io/* — The interoperability protocol for agents

Don't feed HTML to your agents.

Give them a White Box: state, intent, and semantics.

Why UI Generation Is Not Enough in the AI Era

Jung Sungwoo — Wed, 03 Dec 2025 06:26:51 +0000

Why UI Generation Is Not Enough in the AI Era

A philosophy of software architecture from the perspective of AI agents

For the past decade, UI generation has been the flagship promise of developer productivity. Visual builders, code templates, declarative schemas—all designed to accelerate the creation of user interfaces.

But something fundamental has changed.

The users of our software are no longer just humans. AI agents now interact with applications, trigger workflows, manipulate data, and evolve systems. And here's the uncomfortable truth: UI was never designed for them.

This essay argues that in the AI era, generating UI is no longer the bottleneck. The bottleneck is the absence of machine-readable semantics. And until we address this, AI agents will continue to guess, hallucinate, and fail.

The Lens Matters: Human Semantics ≠ Machine Semantics

Before we proceed, let me be explicit about the lens through which I'm viewing software:

This is not a critique of modern frontend development.

React, Vue, and Svelte are sophisticated frameworks. They organize code into semantic components. A <UserForm /> component is meaningful—to a human developer who can read its implementation.

But an AI agent cannot open UserForm.tsx and understand:

What fields exist inside
Which fields depend on others
What validation rules apply
When a field becomes disabled
What side effects occur on submit

The component is a black box.

Modern UI frameworks are semantic for humans. They are opaque for machines.

This distinction is the foundation of everything that follows.

Why AI Fails: The Interpretation Gap

When an AI agent "mis-clicks" or "hallucinates form behavior," the instinct is to blame model accuracy.

My view is different.

AI fails because applications do not expose their internal semantics.

Consider what happens when an AI agent encounters a typical web form:

It sees a screenshot (or DOM structure)
It identifies visual elements: buttons, inputs, dropdowns
It infers what those elements do based on labels and context
It executes actions based on those inferences

Step 3 is where everything breaks.

The AI has no way of knowing:

That selecting "Digital Product" should hide the "Shipping Weight" field
That "Subcategory" depends on "Category" and should be disabled until Category is selected
That "Freight" shipping type enforces a minimum weight of 50kg
That "Final Price" is auto-calculated from "Price" and "Discount Rate"
That SKU must be validated against a server endpoint for uniqueness

These rules are scattered across:

useEffect hooks
Custom validation schemas
Service layer calls
Global state management
Ad-hoc conditional rendering
Backend business logic
Tribal knowledge in developers' heads

The AI sees the surface. The meaning is buried.

Any system that forces an AI to guess will inevitably break.

What AI Agents Actually Need

Let me reframe the problem.

Humans need:

Buttons to click
Inputs to fill
Visual feedback to understand state

AI agents need:

The intent behind a button
The semantics of a field
The rules governing a workflow
The dependencies between values
The effects triggered by a change

UI expresses almost none of this in a machine-readable way.

What AI agents truly need is not a screen. It's an Intent Graph—a declarative representation of:

UI Concept	Semantic Equivalent
Button	Action with preconditions and effects
Input field	Typed semantic value with constraints
Screen	View into a domain model
Form submission	State transition with validation
Conditional visibility	Dependency graph

The UI can be generated, regenerated, or discarded. But the Intent Graph remains constant.

That is what the AI should interact with.

A Concrete Example: Declarative View Schema

Let me show you what this looks like in practice.

Here's a traditional React form (simplified):

function ProductForm() {
  const [productType, setProductType] = useState('PHYSICAL')
  const [weight, setWeight] = useState(0)
  const [fulfillment, setFulfillment] = useState('STANDARD')

  useEffect(() => {
    if (fulfillment === 'FREIGHT' && weight < 50) {
      setWeight(50)
    }
  }, [fulfillment, weight])

  return (
    <form>
      <select value={productType} onChange={e => setProductType(e.target.value)}>
        <option value="PHYSICAL">Physical</option>
        <option value="DIGITAL">Digital</option>
      </select>

      {productType !== 'DIGITAL' && (
        <input 
          type="number" 
          value={weight}
          onChange={e => setWeight(Number(e.target.value))}
        />
      )}
    </form>
  )
}

An AI agent looking at this has to:

Parse the JSX
Trace the useState dependencies
Understand the useEffect logic
Infer conditional rendering rules

Now compare this to a declarative semantic schema:

const productView = view('product-create')
  .fields(
    viewField.select('productType')
      .options(['PHYSICAL', 'DIGITAL'])
      .reaction(
        on.change()
          .when(fieldEquals('productType', 'DIGITAL'))
          .do(actions.updateProp('shippingWeight', 'hidden', true))
      ),

    viewField.numberInput('shippingWeight')
      .dependsOn('productType', 'fulfillmentType')
      .reaction(
        on.change()
          .when(and(
            fieldEquals('fulfillmentType', 'FREIGHT'),
            ['<', $.state('shippingWeight'), 50]
          ))
          .do(actions.setValue('shippingWeight', 50))
      )
  )

The difference is profound.

In the declarative schema:

Dependencies are explicit: dependsOn('productType', 'fulfillmentType')
Reactions are declared, not imperative: on.change().when(...).do(...)
Business rules are first-class: "FREIGHT requires minimum 50kg"
Visibility conditions are queryable: hidden: true when productType is DIGITAL

An AI agent reading this schema knows—without inference, without guessing—exactly how the form behaves.

Why Existing Technologies Aren't Enough

You might ask: don't we already have semantic technologies?

Technology	What It Captures	What It Misses
OpenAPI	API shape, request/response	UI state, field dependencies
GraphQL	Data relationships	Workflow logic, validation rules
JSON Schema	Data structure, constraints	View binding, reactive behavior
MCP	Tool contracts	Inter-field dependencies, UI state
React/Vue	Component structure	Business logic (encapsulated)

Each of these is a fragment of semantics.

None provides a unified model that spans:

Data (Entity)
View (Presentation + Interaction)
Rules (Validation, Constraints)
Dependencies (Field relationships)
Actions (State transitions)
Workflows (Multi-step processes)

This is the missing layer. I call it the Semantic Execution Layer—a unified runtime where meaning is explicit, queryable, and executable.

The Architecture of Meaning

Here's how I envision the stack:

┌─────────────────────────────────────────┐
│           Natural Language              │  ← User or AI intent
├─────────────────────────────────────────┤
│         Semantic Layer                  │  ← Intent Graph / View Schema
│  ┌─────────┬──────────┬──────────────┐  │
│  │ Entity  │  View    │  Reactions   │  │
│  │ Schema  │  Schema  │  & Rules     │  │
│  └─────────┴──────────┴──────────────┘  │
├─────────────────────────────────────────┤
│         Execution Runtime               │  ← Interprets & executes
├─────────────────────────────────────────┤
│    UI Rendering    │    API Calls       │  ← Projections
└─────────────────────────────────────────┘

In this architecture:

Entity Schema defines domain truth: what data exists, what constraints apply
View Schema defines presentation and interaction: how fields are displayed, how they react
Reactions define behavior: when X changes, do Y
Execution Runtime interprets these schemas and manages state
UI is just one possible rendering—a projection of the semantic layer

The AI agent interacts with the Semantic Layer directly. It doesn't need to parse UI. It doesn't need to guess.

Inference vs. Guarantee

There's a counterargument I often hear:

"But LLMs are getting really good at understanding UI! They can look at screenshots and figure out what to do."

This is true. And it's also insufficient.

LLMs can infer meaning from UI. But inference is probabilistic. It's a prediction, not a guarantee.

For simple forms, inference works. For complex business logic—cascading dependencies, conditional validation, multi-step workflows—inference fails unpredictably.

Consider the difference:

Approach	Reliability	Debuggability	Determinism
Screenshot → LLM inference	~70-80%	Low	No
DOM parsing → heuristics	~80-85%	Medium	Partial
Semantic schema → direct access	~99%+	High	Yes

If you're building a demo, inference is fine.

If you're building production systems where AI agents execute real transactions, move real money, and affect real outcomes—you need guarantees.

Semantic schemas provide those guarantees.

UI Is Ephemeral. Semantics Endure.

Let me be clear about what I'm not saying.

I'm not saying UI is useless. UI is essential—for humans.

I'm not saying we should stop building beautiful interfaces. We should.

What I'm saying is this:

UI is one projection of a deeper structure. AI agents need access to that deeper structure directly.

Today's software is built like this:

Design the UI
Implement the logic (scattered everywhere)
Hope the AI can figure it out

Tomorrow's software should be built like this:

Define the semantic model (Entity + View + Rules)
Generate UI as one projection
Expose semantics to AI agents as another projection
Let both humans and machines interact with the same underlying truth

The semantic layer becomes the single source of truth.

UI becomes a rendering concern—important, but not foundational.

Implications for Software Architecture

If you accept this philosophy, several implications follow:

1. Schema-First Development

Define your semantic schemas before writing UI code. The schema is the specification. The UI is an implementation detail.

2. Explicit Dependencies

Never hide field dependencies in useEffect hooks. Declare them in the schema where they can be queried and reasoned about.

3. Reactions as Data

Business rules should be expressed as declarative reactions, not imperative code. on.change().when(...).do(...) is data. An if statement buried in a component is not.

4. AI-Native APIs

Expose your semantic layer to AI agents. Not just REST endpoints, but the full Intent Graph: fields, dependencies, constraints, valid actions, expected outcomes.

5. Runtime Introspection

Build execution runtimes that can answer questions like:

"What fields are currently visible?"
"What would happen if I set this value?"
"What are the preconditions for this action?"

The Road Ahead

We're at an inflection point.

For decades, software has been built for human consumption. UI was the interface, and it was sufficient.

Now, AI agents are becoming first-class users of our systems. They don't need pixels and click events. They need structured meaning.

The companies that recognize this shift early—that invest in semantic layers, declarative schemas, and AI-native architectures—will build systems that are:

Interpretable: AI agents can understand intent, not just surface
Deterministic: Behavior is predictable, not probabilistic
Evolvable: Schemas can be versioned, migrated, and extended
Debuggable: When something fails, you can trace exactly why

The companies that don't will find their AI integrations perpetually fragile—dependent on prompt engineering hacks and screenshot parsing tricks that break with every UI change.

Conclusion

UI generation was the endgame for human developers.

For AI agents, it's not enough.

What we need is a Semantic Execution Layer—a unified representation of data, view, rules, and behavior that both humans and machines can interact with.

UI is a projection of this layer. An important one, but just one of many.

As AI accelerates, the question shifts:

"What does my application look like?" → "What does my application mean?"

The first question produces screens.

The second question produces understanding.

And in the age of AI agents, understanding is everything.

UI is transient. Semantics endure.