What Is a Build Surface in an AI Operating System?

A build surface is the part of an AI operating system where new things get made — the interface where a founder directs AI agents to write code, ship features, and land commits, rather than chatting about work. In Optimus, the build surface is Orca: one terminal, a pod of 8+ Claude Code agents, big work taken down in parallel while you stay in flow.

Why does an AI operating system need surfaces at all?

Because a business runs in modes, and one interface can’t serve them all. Sometimes you’re heads-down making something. Sometimes you need a clean picture of everything your agents did while you were elsewhere. Sometimes you’re in the car with an idea that can’t wait for a desk. Cram all three into one chat window and you get the worst of each: a build session interrupted by status questions, a status view cluttered with build debris, and an idea-capture flow that demands a keyboard.

An operating system solves this the way operating systems always have — by giving each mode its own surface while keeping one system underneath. Optimus has three:

Behind the surfaces, Harry the honey badger does the heavy lifting in the background when Ollie dispatches it. Three surfaces, one crew, one place everything reports back to.

What makes a surface a build surface?

Three properties separate a build surface from every other AI interface:

• The output is shipped work, not text. On Orca, the unit of progress is a commit landing in a git worktree — a receipt you can inspect, diff, and deploy. A conversation that ends in a paragraph of advice hasn’t built anything.
• The human is the architect, not the typist. You brief outcomes; agents produce the code. The interface is built around orchestration — observing 8+ sessions from one screen, steering, harpooning what’s stuck — not around a text editor.
• It protects flow. The pod self-advances, picking up the next task as each lands, and only pulls you in for a real decision. A build surface treats your attention as the scarcest resource in the room, because it is.

How is a build surface different from a chat window?

A chat window is a conversation surface. It’s genuinely good at thinking out loud — which is why Optimus keeps one, in the form of Mako, for the go mode. But conversation surfaces make bad build surfaces: one thread, one worker, no isolation between tasks, and output you have to copy-paste into the real world yourself.

A build surface inverts every one of those. Parallel workers instead of one thread. Isolated git worktrees instead of a shared context that tangles. Commits instead of copy-paste. And when a worker goes sideways, you harpoon that one agent and Orca recycles the slot instantly — the other workstreams never notice. The full head-to-head is in terminal agents vs chat UIs.

What does the build surface reach?

An agent is only as useful as what it can touch. Every Optimus agent — on every surface — connects to the tools and platforms you already run through one secure gateway, with each connection scoped to your own keys. That’s a patented approach: your agents get the reach of your entire stack, and you never hand the keys to a platform. On the build surface that matters double, because building against your real stack is the difference between a demo and a deliverable.

What happens to the work after you build it?

It doesn’t evaporate into a scrollback buffer. Everything Orca ships reports back to Optimus, so the moment you step away from the keyboard, the full record is waiting in your portal. That hand-off between surfaces — build in Orca, review with Ollie — is the operating-system part. A standalone tool ends when you close the window; a surface feeds the system.

Why should a founder care about any of this?

Because the alternative is renting your build capacity — from an agency’s calendar, a contractor’s queue, or a platform that holds your keys. A build surface puts the making of things back in the founder’s hands at the speed the founder thinks. If you want the practical version, start with how to build software without a dev team — and see what it looks like when Orca is the surface you do it on.

FAQ

Is a build surface just another name for an IDE?

No. An IDE is where a human writes code. A build surface is where a human directs agents who write the code — the primary interface is the briefing and the orchestration, not the text editor. In Optimus, the build surface is Orca: one terminal driving 8+ Claude Code sessions in parallel.

Why does an AI operating system need more than one surface?

Because building, reviewing, and thinking are different modes with different interfaces. Optimus splits them into three surfaces — Orca in the terminal for building, Ollie in the portal for staying in the know, and Mako on Telegram for the go — all reporting back to one place.

What happens on the build surface, specifically?

You brief outcomes, dispatch agents into isolated git worktrees, watch commits land, harpoon anything stuck, and steer. The pod self-advances and only pulls you in for real decisions. The output is shipped, committed work — not conversation.

Do I have to use all three Optimus surfaces?

They come as one platform, but you use each when its mode fits: Orca when you build, Ollie when you need to see everything your agents have done, Mako when you’re away from the desk. Since everything reports back to one place, work started on one surface is visible from the others.