Canonical vocabulary for AI Notes. Prefer these terms in prose and code.
| Term | Meaning |
|---|
| Model / LM / LLM | Next-token (or multimodal) predictor used as a component |
| Completion | Single model call → continuation |
| Chain | Fixed sequence of model/tool steps |
| Workflow | Code-owned control flow; model fills steps |
| Agent | Stateful decision system: loop over actions under a policy with state & environment |
| Autonomous system | Agent (or fleet) with broad action rights; not the default goal of this book |
| Environment | External world + tools + humans that produce observations |
| Observation (o) | Data returned after an action (tool result, user message, timer) |
| Action (a) | Element of a closed or constrained action space (tool call, answer, escalate, …) |
| State (s) | Structured system state (not only chat text) |
| Policy (\pi) | Mapping from state (and context) to action distribution or choice; may be hybrid |
| Control loop | observe → decide → act → update state → (repeat / terminate) |
| Episode / case | One bounded unit of work (e.g. ShopOps case O-1001) |
| Hybrid control | Model proposes; deterministic code constrains/permits/executes |
| Term | Meaning |
|---|
| Context / working context | Tokens presented to the model this call |
| Context assembler | Component that builds context under budget + precedence |
| Token budget | Hard/soft limit on assembled context |
| Context poisoning | Untrusted or conflicting content steering behaviour |
| KV cache | Cached key/value tensors for prior tokens during decoding |
| Prompt / prefix cache | Reuse of billed/computed prefix across requests when prefix bytes stable |
| Lost-in-the-Middle | Empirical drop in use of mid-context evidence |
| Term | Meaning |
|---|
| Tool | Typed side-effecting or read API exposed to the agent |
| Tool registry | Name → schema → handler catalog |
| Executor | Runs tools after policy checks |
| Idempotency key | Client key making retries safe |
| Dry run | Execute validation/path without committing side effects |
| Term | Meaning |
|---|
| FSM | Explicit finite-state control |
| Checkpoint | Durable snapshot enabling resume |
| Working memory | Short-horizon task state |
| Semantic memory | Long-lived facts/embeddings |
| Episodic memory | Records of past episodes |
| Procedural memory | How-to skills / playbooks |
| Retrieval | Fetch external/knowledge docs (≠ memory write) |
| Memory controller | Policy for what is written/forgotten/superseded |
| Provenance | Where a fact came from |
| Term | Meaning |
|---|
| Orchestrator | Assigns tasks, budgets, approvals — not “the smart one” |
| Ledger | Append-only ordered log of shared events/beliefs |
| Conflict | Contradictory assertions recorded as data |
| Trace | Structured record of a run’s decisions and I/O |
| Audit / evidence pack | Exportable justification for a consequential action |
| Term | Meaning |
|---|
| Policy-as-code | Deterministic permit/deny rules versioned in code |
| HITL | Human-in-the-loop approval/escalation as architecture |
| Injection | Untrusted content influencing instructions/actions |
| Authz | Authorization independent of the model |
| Term | Meaning |
|---|
| ShopOps | The book’s e-commerce post-purchase operations system |
| Case | One customer order exception / order-exception workflow instance |
| Intake / Resolution / Policy / Outreach agents | Specialised ShopOps components (may be modules or processes) |
| Avoid | Prefer |
|---|
| Brain | Model / policy |
| Memory (unqualified) | Name the type |
| Autonomous (default) | Agent with explicit permissions |
| Agent for every function | Module / workflow step |