Skip to main content
ResourceAttachment is how a session sees durable inputs. This is an important shift in mental model:
  • not everything should become prompt text
  • not everything should become global memory
  • many useful inputs should instead be attached resources

​
Current resource kinds

The current public kinds are:
  • workspace_directory
  • local_file
  • learnings_memory_store
  • session_runtime_memory
Reserved for later:
  • vault
  • remote_file_store
  • repo_mount

​
Default resources

Every new session automatically receives default local resources:
  • the agent workspace directory
  • the agent learnings store
  • the session runtime directory
That gives the harness:
  • shared agent substrate
  • shared agent-level lessons
  • isolated per-session continuity

​
Why this split matters

The most important distinction is:
  • session-local
    • runtime scratch state
    • session-specific checkpointing
    • session-specific working buffer
  • agent-level
    • reusable learnings
    • durable workspace substrate
    • stable steering files
If those are mixed, long-lived agents become hard to reason about.

​
Access model

Each resource carries:
  • sourceRef
  • mountPath
  • access
Current access values:
  • read_only
  • read_write
This means the resource contract is about:
  • what the resource is
  • where it appears in the runtime
  • how writable it is
not about which product layer invented it.

​
Good design rule

Ask these questions in order:
  1. should this be durable across sessions?
  2. should it be isolated per session?
  3. does the harness need it as a mounted input, or just as summarized prompt text?
If the answer is:
  • durable + isolated + directly useful to execution
it probably belongs as a ResourceAttachment.

​
Future direction

The public contract is ready for richer resources later:
  • vault-backed credentials
  • attached repositories
  • remote file stores
  • work-specific attached artifacts
Those should be added without changing the core meaning of Session.