Fourth post in the agent sandbox series. Move progress out of container memory onto a shared disk, then delete the working container on purpose — another one picks up at page 17. Including the honest part: this "automatic recovery" still needs a human to press something.
Third post in the agent sandbox series. A warm pool is the taxi rank at the airport: instant pickup, engines burning fuel while empty. Plus an honest account of the three things this dispatcher gets wrong — which are exactly what forces the next posts.
Second post in the agent sandbox series. One container per task sounds obvious, and it makes the user wait 45 to 90 seconds after they hit submit. Where those seconds actually go, and why the interface built for managing a cluster has no business on the path a user clicks.
First post in the agent sandbox series. Ask an AI to work for two hours straight and the gap between "it runs" and "it ships" turns out to be one thing: isolation. A small service, deliberately killed by the system, makes the problem visible. Jargon is explained as it appears — no Kubernetes background needed.
Where the line runs between an ontology, a knowledge graph, a database schema, a workflow and an agent — and why I think enterprises should never build a top-down global ontology, but derive one backwards from the actions their agents are allowed to take.
After going through the public material, my conclusion is that what makes Glean valuable is not that its search is good — it is that it finished the grinding work of "who is allowed to see what". Also my take on the claim that long context kills RAG.