Devin (Cognition)

A Devin session begins each run with a fresh sandbox and no past. AIStor Memory gives it memory: a mount of a MinIO AIStor Memory Bucket (a cortex) that the agent both works in and remembers through. The session's files and the knowledge it earned live in the durable cortex — your storage, your keys — so the next session re-mounts the same state at full fidelity, on any host.

Devin persists workspaces today by hypervisor-snapshotting the whole sandbox VM, which ties the workspace to one host's local disk. Once the cortex holds the agent's memory, that snapshot becomes an optimization rather than a correctness requirement — any host can resume by re-mounting the cortex.

The intended release shape is one runner-image change plus one per-session storage field. The runner hook owns the config file, local store path, mount, and wait loop.

Golden path

1. Runner image bundles aimem, FUSE userspace, and devin-aimem-workspace.
2. Control plane exposes one per-session workspace_storage field with bucket (a cortex — see below), endpoint_url, and credentials_secret_ref.
3. Runner startup maps that field to environment variables and runs devin-aimem-workspace mount before the agent starts.

Everything else — atomic upload semantics, agent-memory warmup, the aimem skill — is owned by AIStor Memory and ships ready to use.

Secrets are not automatic: the runner contract above only mounts the workspace. To give the agent credentials, the runner must run the launcher-side provisioning handshake before starting the agent:

# Keep the store token in the launcher env, not argv (argv shows up in
# process listings and shell history).
AIMEM_SECRET_STORE_TOKEN="$STORE_TOKEN" \
aimem secret provision \
  --store-endpoint "$STORE_URL" \
  --grant OPENAI_API_KEY=openai --grant GITHUB_TOKEN=gh-pat \
  -- <agent-command>

This fetches only the granted secrets from your store and injects them as environment variables into the launched agent. aimem scrubs the store token and the mount credentials from the child's environment, so they never reach the agent. --grant VAR=secret-name is required and repeatable.

If your secrets already live in the cortex itself (written with aimem secret put team-foo-devin <name>), swap --store-endpoint for --cortex team-foo-devin — the two sources are mutually exclusive and exactly one is required. The cortex source resolves each grant over the Memory API using the same AIMEM_ENDPOINT_URL / AIMEM_ACCESS_KEY / AIMEM_SECRET_KEY as the mount.

Runner contract

The session field is intentionally small:

{
  "workspace_storage": {
    "kind": "aimem",
    "bucket": "team-foo-devin",
    "endpoint_url": "https://aistor.team-foo.example.com",
    "credentials_secret_ref": "devin-aimem-team-foo"
  }
}

The runner resolves credentials_secret_ref to the cortex's signing credentials and exports them as AIMEM_ACCESS_KEY / AIMEM_SECRET_KEY (plus AIMEM_SESSION_TOKEN when they are temporary/scoped), exports AIMEM_BUCKET and AIMEM_ENDPOINT_URL, then calls:

devin-aimem-workspace mount

aimem cortex credentials team-foo-devin mints scoped, session-bound credentials for a single cortex. It prints ready-to-source export AIMEM_ACCESS_KEY=… / AIMEM_SECRET_KEY=… / AIMEM_SESSION_TOKEN=… lines whose access is intersected down to that one bucket.

The hook defaults the workspace to /workspace and AIStor Memory's mandatory local store to /var/cache/aimem/devin. It generates the config at /etc/aimem/devin.yaml, folding the runner's AIMEM_ENDPOINT_URL into the YAML's endpoint_url: key. The config carries the mandatory version: "1.0" key, the endpoint, and the local store, so the mount is a single reviewable --config invocation with no other flags:

aimem team-foo-devin /workspace --config /etc/aimem/devin.yaml

# /etc/aimem/devin.yaml — written by the hook from the runner's env
version: "1.0"
endpoint_url:
  - https://aistor.example.com # from $AIMEM_ENDPOINT_URL
local: /var/cache/aimem/devin

Signing credentials stay in the environment (AIMEM_ACCESS_KEY / AIMEM_SECRET_KEY) — never a flag, never in the YAML. The local store may equally be supplied by the --local /var/cache/aimem/devin flag or the AIMEM_LOCAL env var; at least one of the three is required. On pause or teardown, the runner calls:

devin-aimem-workspace unmount

What this gets you

• Durable memory across hosts. The cortex holds the session's memory — its files and the knowledge around them — so any host can mount it and resume. VM snapshots become an optimization, not a correctness requirement.
• Costs scale with the working set. Only files the agent actually wrote land in the cortex — not the entire VM state.
• Portable memory. Same cortex, any region, any cloud. SaaS and customer-VPC modes use the same integration shape; only the storage backend differs.

Get in touch

If you operate a Devin deployment (SaaS or customer-VPC) and want to evaluate cortex-attached memory for your sessions, get in touch via your MinIO contact. We'll bring:

• A one-page pitch for cortex-attached memory on Devin.
• The technical contract we'd validate together (image bundling plus a control-plane field to point a session at a cortex).