Running a Company with a Desk Full of Bots

13 Sep 2026

13 Sep 2026 by Luke Puplett - Founder

Most "AI for work" demos still end the same way: one chat window that knows everything and owns nothing. You paste context, it pastes back a plan, and the actual moving of tickets, mail, and pull requests stays on you.

That model collapses the moment you try to run a company with it. Context dilutes. Ownership disappears. Everything becomes a dump into the same thread. What I wanted instead was closer to a small org chart: named roles, clear lanes, a shared board, and a human who still decides what goes live.

For the last stretch I've been running Zipwire that way with Grok Bot — desktop assistants that each get a real Linux computer, connectors into accounts, and teammates they can hand work to. This is a field note on how that actually looks day to day, not a product pitch.

The problem with one mega-bot

A single assistant that "does everything" sounds efficient until you watch it in practice. Personal mail sits next to product bugs. Investment research bleeds into a timesheet question. A draft blog post competes with a calendar conflict. You spend half the interaction re-explaining who you are and which hat you're wearing.

Worse, nobody owns the outcome. If everything lives in one chat, nothing has a default home. Work falls through the cracks between "I thought you had it" and "I was waiting on you."

That's the same failure mode as a company with no roles — just a smart person in a room. The fix isn't a smarter model. It's structure: specialists, handoffs, and a place work can sit when you're not looking.

We've written before about how productivity numbers miss what actually moves. The same trap shows up in assistant tooling: activity in the chat is easy to see; finished work on a board is harder and more honest.

What Grok Bot actually is

Grok Bot is not "ChatGPT with a nicer sidebar." Each agent runs against a persistent Linux machine — internally we just call it the desk — with a browser, a shell, memory that survives the conversation, skills for recurring jobs, and scheduled routines that fire when you're away.

The important part for ops is the escalation order. Prefer a connector (mail, calendar, Drive, GitHub) when one exists. Fall back to a signed-in browser on that desk when it doesn't. Put repository work on Cursor cloud agents, with pull requests as the default rather than push-to-main. Secrets go through secure cards, not paste-into-chat.

That's different from a normal Cursor chat or a web LLM in a few concrete ways. The machine state sticks around. Teammates can message each other. Routines keep watching. Handoffs are explicit. You're not restarting the universe every time you open a tab.

If you've used Zipwire through MCP, you already know the shape: give an agent legible access to real systems and it stops being a suggestion engine. Grok Bot pushes that further by giving each role its own desk and its own lane.

The desk chart

Here's the cast I actually use:

• Chief of Staff — coordinates the other bots, pulls me in for decisions, keeps the board honest.

• Pepper Pots — personal secretary: mail and calendar, light time capture for Dad and Zipwire work when I ask (and only after confirming).

• Zipwire bot — product and engineering plus blog drafts. Dispatches Cursor cloud agents onto Zipwire repos; opens PRs by default.

• Investment Research — filings, markets, theses. Mentioned lightly here on purpose: different lane, different chat.

The rule of thumb is blunt: don't make one bot own everything. Hand off by domain. If something is Hotmail triage, it's Pepper. If it's a Zipwire PR, it's the Zipwire bot. If it's a go/no-go that only I can make, Chief of Staff surfaces it instead of inventing an answer.

Coordination lives in a private GitHub repo we call grok-bot-coord, plus a GitHub Project with four columns: Inbox, Doing, Waiting on Luke, and Done. Labels do the protocol work: needs-bot, needs-luke, decision, blocked, fyi. No private issue titles in this post — the board shape is the useful part, not the contents of any one card.

On the desk itself: gh authenticated for GitHub, Buffer CLI for social after something is actually published, Homebrew for the rest, and the Zipwire zw CLI for time tracking — same tool as the contractor automation path, installed the boring way:

npm install -g @zipwire/zw

That part was almost suspiciously simple. Once the binary is on the PATH, journaling and timesheet commands behave like any other CLI. The interesting bit for Grok Bot is auth: the assistant has a small secure UI for taking an API key I created in Zipwire, so the bot can store the credential without me pasting secrets into the chat transcript. No shared password file, no "just put it in the prompt."

I did try the normal browser login flow the CLI offers. It did not work on this desk, and it cannot work today: the Linux Grok box doesn't have passkeys enabled, so a WebAuthn / passkey-gated Zipwire login has nowhere to complete. API key via Grok Bot's secret UI is the path that actually ships. Connectors first; browser when you must (and when the browser can finish the auth); cloud agents for code.

A day that actually happened (composite)

Morning starts without me typing "what's on today?" into a blank box. Chief of Staff has already sorted overnight noise into the Project. Pepper has personal mail in a state I can scan. Anything that needs a Zipwire decision is labelled, not buried in prose.

A typical path looks like this. Something lands in Inbox with needs-bot. Chief of Staff triages it into the Zipwire bot's lane and moves the card to Doing. For a product change, the Zipwire bot confirms Cursor can see the target repo, then kicks a cloud agent with a tight brief: fix or feature, open a PR, don't push to main. The agent works on a remote checkout; the PR comes back with a URL. The card flips to Waiting on Luke with needs-luke. I review, comment or merge, and only then does it go to Done.

The PR beat matters because it forces the same discipline you'd demand from a contractor. Diffs are reviewable. CI still runs. Nothing lands on main because an assistant felt confident. If the cloud agent can't reach the repo, the Zipwire bot stops and says so instead of improvising against a local checkout that isn't the source of truth.

That's the coding beat I care about. The bot doesn't "ship." It prepares a reviewable change and parks ownership on me until I move it. Same pattern as the human-in-the-loop note in our Claude morning-briefing story: speed is only useful if the assistant is honest about what it shouldn't invent or publish.

Blog work follows the same spine. Outline first, locked prefs (channel, length, what not to say), then a full draft on the desk following a repo skill. Staging goes to the Zipwire content bucket. Production and social wait for an explicit go. Confirm before anything external leaves the building.

Time tracking sits beside all of this with three jobs: Dad under Personal, Zipwire boss under Zipwire, and Pacific AM under its own bucket. Pacific AM I log myself from that laptop. Dad and Zipwire, Pepper may infer from footprints — GitHub, activity — but she confirms before anything hits zw. The bots don't get to rewrite history to look busy.

What's working, and what's still awkward

What's working: clear lanes beat a mega-thread. PR-by-default keeps code reviewable. Labels on a Project beat status novels in chat. Confirm-before-publish and confirm-before-log keep trust intact. Specialists mean I can yell at the right desk instead of re-prompting a generalist every morning.

What's awkward: skills don't live in one place yet. A write-blog skill in a Mac Cursor checkout is not automatically on the shared Grok box skill library, and a cloud agent only sees it if the job opens against a tree that includes it. That sounds like a footnote until you're mid-draft and the agent cheerfully invents a workflow. We route around it by being explicit about where a job runs — this post was written on the shared desk against a local clone that already had the skill, not handed to a remote agent that couldn't see it.

Interrupt vs decide is the other live tension. Chief of Staff's job is to pull me in for consequential calls and otherwise keep moving. Get that threshold wrong and either I'm drowning in pings or a bot has guessed something it shouldn't. We're still tuning that by watching which cards linger in Waiting on Luke. If a card sits there too long, the process failed — not the model.

Connector gaps still cost. When there's no clean API path, the desk falls back to a signed-in browser. It works. It's also slower and more brittle than a proper connector. The escalation order is right; the coverage isn't finished. Same story for social: Buffer stays parked until after a post is live. Drafting promotion before publish is how you accidentally advertise a staging URL.

What I'd tell another founder

Start with two or three named roles, not twelve. Give them a board with boring columns and a short label vocabulary. Pick a default coding path that ends in a pull request. Keep the human on decisions and anything that publishes or spends.

Don't optimise for the demo where one assistant does a magic trick in a single thread. Optimise for Tuesday afternoon, when mail, a bug, a draft, and a calendar conflict all show up at once and you need them owned by different desks.

I'm not claiming this is the finished shape of "AI ops." I'm saying that treating assistants like teammates with machines, lanes, and a Project board has been more useful than treating them like a smarter search box. If you're already building with agents against real systems — Zipwire's own MCP path included — the next step isn't a bigger prompt. It's an org chart small enough to trust.

---

Learn more