Product guides
Product building blocks
Each primitive handles a different part of the run.
| Primitive | What it holds | What it changes |
|---|---|---|
| Run workspaces | Mutable files, tools, browser state, and intermediate results for one run | Gives the agent a place to do the work |
| Documents and artifacts | Accepted deliverables and retained previews | Preserves the canonical result beyond the workspace |
| Automations and events | Triggers, conditions, actions, and activity history | Starts work at the right time |
| Integrations | Governed access to business and developer systems | Lets the run operate where the work lives |
| Knowledge | Approved facts, policies, examples, and organization context | Gives the run the right information |
| Skills | Versioned procedures and checks for repeatable work | Gives the run a tested method |
| Memory | Scoped guidance from accepted work and corrections | Improves future choices without rewriting every prompt |
| Identity and permissions | Run owner, tool allowlists, network boundaries, approval rights | Defines what the run may see, change, and approve |
| Review | Evidence, questions, changes, and approval gates | Keeps consequential decisions accountable |
The prompt describes today's job. Knowledge supplies approved facts, a Skill supplies the method, and Memory offers scoped guidance from earlier reviewed work. The named system of record and the accepted artifacts keep current truth separate from working copies.
Which layer a correction belongs in
Most operating mistakes come from putting a correction in the wrong layer. A policy pasted into a prompt has to be pasted again. A one-time exception promoted to Knowledge becomes a rule that quietly breaks the next run.
| The correction is | It belongs in |
|---|---|
| A fact or a policy | Knowledge |
| A change to the procedure | The Skill |
| A one-time exception | The run, and nowhere else |
| A missing check | A validator |
| The wrong tool for a step | A tool rule or routing guidance |