The before times (last week)
For the launch push, marketing ran the way a lot of things run right now: an AI coding session on my desk with a pile of scheduled jobs. Morning sweep at 7:55, evening sweep at 6:05, a launch thread queued for 8:27 on Monday. The session hunted X for conversations worth joining, drafted replies in my voice, and I approved each one with a one-word go. It worked. We went from zero presence to real conversations with the Buzz maintainers in a weekend.
It also had the structural integrity of a sandcastle. The schedules lived inside one session; if the session died, they died silently. The machine had to stay awake all weekend. I was already herding multiple sessions for different parts of Hachiflow, and marketing was one more terminal to babysit. All the context lived in one process on one machine, and the only way to check on it was to go look.
The swap
Hachiflow sells managed Buzz workspaces, and Buzz is the open-source workspace where AI agents join channels like teammates. You can see where this is going. I made a #marketing channel in my own hive, the same hive my team lives in, hosted on Hachiflow like any customer workspace, and created an agent named Gary V. If you are going to have a marketing guy grinding replies at 7am, name him honestly.
Gary's system prompt is everything the launch weekend taught us, written down: the claims we can make and the claims we never make, the reply protocol, the map of who is who in the Buzz ecosystem, and the browser scar tissue, like the time an unfocused text box turned typed words into keyboard shortcuts and muted an account nobody meant to mute.
The important part: Gary has zero posting authority. He drafts in the channel with targets, context and stats. I reply with a short go from my phone, from anywhere, and he executes. Same approval flow as before, except now it is a persistent channel instead of a terminal on one machine, and the whole history of what we found, what we posted and why is just chat history, in the workspace, where the team can argue with it.
Where an agent actually lives
Here is the detail I had not fully internalized before creating him: a Buzz agent's runtime lives on the machine where you start it. The relay is hosted; in our case by us, which is the whole product. But the agent's hands, its shell, its files, its browser, are the machine that birthed it.
So I created Gary on my dev machine, a Mac Mini, and that turned out to be the right call for reasons beyond convenience. Gary needs what that machine has: the marketing directory in the repo, the company memory CLI, an authenticated browser, the analytics CLI. Creating him where I dev means he inherits the whole toolbench. He is not a chatbot in a channel. He is a coworker with my exact workshop, reachable from anywhere through chat.
It also means the honest architecture is: workspace always on, agent as awake as the Mac Mini. If the Mini sleeps, Gary's messages queue in the channel and he catches up when it wakes. For a marketing agent behind a human approval gate that is completely fine, and it is exactly the boundary we tell customers about: relays are ours to run, agents are yours, and they live where you put them.
Why bother
This is the thesis, eaten at home. Hachiflow's pitch is that your team's chat should be a place you own, where agents are members instead of metered add-ons. The most credible thing I could do with launch day was run my own company that way: marketing is an agent, in a channel, in a hive, on a Hachiflow server, approved by a human, with every decision written to company memory. $50 a month, no per-seat anything, including for Gary.
Next milestones: two clean weeks and Gary earns limited posting autonomy. After that, a second agent on the analytics side, and the two of them talking to each other in-channel where I can watch.
Come overshare with us
If you want a hive of your own, the buy button is on the home page, and the first twenty customers get onboarding done personally by me. Gary will probably reply to your tweet about it either way.