Reliability on t0ul

Calendar CRUD and export

Tue, 07 Jul 2026 00:00:00 +0000

Part of my AI Security Engineering series, a local email-to-calendar agent I build, then attack, then harden. If you have not set up the lab yet, start with Set up your lab. The lessons are on GitHub, and the agent itself lives at t0ul/emaildrop.

The quiet failure

Most of this book has been about a hostile email. This feature fails without one. Writing events to the calendar and exporting them is the agent’s one durable side effect, the thing that shows up on your actual phone, and the way it goes wrong is the most ordinary bug there is: it happens twice. The folder watcher restarts and re-reads an email it already processed. A request times out and the client retries. An export runs a second time. Every one of those is correct behavior, a safe operation repeated, and every one of them, done naively, puts a second copy of the same event on your calendar.

Durable execution and resume-verify

Tue, 01 Sep 2026 00:00:00 +0000

Crashes are not attacks, until they are

The last part governed the agent. This one makes it survive the boring disasters: a crash mid-task, a retry after a timeout, a context window that fills up. These are not attacks, they are the ordinary physics of running software, and the reason they belong in a security book is that the mechanisms you add to survive them become attack surface of their own. A system that can resume is a system that trusts something it wrote down earlier, and anything the agent trusts is worth examining.

Exactly-once side effects

Tue, 08 Sep 2026 00:00:00 +0000

When a retry is dangerous

The calendar chapter met this once already: re-ingest an email and the same event lands twice. There the cost was a duplicate on a screen. This post is the version where the cost is real, because the agents that matter do not only write calendars, they take actions, send a message, issue a refund, move money, and they retry those actions all the time. A request times out and the caller tries again. A process crashes mid-task and resumes. A client never saw the response and resends. Retrying is correct behavior and usually free, right up until the thing being retried has a side effect, at which point once-per-attempt is a bug with a dollar figure.

Context compaction and summarization injection

Tue, 15 Sep 2026 00:00:00 +0000

The summary is trusted context

A long-running agent runs out of room. The context window is finite, the conversation is not, so at some point the agent has to compact: summarize the older turns into a short running summary and keep only the recent ones verbatim. It is a reliability mechanism, the thing that lets a session last all day without blowing the budget. It is also, like durable resume, a place where the agent starts trusting something it generated earlier.

Agent memory architecture

Tue, 22 Sep 2026 00:00:00 +0000

Shared memory between agents

The last three posts secured one agent’s memory of itself: a durable log it can verify, side effects that fire once, a summary that does not launder instructions. This one steps up to the architecture, because real systems are rarely one agent. They are several, cooperating, and they coordinate through shared state, a blackboard that each can read and write. The moment memory is shared, it inherits every multi-tenant problem a database has, plus one that is specific to agents.