Giving Every Sandbox a Memory of Its Own

Boxxkite is partnering with MemCode to give agents running inside sandboxed workflows durable, scoped memory. Boxxkite keeps every sandbox clean and isolated; MemCode gives the agent inside it the context to pick up exactly where the last session left off. Two different problems, solved by two teams who each specialize in one of them.

The reset is the point

A boxxkite sandbox is disposable by design. Fresh filesystem, fresh process tree, no residue from the last session, torn down the moment it's done. That reset is what lets teams run agent-generated code with confidence: one session shouldn't leave anything behind for the next, and one tenant should never inherit another tenant's environment. Isolation and disposability aren't the tradeoff here — they're the entire point of the product.

The cost is familiar to anyone who has used a coding agent for more than a day. A fresh sandbox doesn't know the decisions already made in the repository: which approach was rejected, why a dependency is pinned, what the team considers done, which command actually verifies a change. Re-explaining that context on every task turns real engineering work into repeated setup, and a bigger context window doesn't fix it — that only helps an agent stay coherent inside one conversation, not across the ones that come after it.

Memory belongs outside the box

Boxxkite and MemCode solve different halves of the same workflow. Boxxkite provides the isolated place where an agent can safely execute. MemCode provides the durable memory layer that decides what's worth keeping, preserves it outside the sandbox, and returns the right slice of it on a later task. The sandbox stays exactly as clean as it needs to be; the agent using it gets to be less forgetful anyway.

MemCode's approach treats memory as infrastructure rather than an embedding index bolted onto a chatbot. New information is routed to specialized memory agents, extracted into structured knowledge, then run through a judgment pass that decides whether it should be added, merged into something that already exists, superseded, or left out entirely — only after that reasoning completes does anything get written. It's built around the failure mode that actually sinks most memory products: a store that quietly fills up with stale, duplicated, or contradictory facts because nothing was ever responsible for reconciling them. Retrieval follows the same philosophy — a simple question needs one lookup, a harder one triggers several, planned at runtime rather than hard-coded per query. MemCode calls the relationship-learning piece of this Recall Bond: when an answer genuinely needs two memories together, that pairing strengthens the connection between them for next time, so the memory graph gets more useful the longer it's used.

MemCode backs this with real numbers rather than leaving it as marketing copy — 95.6 on LongMemEval and 94.2 on LoCoMo, broken down by category rather than collapsed into one headline figure. Benchmark scores in this category are notoriously hard to compare across vendors, so we hold every number we cite to the same bar we hold our own to: a disclosed methodology and a per-category breakdown, not a bare percentage.

Scoped access, not a blanket connection

A memory connection follows the same principle boxxkite already applies everywhere else: least privilege. Boxxkite has a curated, outbound-MCP catalog — a small, boxxkite-reviewed list of external MCP servers, alongside entries like Slack and Linear — that a sandbox session can be granted a scoped connection to, enforced by a real per-session Kubernetes NetworkPolicy rather than a blanket allow-list. MemCode is now one of those catalog entries, live on boxxkite's own hosted control plane, and we've verified directly against a real cluster that a granted connection opens network access to exactly MemCode's memory endpoint and nothing else. The execution environment stays isolated; memory stays durable, purpose-built, and reachable only when a session has actually been given that connection — and the remaining piece of engineering ahead of us is the runtime path that lets a sandboxed agent call it directly, the same way boxxkite's browser tool already reaches the open internet from an otherwise locked-down sandbox.

What an agent gets to carry forward

The value shows up in ordinary engineering moments, not a demo reel. A later sandbox starts already knowing the repository's preferred test command, remembers that a migration needs a dry run first, or understands why a workaround exists before trying to remove it. It builds on a decision instead of reopening the same debate from scratch — the kind of context that normally lives in one engineer's head and nowhere else, surfaced automatically the moment it's relevant again.

None of that requires a bigger model. It requires somewhere for the knowledge to live between sessions, and a real path to get the right slice of it back out when it matters. We're also building durable memory into boxxkite directly — that work, internally called MemoryBase, is real and in progress, on a timeline we'd rather get right than rush. MemCode is how agents get durable context now, without waiting on that timeline first.

Clean sandboxes. Durable knowledge.

A sandbox should be thrown away the moment its task ends — that's what makes it safe to run code you didn't write and can't fully vouch for. But the knowledge an agent builds while it's running there — your conventions, your team's decisions, the reasons behind the code as it exists today — shouldn't be thrown away with it. That's the promise of this partnership: not a bigger prompt or a longer transcript, but a practical way for agents to keep the right context without ever asking the sandbox itself to remember anything at all.