Agent Daily Operations: RAM Corpses, Channel Rules, and Four Doors Into One Brain

Between September 18 and 22, my cyberdeck gained an agent community, compiled a Rust tool, and nearly buried itself under a dead update process holding 641 MB of RAM. This is not a milestone post – it's the operations diary from the week between the headlines, documented while it happened. Three themes: the four doors into one agent brain, a RAM corpse, and the community rules nobody writes down until the channels get noisy.

My agent is now reachable through four interfaces: the terminal on the phone, Telegram, Buzz, and a desktop app on my MacBook connecting via a remote gateway. All four lead into the same brain – same sessions, same skills, same memory. I can start something in the terminal in the morning and continue it in the desktop app at noon; the context travels with me.

What surprised me: the desktop app adds almost no load to the phone. The server process needs 199 MB of RAM and nearly zero CPU while idle, because the thinking happens in the cloud and the phone only orchestrates. My MacBook is the screen, the phone is the server, the cloud is the brain. Three devices, one division of labor, zero additional cost – each device doing the thing it does cheapest.

The week's least glamorous find: a half-finished update had left behind an npm install process holding 641 MB of memory, running silently for a day. Together with its child processes it hoarded over a gigabyte while the system kept working and every health check stayed green. The agent found it, I approved the cleanup, and afterwards 1.4 GB were free – double what we had before, with zero restarts. The lesson is banal and important: even a hardened system collects garbage when processes are aborted. A watchdog guards the agent, not every installed tool.

The Buzz week produced working rules the hard way. In a channel with three agents and one human, timing collisions are normal: two agents test-ping at the same moment, confirmations cross in flight, and the human sees overlap and noise. What fixed it was a protocol everyone agreed on: flat main chat, no sub-threads, @-mentions as triggers, direct messages for private matters. Boring rules, readable channels.

The second lesson was cost awareness. Every message to an agent triggers a full reasoning run, and a run that wanders for fifty iterations before answering burns minutes of model time while the channel sits silent. After trimming the configuration – no progress spam, no forced threads, direct replies – a message now costs seconds instead of minutes. Same agent, same brain, a tenth of the latency. The configuration you do once and never touch again is what makes an agent usable instead of annoying.

Four takeaways: agents need office rules; RAM discipline on Android includes cleaning up your own aborted tooling, not just watching for out-of-memory kills; ergonomics is a milestone, and working from a proper keyboard made my inputs richer and the collaboration better; and the cheap phone keeps being the right host – it orchestrates, the cloud thinks, and the laptop is just a comfortable window into the same brain.

The detail that made the cleanup satisfying: the agent didn't find the dead process because I asked for it specifically – it found it while checking overall memory usage, and flagged the outlier on its own. The combination of a human noticing slow responses and an agent reading the process list caught in two minutes what a watchdog had carried for a day. Monitoring finds failures; a curious agent finds causes.

The allowlist failure taught me the same lesson from the other side: my agent ignored three of my messages because my own configuration had it running in private mode, and I was the user nobody had authorized. The system was working perfectly – against me. One config line, and I was on my own list. It is a specific kind of humbling when your security setup locks out exactly the person it was built for, and the fix was written by the machine that had been silently ignoring you.

The channel rules took one iteration to stick. First there was noise – three agents and one human writing over each other, replies landing in threads nobody read, test pings colliding. The fix was not more moderation but a one-paragraph agreement everyone confirmed in the channel itself: flat main chat, @-mentions as triggers, DMs for private matters. After that, the noise dropped to zero and the collisions became visible as what they are – parallel work, not chaos.

The cost lesson ties back to the RAM story. Both problems had the same shape: something running longer or larger than anyone noticed, because the system kept working anyway. A dead install process hoarding 641 MB, an agent run wandering through fifty iterations before answering – neither is a crash, and neither trips a watchdog. They are efficiency leaks, and the only tool that finds them is a routine look at the operational numbers. The cheap phone survived all of it; the lesson is to check on it before it can't.

One more operations pattern worth copying: the cleanup happened without a restart because each dead process was killed individually, verified by re-reading the memory numbers, and the gateway never went down. The temptation in the moment is to restart everything and start clean – but a restart loses the WebSocket connections, drops in-flight cron runs, and costs a cold-start window. Killing two zombie processes was the smaller, safer operation. Minimal intervention is a habit worth training: the less you restart, the more your uptime means.

What I want to check next month: whether the desktop app's server process accumulates its own state over weeks – connections, caches, orphaned handles – the way the update process did. The watchdog covers the gateway, and now I know to look at the serve process too. Cheap hardware doesn't mean sloppy operations; it means the operations have to be deliberate, because the hardware won't forgive what the software forgets.

A quick note on the numbers in this post, because they are the kind readers trust and writers get wrong. The 641 MB figure is the RSS of one dead npm process at the moment of cleanup; the 1.4 GB free is the post-cleanup reading of MemAvailable, not a benchmark; and the two-minute interval is measured from my question in the desktop app to the verified state after the kills. Small numbers, exact context. An operations post lives or dies by whether its numbers survive the second reading.

The meta-lesson of the fortnight is that the boring layer is where trust is built. The community saw the agent arrive; they didn't see the allowlist mistake that made him deaf for a day. The blog readers will see the milestone numbers; they don't see the 1.4 GB of recovered memory. But the agent that answers reliably next month will do so because someone cleaned the corpses and wrote down the channel rules. Operations is the blog you write in logs, not in markdown – and once in a while, like today, the logs become the post.