TorkBot

I started TorkBot after using a continuous personal agent and getting completely nerd sniped. It felt different from opening a chatbot for a task, and I wanted to know which parts of that feeling were real architecture.

Most of the work is about continuity: one agent stays present across conversations while slower work carries on elsewhere. That question has pulled me into queues, sandboxes, and memory. It has also produced a few architectures that looked much better before I tried them.

One agent from the outside

Slack ───┐                              ┌─ research lane
GitHub ──┼─ foreground conversation ────┼─ coding lane
Web ─────┘                              └─ sandbox lane

Messages from each surface enter the same foreground conversation. A lane can go deep without filling that conversation with every intermediate tool call, then return a result through the same channel the foreground uses for everything else.

The split is internal. From the outside, it should still feel like one agent that remembers what it was doing.

Lanes return references, not working transcripts

A coding lane can leave a patch, report, or dataset in the shared filesystem and send the foreground conversation its path. The foreground gets the result and enough context to explain it, without inheriting every failed command and intermediate thought.

That keeps the continuous conversation legible while the underlying work can still be messy.