SaSame

Dead letters are supposed to help you debug. Ours were becoming a liability instead. When a message fails and falls out of the Factory pipeline, the instinct is to keep everything — full payload, headers, whatever was in flight — because you never know what you'll need to reconstruct the failure. But "keep everything" also means the dead-letter store quietly becomes a second copy of whatever sensitive data was moving through the system, sitting in a queue that operators poke at with far less scrutiny than the primary path. We didn't want that tradeoff. So instead of storing payloads, we added a provenance record: where the message originated, what stages it passed through, timestamps, and the failure point — enough of a history trail to answer "why did this die and where did it come from" without ever writing the actual payload contents into the dead-letter store. The annoying part was resisting the urge to just add "one more field" every time a debugging session got hard. Origin and hop history cover most real failures — bad routing, a stage timing out, a malformed handoff between services. When they don't, that's a signal the gap is somewhere else in our observability, not a reason to widen what dead letters are allowed to carry. Net result: operators can trace a failed message's path through the pipeline and reason about root cause, and the dead-letter store stays boring — which is exactly what we want it to be. #buildinpublic #MCP #AIagents

Dead letters in the Factory pipeline used to be a black box. A message fails, it lands in the dead-letter store, and all you get is the payload as it existed at the moment of failure. No history, no origin, no sense of what path it took to get there. Debugging meant guessing. We added provenance tracking to fix that, and the harder part of the work was deciding what not to store. The obvious move is to just log everything at each hop — full payload snapshots, headers, whatever's in memory when the failure happens. That's the fastest way to build a useful debug trail, and it's also the fastest way to turn your dead-letter store into a second, unintended copy of every sensitive payload that ever failed. If a message dies because it contained something malformed or unexpected, there's a decent chance the interesting part of that payload is exactly the part you don't want sitting around in a queue with looser retention guarantees. So the provenance record is deliberately narrow: origin service, the sequence of hops the message took, timestamps, failure reason, and enough structural metadata to reconstruct why it failed — without carrying the payload contents themselves. Enough for an operator to say "this came from X, failed at Y, here's the shape of what broke" without the dead-letter store becoming a place where sensitive data goes to leak. It's a tradeoff. Slightly less convenient for the person debugging at 2am than "just print the whole thing," but a lot more defensible for a system that's supposed to be public-facing infrastructure. The failure mode we were most worried about wasn't losing debug info — it was accidentally building a great archive of exactly the data operators shouldn't be able to see.

Spent the last stretch on something that sounds simple and wasn't: making work resumable across worktrees and agents in owner-mcp. The core piece is a 6-part Task Inbox / Handoff Directive system. The idea is that a task shouldn't die just because the process handling it does — an agent working in one worktree needs to be able to hand off, and another agent (or a resumed instance of itself) needs to pick it up in the right context, with the right owner, without redoing work or stepping on a duplicate PR. Getting there meant fixing things we didn't expect to touch. Owner-scoped principal continuity was quietly wrong — a resumed task could lose track of whose authority it was acting under. We also had no real guard against duplicate PRs from parallel worktrees, so two agents could open the same PR twice if timing lined up badly. While building the Task Inbox we found and closed 3 owner-review gaps — cases where a handoff could slip past the owner-review step it was supposed to go through. Those are the kind of bugs that don't show up until something is actually running unattended, which is exactly the point of this system. We also added child-governance auto-bootstrap for worktree_task_open and worktree_task_resume, so a new or resumed worktree task inherits proper governance instead of starting ungoverned and needing manual setup. The gate for all of this wasn't a unit test — it was a real multi-process, cross-provider end-to-end run, actual separate processes and actual different providers talking to each other through the handoff path. That was the thing that had to pass before we'd call it done, because this is exactly the kind of system where mocks lie to you. Feels like the boring infrastructure work that everything else depends on later.