# Build for the Agent, Not the Human

#concept

## Summary

A product philosophy from [[thorsten-ball]]: if you start something on the frontier today, **no human should have to fill out a form.** Anything a human can do on your site, they should be able to have an agent do — and ideally they should **bring their own agent**, because "nobody wants to use your shitty built-in agent."

## Current Understanding

- **The admin panel that dies.** Building a food-ordering app from a photo of a menu, the agent also produced an admin UI for editing prices and spellings. Thorsten's reaction: *"I'm never going to open that. I'll just send another photo and say 'fix the pricing.'"* The insight underneath it is general: **a lot of admin UI existed only so that no code had to change.** Once changing code is cheap, the UI layer built to avoid changing code is pure [[shedding-weight|weight]].
- **The same for content dashboards.** WordPress-style admin: "here's my draft, add this header image, publish, spell-check" — one sentence instead of a session of clicking.
- **Bring your own agent** is the sharp part, and it cuts against most 2026 product roadmaps: the differentiator stops being *your* assistant and becomes whether your surface is drivable by *the user's* assistant. That makes agent-accessibility a product feature rather than an integration checkbox.
- **Consequence for moats.** If every surface is agent-drivable and every agent can remix software ([[emacsification-of-software]]), general-purpose SaaS loses the lock-in that UI familiarity used to provide. Thorsten's own prediction list says it plainly: it is unclear what software survives.

**Read carefully, this is not "no UI."** The claim is that UI built as a *substitute for changing the system* dies, and UI built as a genuinely better interface survives. The distinction matters for the webinar's [[personal-ai-operating-system|OS framing]], where the endpoint is a *smaller* interface (a button that already knows what the email said) rather than no interface — arrived at from the opposite direction: Thorsten deletes UI so he can prompt, the OS framing builds tiny UI so you need not prompt. Both are the same underlying claim that the generic chat box and the generic admin panel are the two things being squeezed out.

## Evidence

- "No human should have to fill out forms," bring-your-own-agent, the food-app admin panel, the WordPress example — [[2026-07-28-agentic-engineering-10x-developer]].
- Erosion of software moats via remixability (prediction 3 in the same source).

## Related Pages

- Concepts: [[shedding-weight]] (the parent move), [[emacsification-of-software]], [[explosion-of-internal-software]], [[personal-ai-operating-system]] (the interface question from the user's side), [[async-by-default]]
- Entities: [[thorsten-ball]], [[amp]]

## Contradictions / Uncertainty

- **Who operates the software if forms die?** Thorsten's answer is "prompt the agent" — which assumes exactly the prompting competence the corpus's HR interviews identify as the real bottleneck ([[levels-of-ai-usage]], and Nina/Yulia's *friction, not resistance* finding). An admin panel is a poor interface for an expert and a good one for a beginner. Status: tentative.
- "Bring your own agent" is asserted by someone who sells an agent; the business model that survives universal BYOA is not addressed.
- No account of authorization: an agent-drivable surface is also an agent-*abusable* surface, and the source says nothing about permissions, rate limits, or attribution.

## Next Questions

- What is the minimum an existing product must expose to be genuinely agent-drivable — an API, an `AGENTS.md`, structured error messages, or something else?
- Does the webinar audience want fewer forms or *better* forms? Worth asking directly, since it decides whether the OS pitch lands as liberation or as loss of a familiar surface.