The one command (reference)

You've spent this unit learning how your agent gets real tools to work with. Here's the thing that ties them together — and the first surprise is that it isn't yours to operate. It's a reference card for a tool your agent drives, so you can recognize it when it shows up in a session log and know what it's doing.

Most of what you do here, you do by talking. You describe what you want; the agent does the work. But underneath the conversation, the agent isn't waving a magic wand — it's running a real command-line tool, over and over, the way a builder reaches for the same trusted handle a hundred times a day. That tool is called wbx, and this lesson is the short version of what it is and why you'll see its name go by.

one handlE, mostly Held by tHe agent

The honest way to describe wbx is that it's a handle, not a brain. It's a single program that authors, builds, signs, ships, and runs workbooks — but it owns almost none of the cleverness itself. It parses what it was asked for, does the light local work directly, and hands everything heavy to the engine behind it. The intelligence lives in the system; the command is the grip you hold it by.

And in your case, you mostly don't hold it. When you ask your agent to scaffold a workbook, wire in a toolkit, or ship the thing, the agent is the one typing wbx commands. You'll see them scroll past in the session — wbx init, wbx toolkit push, wbx bundle — like a worker's hands moving across a bench. You're directing; it's operating.

why you'd wAnt to reCognize It anyway

If the agent does the typing, why learn the tool at all? Because recognizing what it's doing is how you tell whether it did the right thing. When a session log says the agent ran a build, then a bundle, then a sign, you can read that as a sentence: it compiled the work, packed it into one file, and stamped your origin onto it. You don't need to run those commands to know that's the right order — and to notice if a step is missing.

The verbs aren't random, which makes them easy to read. There are thirty-odd of them, but they fall into a few plain families:

• Author — starting a workbook, previewing it live, shaping its contents. This is the agent setting up its workspace.
• Make — turning the work into one finished file: build, bundle, run.
• Trust — signing a file so its origin travels with it, and verifying one someone hands you.
• Parts — the toolkits, workflows, and agents from the rest of this unit: discovering, building, importing, and pushing them.
• Engine — the commands that stand up a server and ship a workbook to it, for when you want it to keep running after you close the laptop.

You don't memorize the thirty. You learn that the families share the same manners — you start a thing, you check a thing, you do a thing — so once you've seen one family go by, the others read the same way.

it speaks to People and To machineS, on purpose

Here's the design choice that makes wbx safe for an agent to drive. The tool knows it has two kinds of users, and it changes its manners for each without changing what it does.

When a person is at a terminal, it's warm: it picks sensible defaults, offers a small menu when the choice is genuinely yours, and ends each success by suggesting the next step. The moment its output is being read by a program instead of a person — piped into a script, or driven by an agent — it drops the friendliness. No menus to hang on, no colors a log can't read, just clean, predictable output a machine can trust, and a stable code for every outcome so the agent can tell success from "the engine isn't running" from "that wasn't found." Same work underneath; only the manners change.

This matters more than it sounds. The usual industry answer is two separate things — a tool for humans and an interface for machines — and they always drift apart until they quietly disagree about what the software even does. wbx refuses that fork: one program with good manners, not two programs that fall out of sync.

the same Tool, inSide thE engine

And it goes one step further than most people expect. The very same tool runs inside the system, in the sandbox where the engine's own agents do their work. So when an agent's log says it ran a particular command, that's not a stand-in or a translation — it's literally wbx, the same one a person would install on a laptop.

That's what makes "people and AI build together" more than a slogan. It has to be true at the level of the tool itself, or it isn't true anywhere. When you and the agent are reaching for the exact same handle, with the same words and the same behavior, you're genuinely working in the same place — not watching a machine operate controls you can never touch.

where thiS is today, And where It's going

What's real today: wbx ships as one compiled tool for Mac, Linux, and Windows, and the same source also runs inside the engine's sandbox — so the claim that you and the agents hold the identical tool is literally true, not a metaphor. The verb families, the human-versus-machine manners, the stable outcome codes, and the never-fail health check are all built and tested.

The honest edge: this page is a reference, not a tutorial. We've deliberately not walked you through running commands yourself, because for a builder who works by directing an agent, that's not the job. If you ever want to drive wbx by hand — and plenty of people do, once they're curious — the deeper pages are where to go, and the tool is built to teach its own shape as you use it.

So that's the one command, named accurately for how you'll actually meet it. It's a single handle that authors, builds, signs, ships, and runs workbooks; it has good manners for people and trustworthy manners for machines; and it's the same tool on a laptop and inside the engine. You won't usually be the one holding it — your agent will. But now, when its name scrolls past in a session, you'll know exactly what your collaborator just reached for, and whether it reached for the right thing.