Agent-First Design: Why Zero Exists and What It Trades

The Question Zero Asks

The premise behind Zero is simple: when an AI agent — not just a human — is reading, writing, and repairing code, what does the language itself want to look like?

Existing languages were designed long before agents could write code. Their priorities — terse syntax, expressive idioms, library cleverness — make sense for humans typing into editors. They tolerate ambiguity and implicit conversions because humans are good at filling in gaps. Agents are not. They generate exact text from probability distributions, and they pay for every fuzzy edge of the language with a wrong token somewhere downstream.

Zero starts over with the constraint flipped: design for agents first, accept that humans will still read the code, and see what falls out.

Principle 1: A Small, Regular Surface

Most programming languages grow over time. Each new release adds a small convenience — a new operator, a new syntactic form, a new way to express something the language already covered. Each addition pays for itself in human ergonomics. Each addition costs an agent: another variant to learn, another way to be wrong.

Zero deliberately keeps the surface tiny:

• One binding form (let).
• One function form (fun, optionally pub).
• One loop today (while).
• One way to model product types (shape).
• One way to model sum types with payloads (choice).
• One way to model labeled sums (enum).
• One pattern-matching construct (match).

No operator overloading, no decorators, no macros, no implicit conversions, no truthy coercion, no ternary. Each absence is a feature: it removes a place where an agent could pick the wrong variant.

The cost is the obvious one — fewer convenience features. The benefit is that an agent learning Zero during a session can converge on the right syntax without having to weigh seven near-equivalents.

Principle 2: Explicit Effects

Most languages let any function, anywhere, do I/O. console.log in JavaScript, printf in C, print in Python. The function's signature gives no clue about whether it might write to a file or hit the network. The only way to know is to read the body, recursively.

Zero takes the opposite position: every effect a function has shows up in its signature.

• I/O is gated by the World capability. A function that doesn't take World cannot do I/O. The type system enforces this.
• Failure is gated by raises and check. A function that can fail says so on its signature. Every caller acknowledges it with check or another explicit construct.

From a function's signature alone, you can answer two questions an agent (or a static analyzer, or a human reviewer) cares about deeply:

• "Could this touch the outside world?" — yes iff World appears.
• "Could this fail?" — yes iff raises appears.

That property doesn't exist in mainstream languages, and it's not a small one to have.

The cost is parameter plumbing. The World value gets passed wherever I/O is needed; the raises clause is repeated wherever errors flow. Zero accepts that as the price of the property.

Principle 3: Deterministic Tooling

The third principle is the one most directly aimed at agents: every output the compiler produces is structured data.

JSON diagnostics are the headline example:

{
    "code": "NAM003",
    "message": "unknown identifier",
    "line": 3,
    "repair": { "id": "declare-missing-symbol" }
}

Three properties make this different from a normal compiler error:

1. Stable codes. NAM003 means the same thing today and tomorrow, regardless of how the human-facing message is worded.
2. Structured repair plans. When the compiler thinks it knows how to fix a diagnostic, it emits a plan as data — an edit list, not an English suggestion.
3. Multiple structured channels. Diagnostics, dependency graphs, size reports, and explanations all live behind --json modes.

The whole point is that a tool — agent or otherwise — never has to parse English to act on compiler output. Looking up a stable code is exact; parsing prose is fuzzy. Zero treats the former as the contract and the latter as a convenience for humans.

Principle 4: A Library That Lives in the Language

Agents are good at writing code that follows existing patterns. They're worse at picking the right external dependency from a sea of options, integrating it correctly, and tracking when its API drifts. Every external dependency is friction.

Zero's design pushes capabilities into the standard library — explicitly documented, coherent, and stable as the language stabilizes. The aim is that a Zero program rarely needs to reach outside the standard distribution for routine work. That keeps the surface an agent has to reason about bounded.

This is an aspiration rather than a finished state today. The pre-1.0 standard library is real but still growing. The principle is the direction, not the destination.

What Zero Trades

Every design choice costs something. Honest trade-offs Zero makes:

• Verbosity over conciseness. Pure functions don't need World. I/O-capable functions do. Errors show up on signatures. The result is more annotations than a JavaScript or Python equivalent.
• Explicit over magical. No reflective metaprogramming, no decorators that quietly wrap behavior, no implicit globals. Things that look like they "just work" in dynamic languages have to be wired up by hand.
• Static over dynamic. Types are required on parameters, return values, and shape fields. The compiler does a lot of work; the cost is that every signature is something an author (or generator) has to write.
• Stability over rate of change. The language is pre-1.0 and changing fast, but the design intent is to lock down the surface once it settles. The cost is that adding a clever new convenience feature later becomes harder, because the bar for additions is "does this help an agent more than it costs them?"

Whether the trades are worth it depends on what you're optimizing for. If you're a human writing a one-off script, the friction is real and the agent benefits are abstract. If you're operating an agent that produces thousands of small programs per day, the friction pays back many times over.

What Zero Is Not Trying to Be

A few negative claims worth making explicit:

• Not "the future of all programming." Zero is a hypothesis, not a manifesto. The hypothesis is that agent-first constraints produce a useful language. Whether mainstream languages should adopt those constraints is a separate, longer conversation.
• Not a Vercel deployment platform feature. Despite being from Vercel Labs, Zero isn't tied to Next.js or to Vercel hosting. It's a standalone systems language.
• Not a replacement for Rust, Go, or Zig in production. Pre-1.0. Experimental. Use it to learn and provide feedback; don't ship customer software with it yet.
• Not finished. Pieces of the standard library, syntax for mutability, error-handling forms, and constraints on generics may all move before 1.0.

What's Interesting Even If You Don't Use It

Even if you never write a line of Zero, the experiment is informative:

• It's the clearest example of a real, working, capability-based effect system in a small systems language. The mental model — pass the permission, see the effect on the signature — is portable.
• The diagnostic story is what every compiler should have been doing for the last decade. Structured output beats prose every time, and Zero's commitment to stable codes is something other tools could adopt with no language changes.
• The principle of "one way to do each thing, deliberately small surface" runs against the grain of language design as it's usually practiced. Watching where that principle helps and where it pinches is useful regardless of which language you're writing in tomorrow.

Where to Read Next

If you've finished the rest of these docs, the most useful next reads are external:

• The Zero repository at github.com/vercel-labs/zero — examples, source, and AGENTS.md for the maintainers' own statement of intent.
• The official site at zerolang.ai — getting-started instructions and the canonical introduction.

Both are evolving. What you find there will be more current than any third-party tutorial. The principles in this doc are the slow-moving part; the syntax around them will move while the language settles.