How get_context chooses

get_context is the tool that does almost all the work. An agent passes a task in plain words, and gets back a Markdown bundle of rules and reference material sized to fit its context window. This page explains how that bundle is put together, step by step, so you can reason about why something did or didn't come back.

You don't need any of this to use the product. It's here for when you're tuning a workspace, or wondering why an agent missed something obvious.

The inputs

Input	What it does
task	Required. What the agent is about to do, in plain words. The more specific, the better the result: "cold email to a CFO at a 200-person logistics company evaluating Slotly" beats "email".
max_tokens	The budget, from 1,000 to 30,000. Defaults to 12,000.
pack	Apply this pack, instead of matching packs to the task.
tags	Only search sections with these tags.
folder	Only take material from this folder and its subfolders.

Step 1: taking the task apart

A task is usually a whole job: audience, channel, competitor and deliverable in one sentence. Before searching, a small model takes it apart into a plan: the names it mentions and what each one is (a competitor, a product, a persona, a market), what will be produced, two or three short searches that each cover one facet of the task, and any hard constraints it states. The plan is only ever added to the task's own words, never put in their place: the task is always searched as written, and the plan's searches run alongside it. If the model is slow or fails, the task alone is searched. Owners can see the plan for each request in the activity log.

Step 2: rules

Every published rule page that the connection can see, and that hasn't expired, is included in full. Rules come first in the result, under "Rules (always follow)".

Rules are never cut for space. If they come to more than the budget, they still all go, and there's simply no room left for anything else. This is why rules should be short.

Step 3: pinned pages

Pages set to Always include come next, in full, as long as they fit. Whole pages (pinned and pack pages together) can use up to three quarters of the budget; a pinned page that would push past that is skipped, though its best sections can still turn up through search.

Step 4: packs

Each pack carries a few phrasings of the work it's for, like a page's Good for list, suggested by a model from its name, description and pages and editable by owners. The task is compared with every pack's phrasings, and the packs it comes close to are candidates. When the judge is on (see below) it reads the task and each candidate pack and says whether the task really is that kind of work; the packs it is sure about apply. Without the judge, a close enough match applies. Several packs can apply to one task, or none, which is fine and common.

If the agent passed pack, that pack applies and no others are matched.

When a pack applies:

• Its Always pages are added in full, after rules and pinned pages, as long as they fit in the three-quarters allowance.
• Its When relevant pages aren't added directly. Their sections are kept past the closeness window in step 7, as long as they're related at all.

Step 5: pages matched by what they're for

Every published page carries a few short phrasings of the work it's for, under Good for in its properties: "writing a cold email to a finance buyer", "answering a pricing objection". They're suggested by a model when the page is published and can be edited (see Pages). The task is compared with these phrasings, which is a different comparison from searching the page's content: a page of cold-email rules never mentions a CFO or a competitor, but "writing a cold email to a finance buyer" is close to "cold email to a CFO switching from Avalara".

The closest few pages come in this way. A page the model marked as one to read whole (rules, voice, style, templates, a process) is added in full, after pack pages, if it fits. Any other page gets its best two sections kept in the search below even when they'd otherwise fall outside the window in step 7.

Folders carry phrasings too, written from the pages inside them. A task that matches a folder's lifts the pages in it into the search below.

Step 6: search

The rest of the budget is filled by searching sections. The task and each of the plan's searches are run, and their rankings combined, so a section that does well for several facets comes out on top. A few things go into each ranking:

• Meaning. The query and every section are compared as embeddings, so "client was double-billed" finds a section about "charged twice".
• Words. A full-text match on the actual words, so exact names, product codes and jargon rank properly even when meaning-based search would be fuzzy. Words in a section's headings count for more than words in its body.
• Names. The names the plan found in the task (a competitor, a product, a market) are matched as exact phrases in sections and page titles. A section that holds one always surfaces, however it does on meaning, and is ranked higher.
• Questions. Alongside every section, the model writes the questions that section answers ("what is the refund window after a downgrade?"). A task that reads like one of them brings the section in, even when its text is phrased quite differently.
• Tags. Tags from your vocabulary that appear in the task boost the sections tagged with them.

What each section is matched on includes more than its text. It's the section's heading path, its page's folder, type and tags, and then the content. That's why specific headings and sensible folder names make such a difference.

Then the search widens by one step from the pages behind the best hits:

• Links. Pages those pages link to with [[Page title]], and pages that link to them. In the background, the library also works out links the text doesn't have: for each page and its nearest neighbours, the judge is asked whether someone using the one would also need the other (not whether they're similar, which search already knows, but whether a template needs its tone page, a battlecard its pricing). The confident answers are followed too, and the strongest are shown on the page as links its authors might add.
• Folders. Siblings in the same folder, when that folder is about one thing. Each folder gets a coherence score in the background; a "Voice and tone" folder earns the lift, a "Battlecards" folder holding every competitor doesn't, because for a task about one competitor its siblings are exactly the wrong pages.

Pages reached this way join the candidates with a weight that says how they were reached. The judge decides whether they belong, like everything else, so a bad link costs a candidate slot, not a wrong answer.

Step 7: keeping it focused

The budget is a ceiling, not a target. After ranking, only sections whose meaning is close to the best match are kept. A narrow question ("what's the refund window?") gets a few sections back, not 12,000 tokens of loosely related material. A broad task ("write a comparison page against Slotly") naturally keeps more.

When the judge is on, it decides this instead. For each candidate section it answers two questions: would someone doing this task use it, and is it specifically about a different competitor, product, market or audience than the task names. Sections that fail either are dropped, so a cold email about Avalara doesn't carry the TaxJar battlecard along just because the two read alike. The sections it is surest about fill the budget first.

Rows of a table are treated a little differently. A row is a few facts, not a passage someone "uses", so only the second question counts for it: a row about a different plan, region or product than the task names is dropped, and otherwise the closeness test above decides. The judge sees the table's description alongside each row, so it knows what the row is a row of.

A page marked as one to read whole is never sent in pieces: if one of its sections is kept, the whole page comes instead, if it fits, and otherwise nothing from it.

Sections are then added in order until the budget is reached.

The judge

The pack decision and the keep-or-drop decision above are made by a judge: a small, fast model (Jev, from typesafe.ai) that answers yes/no questions with a probability rather than writing text. Every question about one request goes in one call, which adds a few hundred milliseconds and costs a fraction of a cent.

It runs in one of two modes, set by the operator:

• Gate. The default. Its answers apply: the packs it is sure about apply, and sections it says don't belong are dropped.
• Shadow. The judge answers every request and its answers are logged, but the result is built the old way, so its decisions can be compared with the heuristics.

If it's slow or fails, the heuristics take over for that request. Its verdicts for each request are kept with the request log.

Once the judge has approved the same answer to the very same task twice, that answer is remembered: the next time the task comes in, the remembered verdict stands in for the judge, until any of the pages involved is republished or two weeks pass without the judge confirming it again.

When nothing matches

If nothing comes close enough to send, the agent is told so and asked to check with the user rather than guess. It's also told the titles of the two or three nearest pages, with their ids, so it can read one if it plainly covers the task. Those requests show up under Activity → Nothing found, with the same nearest pages, which is where the gaps in a library show.

Keeping the library sound

Two pages that disagree, or one that repeats another, beat any ranking: an agent given both can't know which to follow. When a page is published, a model reads it next to its nearest neighbours and flags any fact, number or rule it states differently, and any ground it covers that another page already does. The flags appear at the top of the page for its owners, with the wording from both pages, until someone marks them resolved.

Step 8: the result

The bundle is rendered as Markdown:

1. Your agent instructions, if you've written any, under "Instructions from the [organization] team".
2. A comment naming the packs that applied and the tags found in the task.
3. Rules (always follow): each rule page in full.
4. Reference: pinned pages and pack pages in full, then search results as excerpts grouped by page.

Each page is labeled with its type, whether it's the full page or excerpts, and its page_id, which the agent can pass to read_page to get the whole thing. Usage notes appear under the page title, and pages with an attached file say so and point at get_file.

If nothing at all matches, the agent is told that the workspace may not cover this and to ask rather than guess. Those requests show up under Activity → Nothing found.

Over the REST API you can get the same Markdown, or JSON with every page, its reason for being included (rule, pinned, recipe for a pack page, use for a page matched by what it's for, link for one reached through a link from a page that matched, folder for a sibling in a coherent folder, or search), and a similarity score for each searched section. See the REST API reference.

What's never included

• Drafts. Only published versions are searched or sent.
• Expired pages, after their expiry date.
• Anything the connection can't see. A key limited to some folders gets nothing from outside them; a member gets nothing from folders they don't have access to.
• Other people's private notes. Your own private notes come back to your own connections, labeled as yours; nobody else's ever do.

Sizes are estimates

Token counts throughout the product are estimates (roughly four characters to a token), not exact counts for any particular model. They're close enough for budgeting, but if you're right at the edge of a model's limit, leave some room.

When results look wrong

The usual causes, roughly in order of how often they come up:

The page isn't published, or has unpublished changes that contain the bit you're expecting. Check the chip at the top of the page.

The fact is buried in a big section. A 900-token section about "Policies" will lose to a 150-token section about "Refunds after a downgrade" every time. Split it with specific headings.

Nothing in the task points at it. If the task says "write to Dana" and Dana's page only says "the CFO persona", nothing connects them. Agents get better results when they describe the audience, channel and topic. Your agent instructions can ask them to.

It's essential but not similar. Voice guides, formatting rules and templates rarely resemble the task they apply to. Check the page's Good for phrasings: if they don't name the kind of work agents actually describe, edit them. Link the page from the pages it belongs with, so a hit on one brings it along. Failing that, put the page in a pack as "Always", pin it, or make the important parts a rule.

The wrong pack applied, pulling in pages you didn't want. Check the Pack column in Activity, and the pack's Good for phrasings: if they'd fit most work in the company, make them more specific.

The budget is full of rules. If your rules use most of the budget, search has no room. Trim them.

Troubleshooting covers problems with connections and keys.