Always-on SOPs

RAG retrieves the right document when it’s relevant — but some material should always be present. That’s what a standard operating procedure (SOP) is for.

What you’ll learn

• The difference between RAG retrieval and an always-on SOP.
• Where SOPs live: the Company OS and the scoped Library.
• When to reach for an SOP instead of a plain Library item.

Retrieved vs. always-on

Most Library items are pulled in by RAG only when they match the task at hand. But your non-negotiables — brand voice, doctrine, compliance notes, escalation steps — shouldn’t depend on a worker happening to ask the right question.

The Company OS (open a Company → ⚙️ Company OS) is the team’s shared “operating system”: brand voice, doctrine, cadence, SOPs, compliance, and vendors. It’s the context every scoped worker inherits automatically — so an SOP recorded here is always present, not merely retrievable.

Two ways an SOP reaches a worker

1. In the Company OS — inherited by every worker on that team whenever a chat is scoped to the Company.
2. As a Library document — when a conversation is scoped to a Company (or for 🌐 Workspace items, always), the Library is folded into the worker’s context via RAG. Scope decides the audience: Workspace items reach every worker; Company items stay with that team.

Put your rules where they belong

Brand voice and compliance usually belong at Workspace scope (or the OS) so the whole organisation stays consistent. A team-specific runbook belongs at Company scope.

Keep SOPs lean

Anything always-on rides along in every relevant worker’s context. A short, sharp SOP beats a sprawling one — be deliberate about what truly needs to be ever-present.

Recap

An ordinary Library doc is retrieved when relevant; an SOP — in the Company OS or scoped in the Library — is always there for the workers in its scope. Use SOPs for the rules that must never be missed. Next, we go further: training a worker so a body of knowledge becomes part of who it is.

➡️ Next: Train a worker