---
title: "Terminology"
description: "Describe how you want the work done. Auto builds a working playbook you can test, change and run again."
url: "https://on.auto/docs/concepts/terminology"
last_updated: "2026-10-17T10:18:42Z"
---

# Terminology

This page is the glossary of Auto's playbooks. It defines the words the documentation, the product and the code use. [Availability](https://on.auto/docs/concepts/functions#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](https://on.auto/docs/concepts/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](https://on.auto/docs/concepts/workflows) 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](https://on.auto/docs/concepts/history-and-dream) explains how a playbook records and reads its history.

## Sitemap

See the [full documentation and product sitemap](https://on.auto/sitemap.md) for related pages.