Headless Everything: The Mental Model That Changes How You Build with AI

Simon Willison — the guy behind Datasette and one of the most respected voices in AI development — has been publishing a series on what he calls “headless everything” applied to personal AI tools. The core idea is simple: separate the intelligence from the interface, the same way we already do with headless CMS, headless e-commerce, and any modern architecture that values flexibility.

But here’s the point most people are missing: this isn’t just software architecture. It’s a shift in mental model that affects how product managers think about features, how devs structure projects, and how anyone building with AI decides what to couple and what to keep independent.

The problem headless solves

Most AI tools today are monolithic. You use ChatGPT? The interface, the model, the context, the history — it’s all bolted together. Want to change something? You can’t. Want to reuse a piece somewhere else? Good luck.

This works fine for casual consumption. But for anyone building products, creating automations, or needing real control over how AI operates, coupling is a prison.

Headless applied to personal AI means separating:

• The model (which LLM you use — could be Claude, GPT, local Qwen, Llama)
• The context (what information feeds the model — files, databases, memory)
• The interface (how you interact — CLI, app, browser extension, API)
• The orchestration (how the pieces connect — agents, pipelines, workflows)

Each layer becomes a replaceable component. You don’t marry any vendor. You’re not dependent on an interface that could change tomorrow. You don’t lose your context when you switch tools.

Why this matters now in Brazil

Two things are converging:

1. Local models became viable. Qwen, Llama, Mistral — they run on accessible hardware. This means the model layer doesn’t have to be an external API with per-token costs. You can have a headless model running on your machine, fed by your context, accessed through whatever interface you choose.

2. API costs for real projects are prohibitive. For anyone building products in Brazil, the API bill for models like GPT-4 or Claude scales fast. Headless architecture lets you use different models for different tasks — a local model for frequent tasks, a premium model only when quality justifies the cost.

What changes in practice

For product managers

Stop thinking of “let’s add AI” as a single feature. Think in layers:

• Which model solves this specific problem? (Do you need the best, or do you need fast and cheap?)
• Is the context for this feature shared with other parts of the product?
• Does the AI interface need to be native or can it be a module?

Monolithic approach

• One model for everything
• Context locked in the tool
• Switching = migrating everything
• Fixed cost per use

Headless approach

• Right model for each task
• Context portable and reusable
• Switching = swapping a component
• Cost optimized per layer

For developers

Headless AI architecture follows the same principles you already know from API-first and microservices:

• Clear contracts between layers. The model receives prompt and context, returns a response. The interface doesn’t know which model is behind it.
• Context as structured data. Not text dumped into a prompt. Information that can be indexed, searched, versioned.
• Explicit orchestration. When you need multiple steps, it’s a declared pipeline — not a chain of prompts strung together and hoping for the best.

The pattern Willison is documenting

Willison’s work matters because he’s not theorizing. He’s building and documenting. Some practices he highlights:

Datasette as context layer. Structured data that feeds the model via query, not via “throw everything in the prompt and cross your fingers”. This is headless in practice: the data layer doesn’t know it’s feeding an AI.

LLM as function. The model is called like a function — takes input, returns output. No state. No interface. It’s a Lego brick.

CLI as standard interface. Before you build a GUI, build a CLI. This forces you to think API-first. The graphical interface becomes a layer on top of something that already works headless.

• Does your AI project work without a graphical interface?
• Can you swap the model without rewriting business logic?
• Is your context structured or is it text pasted into prompts?
• Do you know what each layer costs separately?

Where this breaks down

Headless isn’t a silver bullet. Decoupling has costs:

• Higher initial complexity. Monolithic is faster to start. If you’re validating an idea, sophisticated architecture might not be the right call yet.
• Integration overhead. More layers = more failure points, more potential latency, more to monitor.
• Requires team discipline. If every dev couples things differently, you lose the benefit.

The right question isn’t “should I use headless?”. It’s: what level of decoupling makes sense for the stage and scale of my project?

The mental model that sticks

When you build headless, you’re buying optionality. Today’s model isn’t tomorrow’s model. The interface that works now might not work in 6 months. The context you’re accumulating is the real asset — and it needs to survive the tools that use it.

This applies to anyone building a SaaS with AI, anyone setting up internal automations, and anyone experimenting with personal AI for their own productivity.

The logic is the same that separated frontend from backend a decade ago. Whoever understood it first built better. Whoever waited was refactoring coupled code for years.

With AI, the window of advantage is open right now.