Home / Articles / Agent workflows on ephemeral vaults / Versions / v1.1.0
Agent workflows on ephemeral vaults: what changed in v1.1.0
From v1.0.0 (2026-10-14, 362d46bff) to v1.1.0 (2026-10-18, this release), paragraph by paragraph.
0 paragraphs added, 0 removed, 3 changed in place, 51 unchanged. About 3 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
1 unchanged paragraph
Summary: There is a pattern I keep using for agents that work together: give them an encrypted vault as their shared memory and their way of talking, and let it exist only for as long as the work does. I wantwould like to capture it properly, as a series of architectures from simple to complex, each in a repository of its own with its agents, its keys, its fixtures and a CI job that proves it works, so that people and agents can fork them as templates, recipes and skills. The repository should run as one of the checks before anything reaches sgit's main branch. The key questions are the same at every level: how do you give agents shared memory, how do they communicate, how do they work asynchronously, and how do you know what each one is doing at any moment. The answer depends on who holds which key. Because the only thing that ever leaves the environment is ciphertext, you can be more relaxed about where the logs and the data go: it is all about the keys, and about whether the vault is ephemeral. A vault app can draw what the agents are doing, and the screenshot can go back into the vault. And I wanted to know how far it scales, so we measured it locally: a hundred writers posting ten entries each landed a thousand entries in an append lane in 4.9 seconds, none lost. The same test found four defects, which is the case for the release gate in one paragraph.
12 unchanged paragraphs, under In short {#in-short}, The pattern {#pattern}
Many of these vaults are ephemeral. They exist only for the agents to communicate, and when the work is done they can be deleted from the server, or simply left as ciphertext nobody holds the key to. I wantwould like to capture the pattern so that others can use it, and so that we keep proving it still works.
12 unchanged paragraphs, under Four questions at every level {#questions}, Seven architectures {#architectures}, Watched by a vault app {#watched}
One comment I keep hearing, and I wantwould like the same thing, is a visual representation of what the agents are doing. A vault app does it with almost no new machinery. It is a page that lives in the vault and renders from it: open the vault, the app draws its contents, take a screenshot, store it in the vault, and carry on. sgit's own skill for building them describes "a single index.html (plus its data and assets) that lives inside an SG/Send vault and renders straight from it", and the runtime gives the page access to the vault's files, its append lanes and, if the vault grants it, a model, while "the vault's key stays in the HOST; your frame never sees it". A vault server runs as a Docker image, and sgit can serve a vault's published folder locally with sgit vault serve, so the viewer can run wherever the agents do.
26 unchanged paragraphs, under The swarm, measured {#swarm}, Four defects, and the case for a gate {#gate}, The brief {#brief}…