adrs: agents are much more useful with a company context layer

[shekharkadyan]

Adds adrs/agent-context-layer.md, per CONTRIBUTING.

Two things in it:

1. A view we'd like yours on — whether "context layer" is a pattern QM wants to support as a documented thing deployments can have.
2. Two bugs blocking our implementation of it, both already filed: sandbox.image is silently ignored when backend is "sprites" #272 and Tools that install a program don't work on AWS — the agent reports the command doesn't exist #350.

Happy to test against a branch.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[time-attack]

QM only injects a person’s own keychain automatically in their personal scope. In an ordinary shared conversation, the speaker’s own credential is not injected; credentials must instead be granted to the conversation, and a standing grant can then be reused by subsequent participants. I reproduced this with the focused keychain end-to-end tests and confirmed the controlling condition in src/core/orchestrator.ts. As written, “answers stay bounded by their own access” is therefore true for DMs but not established for shared rooms, which is important because permission preservation is the proposal’s central safety claim. Could this describe the per-speaker credential-brokering mechanism that prevents cross-participant reuse, or explicitly limit the integration to personal DMs?

[shekharkadyan]

Good catch, and you're right. I've pushed a correction.

I confirmed it in src/core/orchestrator.ts — materializeOwn() only runs when scopeId === personalScope(actor.id), and everything else comes from materializeStanding(scopeId), which is attached to the conversation rather than the speaker.

So the sentence was true for DMs and unsupported for shared rooms, and you're right that it's the wrong sentence to be loose about — permission preservation is the whole point of the design.

Taking your second option: explicitly limited to personal DMs. That's what we'd already scoped v1 to and documented on our side; the note just didn't say it.

The reason we haven't tried to work around it: in a shared room a standing grant would mean one person's token answering another person's question, which returns documents the asker can't see. That's precisely the failure the per-person model exists to prevent, so a partial version seemed worse than none.

I've noted that shared-room support would need brokering per speaker — injecting the credential belonging to whoever is talking, rather than one attached to the room. Not asking for it today, just flagging it as the thing that would unlock it.

Separately, thank you for reproducing it rather than taking the claim at face value. On #354 I'd got the cause wrong in the same way and your colleague's "I cannot reproduce this" prompted me to re-test — the trigger turned out to be much narrower than I'd written. Correction posted there.