Six projects from the last few weeks that caught our attention: A wildfire analysis prototype that maps the fire’s spread over time and tracks hot spots, made with Opus 5.5.

Day 7 of building DevBox, our internal coding agent. We started on Codex CLI. Over the summer we moved stage after stage to Deep Agents. Here's why, and what it taught us about who should own orchestration. Codex CLI got us to a working product fast. It's a great coding agent. But we were driving it as a subprocess, and as the workflow grew we kept losing control of three things: what it read, which session it resumed, and whether each step actually ran. Examples: • Resume "last session" could pick a sub-agent's session when several shared a folder • Prompt updates weren't picked up on resumed rounds • An OOM-killed child process left the pod in an error state we kept polling We patched around them: resume by marker instead of "last", reinstall the system prompt on resume, detect dead pods. Each fix worked, but we were building an orchestrator out of workarounds around someone else's CLI. So we flipped it: Python owns orchestration, the model only does reasoning. With Deep Agents (LangGraph underneath), each repo gets its own in-process agent with its own context, checkpointed to SQLite, so it resumes exactly where it stopped. What moved from prompts into code: • Which files and skills each agent starts with • Retry and backoff, including rate limits with jitter so parallel workers don't retry in lockstep • Schemas for every handoff, enforced with structured output It wasn't a big-bang migration. Each piece shipped behind an experimental flag we could turn on per task: implementation first, then distillation and review. Old and new ran side by side until the new path won. One win, previously Codex agents would often ignore the instructions to start per repo subagents unless reasoning was set to high. This decision now moved to Python orchestration. Deepagent planner reports which repos are involved, harness owns starting implementation agents. Consistent behavior without unnessary reasoning tokens. Lesson: let the model reason and let code orchestrate. Every time we asked a model to "remember to do X next", it eventually didn't. Every time we moved X into code, it stopped being a problem. Tomorrow: proving the change actually works.

Day 3 of building DevBox, our internal coding agent. Yesterday: where it runs. Today: getting code into the sandbox quickly, and what happens when sandboxes misbehave. Our tasks touch several big repos. Cloning them at the start of every task burned time before the agent did anything useful. First idea: one shared volume with a git worktree per task. That broke fast. Concurrent sandboxes all wrote to the same .git directory and stepped on each other's locks and refs. Shared mutable state + parallel agents = pain. What we run now: A Kubernetes CronJob clones every repo onto an EBS volume every 30 min and takes a VolumeSnapshot. When a task starts, the control plane mints a fresh PVC from the latest snapshot and mounts it. Attaching takes seconds. Nice properties: • Every task gets its own copy, so no shared .git • If a clone fails, the job doesn't publish, and the last good snapshot stays live • Adding a repo is a one-line ConfigMap change, no redeploy • Old snapshots get pruned to the last 3 30 minutes is still stale for a fast-moving repo. So the harness also syncs each planned repo from origin before planning and again before committing. The snapshot makes it fast, and the sync keeps it correct.