For Agentic App Builders

read as .md

The shift

AI agents drive existing SaaS apps through three increasingly unreliable layers:

Reading screenshots — vision-language models reason about rendered pixels. Brittle, slow, no typed I/O.
Browser automation — Playwright / Puppeteer scripts wrapping flows. Snap the moment a button moves; the agent has no way to know the contract changed.
Reading official APIs — when they exist, and only for the slice the API covers. Most production apps keep a third of their behavior in the UI, not the API.

What’s missing: a typed contract between the agent and an existing app’s surface, so the agent can drive flows safely without parsing pixels or scraping markup.

That’s the gap this track fills.

What gguifying an app looks like

You add a small ggui adapter to your existing app. The adapter:

Exposes navigable routes as renders with typed contracts
Mirrors form fields as actionSpec (typed inbound actions that drive turns)
Mirrors visible state as contextSpec (read-only observable state the agent reacts to)
Wraps any browser-only library you use (Stripe Checkout, Mapbox, calendar pickers) as gadgets so the LLM knows how to compose with them

The agent then drives your app the same way it drives a freshly-generated ggui UI — via ggui_handshake, ggui_render, ggui_consume. Same MCP wire. Same contract guarantees.

Critically: the human-facing UI doesn’t change. End-users keep clicking your buttons. Agents get a parallel typed surface onto the same flows.

What you’d write

The provisional shape is a ggui.app.json next to your existing app config:

{
  "name": "my-saas",
  "routes": [
    {
      "path": "/invoices/new",
      "intent": "create an invoice",
      "agentCapabilities": {
        "tools": {
          "createInvoice": {
            "toolInfo": { "inputSchema": { "$ref": "./schemas/invoice.json" } }
          }
        }
      },
      "actionSpec": {
        "submit": {
          "label": "Create invoice",
          "schema": { "$ref": "./schemas/invoice.json" },
          "nextStep": "createInvoice"
        }
      },
      "contextSpec": {
        "currentDraft": { "schema": { "$ref": "./schemas/invoice-draft.json" } }
      }
    }
  ]
}

Your app code stays as-is. An agent runtime can now discover /invoices/new from the adapter’s catalog, ggui_handshake against its contract, and ggui_render with a typed payload — no clicking around. (Exact wire shape for app-catalog lookup is part of the SDK’s in-design surface.)

Three scenarios this unlocks

Your support agent drives the app for the customer. “Refund last month’s invoice for customer X” → agent navigates to /invoices/, finds the row, calls refund with the typed payload. No human-in-the-loop browsing.
Your sales engineer runs an agent-narrated demo. During a prospect call, the agent narrates while driving the form in real-time. The prospect sees the same UI any user sees, but the agent’s typed actions land like a polished guided tour.
Power users hand work off to their AI. “I have 40 of these to fill in — can my AI do it?” The AI has a typed surface to drive, not pixels to scrape.

What’s shipping when

Component	Status
ggui protocol (this site)	Live
Agent Builder track (build a ggui-native agent)	Live
Agentic App SDK (wrap an existing app)	In design
Hosted gguifier service on guuey.com	In design
Reference adapters for Next.js / Rails / Django	Planned
Reference adapters for legacy stacks (Java EE, Drupal, …)	Planned

No dates. Real engineering work, not a marketing roadmap.

Waitlist

If this is the track you actually need, drop your email. We’ll write when the first adapter ships and we have an early-access slot to fill.

How ggui works — the protocol’s four moments. The gguify pattern reuses the same handshake → render → interact → consume loop, just driven by your app’s routes instead of LLM-generated UI.
Glossary — actionSpec, contextSpec, gadget, tool, blueprint.
For LLM agents — machine-readable resources, including this page at /agentic-app-builders.md.