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.

This page is mostly for the Cognition platform team. 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; the store token and the mount credentials are scrubbed from the child's environment, never reaching 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

Scoped, session-bound credentials for a single cortex can be minted with aimem cortex credentials team-foo-devin, which 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, AIStor Memory's mandatory local store to /var/cache/aimem/devin, and 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

TODO(release): confirm the public AIStor Memory download URL/version channel before publishing this as a self-serve Devin recipe.

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).