Framework Glossary

Every term you’ll meet across the five steps, in plain language, each linked to the page that introduces it.

Agent (how it runs) — A workflow that decides its own path while it runs, uses tools on its own judgment, or runs without you. Design chooses an agent when the workflow needs any of these. On Microsoft 365 Copilot, agents are made in Agent Builder.

Agent (building block) — A configured worker with a job, tools and limits, which a person or another part of the workflow hands work to. See Agentic Building Blocks.

Augmented / Automated — Who takes part while a workflow runs. Augmented: a person is in the workflow along the way, guiding or working with the AI. Automated: no one takes part until it’s done; starting a run by hand doesn’t make it Augmented. Set in Design; see the AI Workflow Design Matrix.

Autonomy — How much the AI decides on its own, judged by what decides the next step. Deterministic: you give instructions and the AI carries out every step you set. Guided: you give bounded decisions with your method (a rubric, criteria, a process), and the AI decides by it. Autonomous: you give a goal, and the AI plans its own steps until the goal is met. Design names the level once, in its plan review. See the AI Workflow Design Matrix.

Backlog — The list of candidate workflows Analyze saves, each with the work, the pain and the value: cards in your registry, or framework/backlog.md in your working folder without one.

Build record — The file Build writes (build-record.md): what was built, where it’s installed, and what it can access. Once the workflow is live, it also says how to switch it off.

Building blocks — The pieces a workflow is built from, in four layers: Intelligence (Model, Context, Memory, Project), Orchestration (Prompt, Skill, Agent, Harness), Integration (MCP, API, SDK, CLI) and Governance (Registry, Observability, Evaluation). See Agentic Building Blocks.

“Change my workflow” — The phrase that starts any change to a workflow that’s planned, built or live. Design picks it up and judges whether the change is small or big; every change starts at the requirements. See Keeping It Working.

Change that can’t be undone — Anything a workflow does that can’t simply be taken back: sending an email, posting a message, deleting or overwriting a record, or changing a record other people see. Design puts a checkpoint before it unless you choose to accept the risk, and a practice run shows it instead of making it.

Checkpoint — A point where the workflow stops and asks a person first, such as before it sends anything. One of the three kinds of line in your requirements, captured in Deconstruct.

Connection — How a workflow reaches a system such as a CRM, a calendar or a drive. Your platform may call it a connector or an app. Build has you connect each one in your own account and proves it works.

Context — The documents, examples and reference material a workflow reads while it runs, such as a style guide or a template. Captured in Deconstruct, kept in the workflow’s context/ folder, and placed where the workflow runs by Build.

“Continue my workflow” — The phrase that moves a workflow on from wherever it is. Say it in a new chat; any of the five skills reads your files, works out which step is next, and either picks up there or gives you the phrase to start that step in a new chat. See Moving From Step to Step.

Design Plan — The plan Design writes (design-plan.md) for how AI will do the work: where it runs, how much it decides on its own, which parts are skills or agents, what it connects to, and the task list Build follows. You approve it before anything is built.

Flag line — The line at the end of every run that flags anything the workflow wasn’t designed for, such as a new kind of input or a case its rules don’t cover, with the phrase to fix it: “change my workflow”. Part of keeping it working.

Framework folder — The framework/ folder inside your working folder that holds your workflow files. Each workflow gets its own folder inside it. It’s kept apart from the workflow’s place.

Keeping it working — What every workflow carries so it stays useful once it’s live: the flag line, a re-check date, and “change my workflow”. It’s part of every workflow, not a step. See Keeping It Working.

Lens — What an Analyze session looks at: Individual (your own work) or Organizational (your business’s processes, across several roles).

Live — A workflow you’ve taken live at the end of Test and now use for real work. Live is a fact about the workflow, not a step: a live workflow stays live while it’s changed or re-checked. Build asks you to pause any schedule while it makes a change, and the changed version is tested before its next real run.

Must-have — A check the output can’t pass without. Marked among what every output must get right in Deconstruct; a miss on a must-have is never accepted.

Practice inputs — Realistic examples, based on your real work, that Test runs the workflow on. Captured in Deconstruct and saved in the workflow’s inputs/ folder. Each round also includes one new input the workflow hasn’t seen, ideally a real one.

Practice run — A run of the workflow that’s built never to send or change anything. It goes up to each change, shows exactly what it would send or change and where, and stops there. Every workflow Build makes has one, and every run in Test is one.

Quick real check — One small real change, made during Build’s setup somewhere only you can see, with your OK first, that proves a kind of change works.

Re-check — Running Test again on a live workflow with “test the workflow I built”, to see whether it still does what it must. When the workflow goes live, Test records a re-check date three months out on your registry card (and in the run log, where the workflow keeps one).

Registry — Your AI Registry: a folder of Markdown cards describing your business, its processes and its workflows, which every framework step reads and updates so you never describe your work twice. See the AI Registry Setup guide.

Round — One pass of Test: the practice inputs that need running and one new input, each requirement checked with proof, then a verdict of Ready, Not ready, or waiting on a connection’s access. A later round re-runs only what a fix or change could affect. On the full track, two or three rounds is normal.

Rules it follows — Sentences in your requirements that say how the workflow must behave: “It always…”, “It never…”, “When…, it…”. One of the three kinds of line, captured in Deconstruct.

Run log — A one-line-per-run record the workflow keeps in its own place, where the platform lets it write one. Re-check reminders and time saved come from it. Not every workflow keeps one; those that don’t still end each run with the flag line.

Skill (how it runs) — A workflow you start yourself that follows your steps and your criteria, stopping at its checkpoints. Design chooses a skill unless the workflow must work out its own path, use tools on its own judgment, or run without you.

Skill (building block) — Any reusable set of instructions the AI follows, including smaller skills a workflow uses for one part of the job. See Agentic Building Blocks.

stale_after — The re-check date on a workflow’s registry card. Test sets it when the workflow goes live, three months out, and resets it after each Ready re-check.

Track (light, full) — How thorough the five steps are for a workflow. Light is for small, low-risk workflows; full is for the rest. Same steps and files; Deconstruct, Design and Test are shorter on the light track, and Build works the same way on both. Any sign of risk keeps a workflow on the full track. Proposed in Deconstruct.

Tricky case — An input that’s harder than usual: missing information, an unusual request, something that tests a rule. Your practice inputs should include at least one.

What it must get right — Yes-or-no checks in your requirements that every output is graded against; the one or two you can never let go out wrong are must-haves. One of the three kinds of line, captured in Deconstruct and checked in every Test round.

“What I did” summary — The short summary a workflow ends each run with: the steps it took, where it paused for you, and what it did with your tools. Test uses it to check the path, but always grades the output itself, never the summary’s claims about it.

Workflow’s place — Where the workflow runs: its own Project or folder; on Microsoft 365 Copilot, Copilot Cowork’s own folder or the agent itself. It holds only what the workflow reads while it runs, never your requirements or plan, so Test’s runs stay cold.

Working folder — The one folder that holds your AI Registry (registry/), your workflow files (framework/) and your knowledge graph (knowledge/). By default it’s called ai-workspace, or it’s a folder you already have: in Google Drive or OneDrive, on your computer (the folder you select in the Claude desktop app), or your workspace itself on Claude Code and Codex. The first framework skill you run asks for it.

Workflow node — A workflow’s card in your registry (registry/workflows/<slug>.md), tracking its status and files across every step. First written by Analyze, or by Deconstruct for a workflow you start without a backlog entry.

Workflow Requirements — The clear, testable description of what a workflow must do (requirements.md): its goal, what every output must get right, the rules it follows, where a person checks, and its practice inputs. Written in Deconstruct and read by every later step.