Rules, pinned pages and packs

Left alone, get_context works like a good search: it finds the sections that best match the task and sends those. That's right for most of what you write. But some things should arrive regardless of what the task says, because they apply to everything, or because search alone would never think to include them.

There are three ways to make sure a page arrives. They differ in when it's sent and how the agent is told to treat it.

	Sent	Treated as	Who sets it
Rule	With every request	A hard constraint, listed under "Rules (always follow)"	Anyone who can edit the whole workspace
Always include	With every request, if it fits	Reference material	Anyone who can edit the whole workspace
Pack page	When the task is the kind of work the pack is for	Reference material	Anyone who can edit the whole workspace

Rules

A rule page is sent, whole, with every single request: every get_context call, from every connection, whatever the task. It appears at the top of the result under a heading that tells the agent to always follow it.

Rules are the only thing that ignore the token budget. If an agent asks for 2,000 tokens of context and your rules come to 3,000, it gets all 3,000 of rules and nothing else. That's deliberate: a rule that only applies when there's room isn't a rule.

To make a page a rule, open it and set Kind to Rule. The starter template makes "Brand voice" and "Style rules" rules for you. When you import Markdown, a page whose title mentions "guardrails", "style guide" or "style rules" becomes a rule automatically, and frontmatter can set it explicitly.

What makes a good rule

A good rule is short, unambiguous, and would cause real trouble if broken once:

• "Don't promise roadmap dates."
• "Only quote customers from the Approved proof page."
• "Discounts over 15% need a manager's sign-off. Don't offer them."
• "Say 'bookings', never 'appointments'."

A bad rule is long, situational or a matter of taste. "When writing to enterprise prospects in the healthcare sector, emphasize compliance..." is useful guidance, but it only applies sometimes, so it belongs on a reference page where search can find it for healthcare tasks, or in a pack.

Every rule costs tokens on every request, and every rule competes for the agent's attention with every other rule. Keep the total small. If your rules run to several pages, go through them and move anything that isn't truly universal.

Always include

Always include (the pin next to Kind) sends a page with every request too, but as reference material rather than a constraint. Use it for the small amount of context that's useful for nearly any task: a one-paragraph company summary, say, or a glossary of terms your team uses.

Unlike rules, pinned pages respect the budget. Whole pages (pinned pages and pack pages) can take up to three quarters of the agent's token budget, so search always has room left over. If a pinned page doesn't fit, it's skipped as a whole page, though its best sections can still come back through search.

Pin sparingly, for the same reasons as rules. Most pages are better left to search.

Packs

A pack is a kind of job, like "Outbound email" or "Release notes", plus the pages that job needs. When an agent's task matches a pack, the pack's pages come back too.

Packs exist for one reason: some pages belong together, and search returns sections one at a time. Your "Tone by channel" page doesn't mention cold emails, so search for "cold email to a CFO" won't find it. A pack for outbound email that always includes it fixes that. A pack is a bundle: when the task is that kind of work, the bundle arrives whole.

You'll find packs under Packs in the sidebar. Everyone in the workspace can see them; people who can edit the whole workspace can change them.

What's in a pack

Name. What the job is called, like "Outbound email". Agents see this.

Description. A sentence about what the job covers: "Cold emails, follow-ups and prospecting sequences to a specific person or list."

Good for. A few phrasings of the work as agents describe it: "writing a cold email to a finance buyer", "following up after a demo". These are what tasks are matched against. A model suggests them from the pack's name, description and pages, and rewrites them when those change; edit the list and it becomes yours. Keywords, if you add any, go into the description the model reads.

Pages. Each page is added in one of two modes:

• Always, whole page. Sent in full whenever the pack applies, as long as it fits in the budget.
• When relevant. Not sent automatically, but its sections are kept in search results for tasks the pack applies to, as long as they're related at all. Use this for pages that are often but not always useful, like proof points for an email. You can add a note saying when it applies; that note is for your team, not the agent.

Rules don't need to be added to packs. They're sent anyway.

How a task is matched to a pack

A pack is matched the way a page is: the task is compared with the pack's Good for phrasings, and the packs it comes close to are candidates. The judge (see How get_context chooses) then reads the task and each candidate and says whether the task really is that kind of work; the packs it's sure about apply. Several packs can apply to one task, and often none does, which is fine.

In practice, that means:

• Write phrasings the way agents actually describe the work, and vary them. "Writing a cold email to a prospect" and "drafting an outbound sequence" are both worth having.
• Keep each pack to one kind of work. A pack for "all marketing" will match everything a little and nothing well.
• If a pack applies to tasks it shouldn't, make its phrasings more specific.

An agent can also skip matching and ask for a pack by name, by passing pack to get_context. It can see your packs with list_packs. You can see which packs each request applied in the Pack column under Activity.

Suggested packs

Pages that agents' requests keep bringing back together are noticed. Once a week, the library looks for groups of pages that went out together often and asks a model to name the kind of work they serve. Groups that are one kind of work appear under Suggested on the Packs page, with their pages as "When relevant". A suggestion doesn't apply to any request until someone accepts it; open it to change its pages first, or dismiss it.

The starter packs

The Sales & Marketing template comes with seven packs: Outbound email, Blog post, Landing page, Ad copy, Competitive comparison, Social post and Fact check. They point at the template's starter pages. Treat them as examples to edit rather than a finished set. The packs that help most are the ones built around the jobs your team actually does every week.

A worked example

A support team writes a lot of replies about billing. They make a pack:

• Name: Billing reply
• Description: Replies to customers about charges, refunds, credits and invoices.
• Good for: replying to a customer about a refund; explaining a charge or an invoice; answering a double-billing complaint
• Always: Refund policy, Tone for customer emails
• When relevant: Plans and what's included, Known billing issues

Now "reply to a customer charged twice after downgrading" gets the refund policy and the email tone page whole, the relevant sections of the plans page and the known issues ranked first, and the style rules on top. Without the pack, it would likely have found the refund policy and missed the tone page entirely.

Choosing between them

• Must never be broken, applies to everything: make it a rule.
• Useful background for almost any task: pin it, and keep it short.
• Essential for one kind of job: add it to that job's pack as "Always".
• Often useful for one kind of job: add it to the pack as "When relevant".
• Everything else: leave it to search. That's most pages, and that's fine.