Incremental Opportunities for Public Projects — 2026-07-31

Scoped to this pass's changed files (120 AIDigest articles 2026-07-26 through 07-30) checked against Projects/public-projects.md.

1. MCP's stateless spec revision directly affects voicebox_agent, agent_harness, and any MCP-serving project

MCP's biggest spec revision (finalized 2026-07-28) removes the initialize/initialized handshake and Mcp-Session-Id header entirely — any MCP server built to the old stateful spec now needs a 12-month-window migration plan. projects/voicebox_agent (Python, Voicebox, MCP) is the one project in the repo directly built on MCP server plumbing; worth checking whether it implements a session-carrying handshake that would need updating, since the practical fix (mint an explicit handle like a basket_id and pass it back as a plain argument) is a real code change, not just a version bump. This is also the same migration this vault's own AgentStack/Skills/.drafts/mcp-protocol-version-migration-audit.md draft already anticipates — worth applying that draft's checklist to voicebox_agent specifically as a concrete first test case.

2. Aurora DSQL's disaggregated compute/storage/coordination design is a relevant reference for multi_dashboard and fullstack_go_project

Aurora DSQL's system-design paper (MVCC + precision timestamps for coordination-free reads, OCC deferring coordination to commit time) is a clean, citable reference for the distributed-systems teaching goal multi_dashboard's README already states ("teaching REST, SSE, WebSockets, Kafka, JWT/OAuth, NoSQL, and AI agents"). Since multi_dashboard already spans FastAPI/Go/PostgreSQL/MongoDB/Kafka/Redis, a documented "why is multi-region OLTP hard" module referencing Aurora DSQL's actual production design would strengthen the repo's stated goal of "production-grade patterns... even when running in a local or simulated environment."

3. Docker Sandboxes / agent credential-scoping pattern is directly applicable to agent_harness

agent_harness is explicitly described as experiments in "how harness infrastructure (planning, memory, verification, sandboxing, sub-agents) determines agent reliability" — sandboxing is already one of its five named rungs. The three Docker "Coding Agent Horror Stories" items this window (Kiro production deletion, $29M secret leak, Docker CISO panel) give agent_harness three concrete, real-world failure cases to benchmark its sandboxing rung against — rather than a synthetic/hypothetical containment test, the repo could add a scenario modeled on the Kiro incident (agent given broad credentials, asked to "fix" something, tempted toward a destructive shortcut) and measure whether the harness's sandboxing rung actually blocks it. This would make the existing "measured rung-by-rung via controlled benchmark" framing concrete against a real published incident instead of only synthetic tasks.

4. Google's Tunix producer/consumer decoupling pattern is relevant to any future RL-training work in this repo

Tunix's core fix — decoupling rollout generation from the trainer so the trainer never blocks on the slowest episode — is a generalizable pattern beyond TPU-specific training. None of the current public_projects entries do agentic RL training, but if agent_harness or a future project adds a training/fine-tuning phase for measuring harness improvements empirically (rather than just benchmarking a frozen model), this producer/consumer decoupling pattern is the reference architecture to cite before hand-rolling a synchronous training loop that would hit the same idle-accelerator problem Tunix was built to fix.