Every page in this manual that describes a task starts with the plain request you type to your agent. This page explains what those requests assume, how the agent proves the work is done, and what happens when vibe hands a job back to the agent instead of doing it itself.
A task page opens with a block you can copy into any agent that has the vibevm [skill](../glossary/index.xml#skill): it names the thing, states the result, and mentions no secrets. Under it, *needs* lists what the agent must have (the skill, network access, a token in the environment), *outcome* says what you will see when it worked, and the *assert* lines are commands that must succeed afterwards. The asserts are the point: an agent's answer cannot be checked by its wording, but a command's exit code can. Run them yourself, or ask the agent to run them and show you the results.
A request that includes a step that cannot be undone, publishing or deleting, says that the agent must confirm before that step. Keep that line when you adapt a request.
vibe behaves the same whether a person or an agent types the command, with one refinement. An agent identifies itself with `--invoked-by <name>` or the environment variable `VIBE_INVOKED_BY`. Every machine-readable report then carries that name, so logs show who did what. The installed skill tells the agent to pass it. In a script, `--unattended` answers every confirmation and refuses to open any interactive wizard.
An agent can run vibe as a command, one process per call, which is the natural way for a quick question or a wide scan. Or it can talk to `vibe mcp serve`, a persistent server registered by `vibe mcp install`, which answers questions about the project's packages and can run the same operations without spawning a shell each time. The operation is defined once; which door the agent uses is the agent's choice, and the skill teaches it the heuristic.
vibe has no model inside it. When an operation needs reasoning, such as explaining a project in prose, vibe does not attempt it: it composes an instruction and parks it in the project's [relay](../glossary/index.xml#relay) mailbox, `.vibe/agentic/command.md`. The agent then runs `vibe command`, which prints the instruction and clears the mailbox, and carries it out with its own model. There is no automatic write-back: if the result should reach vibe, the agent runs the command that records it.
The same handshake governs the build steps a project declares as agent work: when vibe runs under an agent, such a step is parked as a task for the agent to perform, and the same command resumes once the declared outputs exist. Under a person at a terminal, vibe can instead call a configured model provider, and pays for it only when the step actually runs.
Running `vibe command` with an empty mailbox prints that nothing is pending; it is safe to call at any time.
Run with no agent around it and no built-in engine, an operation that needs reasoning fails loudly and says to run it under an agent; an operation that needs none runs as usual.
Every subsystem of vibe has a complete algorithmic mode; a model only ever improves a result, and each such enhancement is off unless the operator switches it on.
An agent that reads this manual by address, rather than through a skill, finds the same requests in the plain-text form of each page; the pages are published for machines as much as for people.