Load agent catalogs each turn instead of caching them on the chat

[AshishKumar4]

What does this change?

Three commits, one concern each.

Load catalogs each turn. A chat cached its agent catalogs and never loaded them again. The
agent could not see a skill added after the chat opened. A new skill reached the slash-command
picker at once, because that list is live, but it never reached the agent's catalog. The user had
to open a new chat. A failed load was cached the same way, as null, so one failure read as an
empty library for the rest of the chat. The cache caused both faults. A catalog states what a
session can reach now, which is not a fact a chat can hold. This loads it on every runAgent
pass and deletes the snapshot type, the completer, the chat field that held it, and their tests.

Stop asking a connection that has no catalog. Scheduler answers null on every call, and the
Workshop cannot tell which ambient gatekeepers have a catalog without asking. null now means the
gatekeeper has no catalog, and the Workshop remembers that per connection, in memory only, so a
gatekeeper that gains a catalog in a later version is asked again on the next activation of the
workspace. An empty catalog is {entries: []} and is loaded every turn. A failed load is not
remembered.

Receiving the catalog is not an observation. The catalog reaches every chat's prompt
automatically, so it is expected and mandatory, and it must not contain anything that needs
observer verification or every workspace would be affected at once. Treating it as one recorded
an action and a transcript entry per turn, and Context's excludeObservers check could refuse
the whole catalog in a shared workspace once the owner added a private collection.
getAgentCatalog() drops its authorizer parameter, Context drops the observation and observer
tracking from its catalog, and Scheduler and the integration fixture drop the unused parameter.
Reading an item through the session is still an observation.

Cost

One getAgentCatalog call per ambient gatekeeper that has a catalog, each time runAgent runs.
An automatic compaction reruns the turn, so that turn loads twice. No action records, no
transcript entries.

A failure costs one turn's catalog. The next turn loads it again.

Checklist

Checking every item does not guarantee acceptance. Maintainers determine whether
a pull request meets the contribution policy.

• This is a small, concrete change; it is not a feature, refactor, or low-value cleanup.
• I understand that maintainers decide whether the change is obviously correct and trivially verifiable.
• I have read and followed the contribution guidelines.

---

[github-actions]

Preview: pr267-fix-refresh-a-6c536a71

https://pr267-fix-refresh-a-6c536a71-router.cloudflare-os-previews.workers.dev

Dashboard · deleted when this PR closes

[ask-bonk]

Submitted 2 actionable inline findings.

github run

[ask-bonk]

Submitted 1 actionable inline finding.

github run

[ask-bonk]

• [P1] Legacy chats still undercount refreshed catalogs (agent-compaction.ts:270): Existing totalTokens records lack measuredSystemPromptChars, so catalog growth is treated as zero. Fall back to a full estimate when the prior prompt length is unknown.

• [P2] In-flight authorization can outlive catalog timeout (overseer.ts:12976): Liveness is checked only before authorizeObservation(). If observer enforcement is still awaiting when the catalog times out, it can later record/capture an observation against another step or turn. Revalidate before recording side effects.

github run

[ask-bonk]

Submitted 1 actionable inline finding.

github run

[ask-bonk]

Submitted 1 actionable inline finding.

github run

[ask-bonk]

• [P2] Hidden ambient catalogs are still loaded (overseer.ts:7887): Spawned chats exclude bindings via config.env, but this loads every ambient catalog before filtering by seedMap. It records observations and observer restrictions for data never exposed to the agent. Load only ambient targets present in the chat’s bindings.

• [P2] Optional catalog methods now fail every turn (overseer.ts:7902): Gatekeeper.getAgentCatalog() is optional. Ambient implementations that omit it now generate an exception, issue report, and warning on every turn rather than once per chat. Unsupported catalogs need a non-error path.

• [P2] Legacy catalog snapshots remain persisted (overseer.ts:7667): Removing alwaysAvailableCatalogs from the TypeScript type does not remove it from typed storage. Existing snapshots, potentially hundreds of KiB per chat, remain stored and deserialized indefinitely. Delete the legacy property and persist the cleaned context.

github run

[ask-bonk]

• [P2] Do not reinterpret existing null responses as permanent (overseer.ts:7924): Previously, null only meant “no catalog” and could be temporary. Memoizing it workspace-wide prevents later catalogs from appearing in any chat until the Overseer restarts. Use an explicit capability declaration or continue retrying null.

github run

[AshishKumar4]

Replies to the two Bonk findings on de95ab3.

Hidden ambient catalogs are still loaded. The premise does not hold. The ambient fold (prepareChatBindings, "Fold the ambient resources into the seed") runs after both seed branches, spawned and normal, so every id in alwaysAvailableCapsuleIds is in the seed map. The one exception is an id whose record is gone, and the load makes no call for that id either (if (!record) return [gatekeeperId, null]). Nothing is loaded that the chat does not expose.

Do not reinterpret null as permanent. This is deliberate. null has always meant "this gatekeeper has no catalog": Context returns Promise<AgentCatalog> and never null; Scheduler returns null on every call; there are no other implementers. The getAgentCatalog doc now states it, and "empty right now" is {entries: []}, which is still loaded every turn. The memo is in memory, per Durable Object activation, so a gatekeeper that gains a catalog in a later version is asked again on the next activation and every chat converges. A declaration flag was considered and rejected: it would restate a fact the interface already carries (the method is optional) and would need a backfill for every existing ambient record.

[devin-ai-integration]

Devin Review found 1 new potential issue.

1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

[ask-bonk]

• [P1] Private Context metadata bypasses observer authorization (library-gatekeeper.ts:330): loadEnabledContextCollections() includes private collections, whose titles, descriptions, and skills are now injected into shared chat prompts without observer checks. Restore authorization or exclude private entries.

github run

[AshishKumar4]

On the two P1 findings (Bonk, Devin) that private collection titles, descriptions, and skill names now reach collaborators through the prompt without an observer check: this is the intended change, decided by @kentonv. Receiving the catalog is expected and mandatory, so it is not an observation, and the catalog must not contain anything sensitive; if it did, every workspace would be affected at once. The getAgentCatalog doc now states this contract. Explicit reads of a context item through the session remain observations, as before, so a collaborator without access is still refused there. Kenton, please confirm that private collection metadata in the catalog is acceptable under that rule; if not, the alternative is for Context to leave private collections out of the catalog in shared workspaces, which is a Context-side change.