Learn
Glossary
These docs use a handful of words as though you already had them. Here is each one in a sentence, with the page that explains it properly. Grouped by family rather than alphabetically: someone who just looked up worktree usually wants land next.
On this page(5 sections)
The pieces
The two tiers, and the things that make up the half that runs on your hardware.
| Word | What it means |
|---|---|
| Machine | The computer a sandbox runs on: your laptop, a server you rent, or one we host for you. It supplies processors, memory and disk, and nothing else about your agents depends on which one it is. The worksite |
| Sandbox | A long-lived workspace environment on a machine you choose, normally one Docker container plus durable volumes. It holds many conversations, their repos, terminals and capabilities, and is the only product tier that sees your code. Architecture |
| Daemon | The program inside the sandbox that everything talks to. It serves the HTTP API, verifies who you are against Google directly, runs the agent, and owns the files and git history. When these docs say the daemon enforces something, they mean it is enforced by the container on your hardware rather than by a screen you could bypass. Sandbox API |
| The platform | The thin hub at intentic.dev: account, subscription and sandbox discovery. It sits off the ordinary command path; hosted-machine lifecycle and optional trial turns are explicit custody exceptions. Architecture |
| Tunnel | The outbound-only connection the sandbox dials from your machine, which is how a browser anywhere reaches it with no inbound port opened. Architecture |
| Workspace | The /work directory inside the sandbox: your repos, and the files the agent reads and writes. It lives in a named Docker volume, so it survives every update, rebuild and rollback. Docker setup |
| Project | One repository in the workspace. No conversation owns one: every agent in that sandbox can reach it, each on a branch of its own, and the same project can sit in two sandboxes at once because each keeps its own clone. The worksite |
| Slug | The short name every Docker object for a sandbox is derived from: the first label of its public hostname, so my-box in my-box.intentic.dev. It is what you substitute into the container, volume and network names. Docker setup |
| Setup code | A short-lived code the setup screen mints and puts inside the install command for you. Your machine redeems it once for the real connection token, which is why no long-lived secret lands in your shell history. Quickstart |
Shape, state and placement
The words for reproducing a sandbox and moving its compute without moving its ownership.
| Word | What it means |
|---|---|
| Sandbox definition | A deterministic sandbox.toml describing the reproducible shape of an environment: the workspace repository, project repo references, connection shapes, secret names, overlay source and non-default agent settings. It contains no credential values, identity or history. Sandbox definitions |
| Bundle | A private portability archive containing the sandbox definition plus state that cannot be reproduced from a source: transcripts, git data, checkpoints and records. A definition is a template; a bundle is continuity. Sandbox definitions |
| Runner | The sandbox image in execution-only mode on another computer. It runs isolated turns and returns their branches and event streams; the parent sandbox keeps the conversation, transcript, review and land door. Remote runners |
Doing the work
What an agent run is, what scopes it, and the words for running several at once.
| Word | What it means |
|---|---|
| Conversation | One thread of work with the agent, addressable and resumable by an id you choose. A sandbox holds many, and each one keeps its own transcript. Parallel agents |
| Persona | A card that decides what a conversation is and may do: which tools are mounted, which connected accounts it signs in as, which folder it starts in, which instructions it runs on. What it withholds is absent from the turn rather than refused during it. The worksite |
| Turn | One request to the agent and the work it does in reply. It runs detached inside the daemon, so closing the tab, reloading, or watching from a second device changes nothing about it. One agent |
| Worktree | A second checkout of one of your repos, on its own branch, which an isolated conversation is given so it can edit files without colliding with anything else. It is a standard git feature, not an intentic one. Parallel agents |
| Land / landing | Taking what an agent did in its worktree and applying it to your main tree as uncommitted changes. Nothing is merged and your main branch does not move: landing hands you a diff to review, and doing it twice is safe. Parallel agents |
| Fleet | All the conversations in a sandbox seen at once, on the board that sorts them by whether they need you, are still working, or are done. Parallel agents |
| Harness | The agentic loop that serves a turn: the thing that decides how the model plans, calls tools and asks you questions. It is a separate choice from the model: the same model behaves differently under each, so the picker asks for both. Models & accounts |
| Runtime subagent | A child created inside the current provider's harness. It remains part of the parent turn, shares its working tree, and uses the same provider and harness. Parallel agents |
| Full child agent / meta-harness child | An ordinary isolated conversation a turn starts through intentic's provider-neutral supervision service. It may use another provider, outlive its parent turn and run on a remote runner. Parallel agents |
Work that runs without you
The three unattended shapes, and the two words that qualify them.
| Word | What it means |
|---|---|
| Automation | A wake-up from outside the sandbox, such as a clock, webhook, message or workspace change, that starts a fresh run. Automations, workflows & loops |
| Workflow | Several agents run in a set order, each handing on to the next. Authored once, run repeatedly. Automations, workflows & loops |
| Loop | One agent kept going until its goal is actually met, rather than stopping after a single turn. Automations, workflows & loops |
| Guard | A shell one-liner run in the workspace before a wake, which has to succeed for the run to proceed. It is how an automation stays quiet when there is nothing to do. Automations, workflows & loops |
| Chore | An automation marked as maintenance of your own codebase, rather than a reaction to something outside it. The distinction is what lets the sandbox report what it keeps an eye on. Automations, workflows & loops |
Reaching out, and letting in
How a sandbox gains tools, and how anything other than you gets in.
| Word | What it means |
|---|---|
| Capability | One connected outside system or tool, added in a click: the credential is stored in your sandbox, the environment variables reach the agent's shell, and a cheatsheet teaches it to drive the thing. Capabilities |
| Extension | Code that adds views, file renderers, commands, settings or whole capability cards to the product. A manifest declares it for the owner to approve before anything runs. Extensions |
| Overlay | The approved list of extra things baked into your sandbox's image: a package, a language toolchain, an SDK. Changing it needs a rebuild you approve, because changing what the container contains is your call and not an extension's. Docker setup |
| Control token | The credential a program presents instead of signing in: a CI job, a script, an editor bridge. Minted with a fixed scope, shown once, revocable one at a time. Authorising a call |
| Role | What an invited person may do in your sandbox: maintainer, collaborator or viewer. The daemon enforces it on every route, so it is not a matter of which buttons the screen shows. Access & sharing |
More in Learn