Terminology

This page is the glossary of Auto's playbooks. It defines the words the documentation, the product and the code use. Availability says what Auto runs today.

A playbook contains one brain and its workflows. The brain is the playbook's collection of reusable functions and shares its lifecycle, and runs belong to the playbook.

Capabilities and resources

There are six capabilities: coordination, reasoning, interaction, prediction, recall and computation. A workflow expresses coordination. Each of the other five has a function type, listed in this order:

Capability	Resource someone defines	Category
Coordination	Workflow	Workflows
Reasoning	Reasoning function	Functions → Reasoning
Interaction	Interaction function	Functions → Interaction
Prediction	Prediction function	Functions → Prediction
Recall	Recall function	Functions → Recall
Computation	Computation function	Functions → Computation

What each function type is for:

Category	Description
Reasoning	Use a prompt and a language model, with tools where configured, to interpret information or produce a response.
Interaction	Exchange information with people or systems.
Prediction	Predict a quantity from the playbook's history or an uploaded dataset, with a model a trainer builds.
Recall	Answer from what the playbook keeps of its own history: its memory, not an agent's own notes.
Computation	Run a TypeScript program to calculate or transform data exactly.

Skill references and a separately managed tool library are still planned.

A reasoning function has a prompt and a language model; it is not limited to a model's reasoning mode. It can call the tools of operator-configured tool servers in a bounded loop. Functions explains when to choose each type.

Definitions and runs

Term	Meaning
Playbook	The complete system for a business responsibility, including methods, functions, workflows, relevant information and operating boundaries.
Brain	Simply the playbook's set of functions. It is created with the playbook and shares its lifecycle, so it is never created or managed on its own. Auto's instructions to your agent use the word; most pages say "the playbook's functions".
Auto	The product. These pages also use it for the running software, as in "start Auto" or "Auto keeps every run".
Auto Runtime	The software you install or deploy, with npx or Docker, that stores and runs playbooks. Technical pages also call it the runtime, and call one running copy of it the server.
Auto Studio	The interface for inspecting and managing playbooks.
Agent	An AI client the user works with, such as a coding agent, that connects to Auto Runtime. It is separate from the runtime and from Auto Studio.
Connection	Authorized access to a service. Most pages mean your agent's link to Auto, which the quick start names auto-runtime. A connection of an org is a tool server a person adds to the org through their agent and approves on Studio's page: the org owns it, its playbooks share it, and its credential is sealed in the runtime's secret store, never held with it. The tool servers the operator sets up are Auto's other connections to other services, and one tool server can serve several playbooks. Your agent's connections to its other accounts stay with your agent.
Method	The business's approach to a piece of work: what evidence matters, how decisions are made and what should happen next. It needs no Method resource.
Definition	A reusable function or workflow that someone saves in a playbook.
Function	A definition of one reusable operation, with declared inputs, outputs and behavior.
Workflow	A definition that coordinates steps, their dependencies, conditions and handoffs.
Subworkflow	A workflow that another workflow calls and waits for.
Step	One use of a function, another workflow or a control operation within a workflow. A step refers to its function and does not copy it.
Trigger	A condition in a workflow's document that starts a run on its own.
Event trigger	A trigger that starts a run for each event of the playbook its filters match.
Schedule trigger	A trigger that starts a run at the times its schedule names.
Schedule	The schedule key of a workflow document, which holds its triggers: a cron rule and an every period, both read in UTC, and an event trigger.
Version	A numbered revision. A definition gets a new version each time it is saved, and each run records the version it used; a prediction function also numbers its trained models. A workflow document's own document.version, such as 1.0.0, is text the author writes.
Overview	A plain-words description of a definition for a person who does not read its document. The runtime writes one for each version it saves, from that version's document. It ends with the active definitions of the playbook that use this one.
Run	A workflow or function carried out once against particular inputs.
Step run	One workflow step carried out once.
Attempt	One try at a step's work, or at a run started again under its id. A retry is another attempt, not another function.
Result	The output produced by a run.
Shape	A JSON Schema the runtime owns for what a definition produces, series, categories, table or text, which says what the data is and never what it measures; a definition that names one in output.shape is checked against it, as a question to a prediction function is checked against series, which a build does not answer, and Auto Studio draws a run's output from the shape the run names.
Sweep	The server's regular pass over the work that waits, such as runs to resume, answers to take and trigger starts to try again. It comes every second by default.

Definitions, versions, runs and results are separate concepts, and an overview describes a definition without being a second source of it. A workflow can call the functions of its playbook and other workflows; a workflow called this way is a subworkflow. Starting a workflow by hand is a run, not a trigger. Sending an approval or other input to a waiting run answers that run; it does not start a new one. Timers and event waits inside a workflow are control steps, not triggers. Workflows and runs explains how versions, retries, waiting and events behave.

Interaction

Term	Meaning
Request	What a run of a function waits on when it asks a person: a message, the party it goes to and when it expires. A run that asks makes one request.
Party	Whoever a request goes to. A party can answer where the request reached them, without calling the runtime, so a party need not be a caller.
Inbox	The playbook's own place for open requests, where a caller who may write to the playbook reads and answers them.
Delivery	How a request reaches a party outside the playbook: one call of the tool the function names in deliver.
Answer	What the party or the tool gives back; it must match the answer schema and is recorded on the run once, as the run's output.
Notification	A request that takes no answer, whose run succeeds once it is delivered.

An interaction function asks a system and returns its result at once, or asks a person and takes the answer later. Answering a request is not sending an event: an event goes to a waiting workflow run, and an answer goes to the run of the function that asked.

Prediction

Term	Meaning
Dataset	The rows a prediction function learns from, one for each series and period, folded from the playbook's events or uploaded.
Brief	The text a trainer reads first, rendered by the function's document from its dataset's figures.
Build	A run of a prediction function that asks a trainer for candidate models, scores them and keeps the winner as a version.
Trainer	The person or agent who reads a build's brief and rows, fits models outside the playbook and uploads them.
Candidate	A model file a trainer uploads to a build, scored on periods the trainer never saw.
Card	What a version was built from and how it scored, recorded when the build keeps it.
Shadow	The trial in which a later version predicts beside the active version as periods close, before it may replace it.
Active version	The version of a prediction function whose predictions its runs return.
Rollback	Activating an earlier version of a prediction function again by hand.

A prediction function, the predictive model a version of it holds and the prediction a run returns are distinct. Each version a build keeps holds one model with its card, and a function's versions are numbered from 1, apart from the versions of its document.

Orgs and callers

Term	Meaning
Org	The runtime's name for an organization in the Auto identity service; an org's id is that organization's id. Every playbook and every key belongs to one org.
Caller	Whoever a request acts for: a key, the local developer or a signed-in person, named on every fact it records. A run acts for the caller that started it, and a run a trigger starts acts as the playbook itself.
Key	A credential the runtime issues itself, for a machine, a pipeline, a trainer's agent or a grant over some of an org's playbooks.
Local developer	The caller of every request in local mode, on the developer's own machine, with every permission in every org. A server is in local mode when it listens only on a loopback address and neither sign-in nor keys are set.
Signed-in person	A person the Auto identity service signs in. They act in the org their sign-in names, with the permissions their token grants, and are recorded under their subject.

Supporting assets

Term	Meaning
Prompt	Instructions and input framing supplied to a language model by a reasoning function. The prompt is not the entire function.
Skill	A reusable package of task guidance and its resources. It supplies guidance rather than naming every component it uses. Planned: a reasoning function cannot use a skill yet.
Tool	A calling interface for an operation, including an operation outside the playbook or a function exposed to a caller. A function exposed as a tool keeps its function type and identity.
Tool server	An MCP server, or an HTTP API described by an OpenAPI document, whose tools the runtime's operator lets functions call.
Language model	A model used by a reasoning function.
Predictive model	A model a trainer builds for a prediction function, as a file the playbook runs in a process of its own.

History and events

Term	Meaning
Ledger	The runtime's record of everything: playbooks, definitions, runs, their history and the workflows waiting on timers and events. It is a SQLite file or a PostgreSQL database.
Event	A recorded fact that something happened, its type named in the past tense, as delivery_failed is.
Event data	The fact itself: what happened, and nothing of who acted, when, or the run it belongs to.
Event metadata	Where an event is recorded, when it happened, who acted, and the definition, run and chain it belongs to.
Published event	An event from outside the playbook, recorded with publish_event.
Projection	Data derived from the playbook's events by a defined rule: a recall function's view, or a prediction function's dataset when it is not uploaded.
View	The value a recall function keeps, built from the playbook's events and kept up to date as they are recorded.
Fold	The code of a recall function that adds each event its filters name to its view.
Dream	A planned, optional process that would revisit a playbook's history and suggest inspirations, such as a pattern worth investigating or a change to a method. An inspiration would be a candidate idea for a reasoning function to weigh, not a fact or an improvement. Dream would present its findings for review, or change only what the playbook has authority to change. It is not a function type.

History and events explains how a playbook records and reads its history.