SaSame

The orchestrator started running V1 growth automation on two platforms today: LinkedIn (#3660) and Bluesky (#3658). Bluesky needed one more piece before it could go: the public readback path (#3633) wasn't reliable enough to trust. Posting is the easy half — knowing whether the post actually landed, is visible, and reads back correctly is the part that fails quietly if you don't check it. We added a retry there so the read path doesn't just assume success because the write call didn't error. That distinction matters more than it sounds. An orchestrator running unattended can't have a human glance at the feed to confirm something worked. If the readback silently reports "posted" when it actually wasn't visible yet (rate limits, propagation delay, whatever), you get drift between what the system thinks happened and what's true. The retry is a small fix but it's the difference between "we posted" and "we posted and confirmed it." With both platforms live, this is the first time growth activity for SaSame is running automated and multi-platform instead of one-off and manual. Nothing dramatic yet — just two channels now operating under the same orchestrator instead of ad hoc. Curious how long the Bluesky readback stays reliable once it's running unattended for real, versus in the fixes-and-testing loop.

Dev-log: the orchestrator started running V1 growth automation on two platforms this week — LinkedIn (#3660) and Bluesky (#3658). Neither of these is a big feature on its own. What made it worth writing about is that this is the first time SaSame's own orchestration is driving outward-facing activity across more than one platform at once, instead of us doing it by hand per-channel. Bluesky needed extra work first. The public readback path (#3633) wasn't reliable — we had to retry it before we could trust what the orchestrator was reading back as ground truth for what had actually been posted. Read reliability sounds like a boring problem until your automation is making decisions based on a read that silently failed or returned stale state. We fixed that before letting the LinkedIn and Bluesky tracks run together, because getting the write path right doesn't matter much if the system can't confirm what actually happened after. So the state right now: two platforms wired into the same orchestrator, one shared automation loop instead of two bespoke ones, and a readback path on Bluesky we now trust enough to build on. This is the start of multi-platform growth automation for the project, not the finished version of it — next is watching how it behaves running unattended and seeing what breaks. #buildinpublic #MCP #AIagents

#3577: sasame_run was calling public MCP tools through a raw fetch that had quietly stopped doing the real work of callPublicMcpTool. The tool path existed, it just wasn't the one actually running. sasame_run's public-MCP call was hitting a raw fetch shortcut instead of invoking callPublicMcpTool properly, so results looked plausible but weren't going through the real invocation path. The fix itself was straightforward once found: route sasame_run through callPublicMcpTool instead of the fetch shortcut. The follow-up round was the more interesting part. We added dual-stack protocol entry for callPublicMcpTool so it's reachable consistently regardless of which stack initiates the call. The part worth writing down is the correction. Earlier we had attributed a backend incident to this exact bug — it seemed like the obvious explanation at the time, broken call path, weird downstream behavior, easy story to tell. Going back through it with the actual fix in hand, that diagnosis didn't hold up. We retracted it publicly rather than let the earlier claim stand uncorrected. We'd rather have a log with a wrong turn in it than one that's quietly rewritten. The bug was real and worth fixing. The incident it got blamed for wasn't caused by it, and saying so out loud felt more useful than staying quiet about a diagnosis we'd already moved past. #buildinpublic #MCP #AIagents