The interesting Show HN launches of the last few weeks are not new models. They are the layers underneath the models: filesystems, snapshot managers, gateways and deploy tools that decide what an agent can see, what survives when it leaves, and what happens when two of them touch the same file. That plumbing is where multi-agent coding currently either works or quietly fails. Here are nine recent launches that each solve one piece of it.
A filesystem that expects agents to disappear
LayerFS starts from an awkward fact about coding agents: they spend most of their time thinking and only a small slice of it running commands. LayerFS treats each Bash call as an ephemeral workspace mounted over shared committed history. The agent mounts, runs, commits what changed and goes away, so the workspace is disposable while the result is durable. Each file tool call becomes one atomic store operation, and every commit lands on a branch, which means two agents editing the same file produce a recorded conflict rather than a silent overwrite. Because the store is shared and serverless, agents on different machines commit to it without a database server sitting in the middle.
A runtime you can host yourself
The managed agent APIs from the big labs are convenient and closed. Omnara is an open-source alternative under Apache 2.0. You write an `agent.yaml` with an instruction, a model provider and a machine pool, and the API runs the agent with tools, secrets, permissions and streaming already handled. It is written in Go and positioned as a self-hostable stand-in for both Claude Managed Agents and OpenAI's Agents API, so the durable-execution part of the stack is yours rather than rented.
Snapshots instead of rebuilds
An agent that loses its sandbox loses everything it installed. Ramet gives each session or attempt an isolated writable workspace over a shared immutable base, and changes only become persistent when your harness explicitly captures a snapshot. That makes it possible to fork independent attempts from one base, reset to a clean starting point and choose what survives, whether you are running best-of-N coding agents or resetting RL environments between rollouts. It is deliberately framework-neutral: LangChain, LangGraph, CrewAI, AutoGen and SkyRL each have a documented integration path, and everything else goes through Python, Go or HTTP.
Keeping the main context clean
Two launches attack the same problem from different ends. Pi Subagents Lite adds sub-agents to the pi coding agent with a deliberately tiny schema: four tools, `Agent`, `StopAgent`, `MessageAgent` and `AgentStatus`, with one-dot descriptions to keep token overhead down. Agents can run in the foreground or the background, with their own tools, extensions and model, across repo worktrees, and a live widget plus conversation viewer tracks tokens and cost per agent, with a watchdog for ones that get stuck.
Agent Workflow Skills works at the workflow level rather than the session level. It is a library of Claude Code skills, subagents and hooks built around proof: a supervisor sends each step to the cheapest model that can do it and escalates a tier after two failures, gates pass on exit code, a bug fix ships with a test shown to fail without the fix, and a session ends with a handoff note the next one picks up. The repository demonstrates the regression-proof recipe on one of its own commits and runs a self-check over frontmatter, links, scripts and hooks in CI.
Deploys an agent can take back
The failure mode here is familiar: the agent says "Deployed", and a file someone fixed by hand in cPanel last week is gone. Shipback is an SFTP deploy tool built around the undo. Every replaced file is backed up on the server before the upload starts, files are swapped in whole so a dropped connection leaves the old one rather than half a new one, and `--restore` puts the site back byte for byte. It refuses to restore over a live edit unless you force it, holds a lock so an agent and a person cannot deploy over each other, and its MCP server has no switch to delete server files or skip the backup.
Storage and routing underneath
Three launches fill in the bottom of the stack. Glider is a single-node vector database that treats S3-compatible object storage as the source of truth: every acknowledged write is durable before the server answers, and local RAM and SSD only speed up reads. It serves nearest-neighbour search with metadata filters over HTTP and JSON, and includes a Python client and an MCP memory server, so an agent's memory can sit in the same place as everything else.
ColdIVF is narrower and more specialised: a read-optimised vector index in Rust built for cold reads, where the first query matters more than steady-state throughput. You can call `prepare()` while the query embedding is still being computed so the index tables load in parallel, and a writer handles inserts, deletes, syncs and compaction while searches keep running.
Bifrost sits above the models rather than below them. It is an open-source AI gateway that fronts 23 or more providers with one OpenAI-compatible API, adding automatic failover, load balancing, semantic caching, virtual keys and budgets, and it works as an LLM gateway, an MCP gateway and an agent gateway. For anyone running more than one provider, it is the piece that turns a rate limit or an outage into a routing decision instead of an incident.
What they have in common
None of these launches makes a model smarter. What they do is make agent work resumable, attributable and reversible: state that survives the sandbox, commits that expose conflicts, snapshots you can fork, deploys you can undo, and a gateway that absorbs provider failures. That is the difference between an agent that demos well and one you can leave running.
