Glossary
Use this page to keep Consuelo OS language consistent.Naming doctrine
Use product terms first. Implementation terms belong in reference docs when they name a real implementation detail.| Preferred term | Use it for | Avoid when you mean this |
|---|---|---|
| OS | The product operating layer. | Transport-layer implementation terms. |
| Portal | The safe product boundary agents use to read context and take approved action. | Interface. |
| Skills | Approved workflows an agent can run. | Legacy workflow docs or runbooks. |
| Tools | Callable agent capabilities exposed through OS. | Scripts when you mean the call surface. |
| Scripts | Executable implementation behind a skill or tool. | Skills, tools, or product workflows. |
| Capabilities | Connected systems, configured services, and available OS powers. | Piles of environment variables. |
| Artifacts | Tracked outputs with storage, provenance, status, and metadata. | Loose files. |
| Approvals or guardrails | Human-decision checkpoints for high-impact work. | Permission framework. |
OS
Consuelo OS is the operating layer that turns a company into an agent-ready workspace. The OS gives agents safe access to context, skills, tools, artifacts, approvals, memory, and structured workspace data.Agent-ready workspace
A workspace is agent-ready when agents can understand what exists, know which actions are approved, run repeatable skills, create tracked artifacts, and leave an observable trail.Portal
The safe entry point agents use to work with Consuelo OS. The portal gives agents one path for context and one path for approved action. Public docs should use portal as the product term.Skill
An approved workflow an agent can run through Consuelo OS. A skill bundles instructions, required context, capability requirements, approval rules, tool usage, implementation scripts, and output contracts into one safe workflow.Tool
A callable agent capability exposed through Consuelo OS. Tools are the operations agents can invoke through the portal, such as reading files, searching context, opening a browser page, checking logs, or pushing a task branch. The tool is the callable surface. A script, service, or hosted endpoint may implement it.Tool manifest
The human-readable tool manifest isTOOLS.md, the catalog that explains available tools for agents and builders.
Machine-readable manifest JSON files define schemas, routing, generation, and execution contracts. Use tool manifest for the human-readable catalog when the docs are discussing TOOLS.md; use machine-readable manifest JSON when the docs are discussing registry files or generated tool surfaces.
Script
Executable implementation behind a skill or tool. Scripts can be TypeScript, Bun commands, or other implementation files. Users should think in skills and tools. Builders use scripts when they need to inspect or change execution machinery.Capability
A configured system the OS can use. Examples include local storage, cloud artifact storage, workspace API access, Slack approvals, Discord approvals, Google Ads, Twilio, GHL, Sentry, or PostHog. Capabilities should be checked and reported in product language. A user should seeGoogle Ads is not connected; low-level configuration keys belong in reference docs.
Artifact
An app-native output with storage behind it. Artifacts can be reports, briefs, documents, pages, PDFs, DOCX files, HTML, JSON, CSV, images, or app-native records. The artifact record tracks provenance, storage, status, and execution metadata.Approval
A human decision required before a high-impact action continues. Approvals are guardrails. They define where OS pauses for a human decision before execution continues.Execution
A single skill run. Executions should record status, trace ID, input summary, source object references, artifacts, approval state, timestamps, and safe errors.Trace ID
A unique ID that connects a call, execution, logs, artifacts, approvals, and errors. Every OS call should emit a trace ID.Memory
Reusable context that helps agents work better over time. Memory can store preferences, summaries, prior decisions, and useful context. It should not store secrets or become the only source of truth for structured records.Structured data
Data that must remain exact and queryable, such as people, companies, tasks, notes, calls, opportunities, approvals, artifacts, permissions, and execution logs.Deprecated wording
Avoid these terms in public OS docs:| Old term | Use instead | Why |
|---|---|---|
| transport-layer implementation terms | OS or portal | Product docs should describe the product boundary first. |
| legacy workflow docs | skills | Skills are the approved workflows agents consume. |
| runbooks | skills | Use skills when the document means approved agent workflows. |
| interface | portal | Portal describes the safe product boundary. |
| script, when it means callable agent capability | tool | Tools are the callable operations agents invoke. |
| script, when it means reusable approved workflow | skill | Skills are the workflow layer users approve and agents run. |
| current build | local OS, cloud OS, current build path | Current build framing makes the docs sound temporary. |
| env matrix or piles of environment variables | capability matrix | Users connect capabilities; builders configure keys. |
| loose files or random files | artifacts | The product tracks outputs, provenance, storage, and status. |
| permission framework or permission matrix | approvals or guardrails | The product pauses high-impact work for human decisions. |