I Cloned Myself Into Slack So I Could Go Skiing

In March I wanted to go skiing. Two weeks over Easter, patchy signal on the mountain, and no other engineer who could answer for me while I was gone. I'm the CTO; when I'm out, the team is blocked on me.

Small startups call this the bus factor. In my case the bus was a holiday.

So instead of shortening the trip, I built a stand-in: a version of me that lived in Slack, that the team could @mention exactly like they'd ping me ("staging deploy's failing, can you look?") and that would do the actual work: read the logs, find the bug, open a PR, and report back in the thread. I called it Citio.

It held the fort for two weeks. It worked well enough that I kept building it after the snow melted.

Claude Tag validated the idea (for enterprises)

Last month Anthropic launched Claude Tag: Claude as a taggable Slack teammate, with persistent memory, watching your channels and chiming in proactively. A month on, it is clearly good, and clearly built for a different customer. It requires a Team or Enterprise plan, runs only on Anthropic's cloud, and is Claude-only.

That leaves a lot of people out: solo founders, two-person startups, any team where the CTO is also the infrastructure. It also leaves two practical concerns that keep coming up even from people who can buy it: the token bill (an always-on teammate that monitors channels burns metered tokens) and the noise (an agent that decides for itself when to interrupt).

Citio is aimed at that gap:

• Self-hosted in your own infrastructure: this version deploys to AWS Fargate with one command, on Spot pricing by default. Other hosts are on the roadmap.
• Runs on the flat Claude Max/Pro or ChatGPT Go/Plus/Pro subscription you already pay for. No token meter, usage is capped by your plan's quota, so there is no bill to run up.
• Only moves when you @mention it.
• Provider-agnostic: Claude Code or OpenAI Codex.
• MIT licensed.

Here is the whole loop in 25 seconds: a bug report in Slack, the agent reading CloudWatch logs and running tests (time-lapsed), and a pull request at the end:

The model never holds the keys

The design decision I care about most is where the credentials live. Citio is, primarily, an MCP server; the provider CLI is the client. The agent does not get a raw shell and a pile of environment variables. It gets a fixed set of named tools: investigate_codebase, read_file, create_pr, check_ci_status, run_command (allowlisted, shell metacharacters rejected), query_logs. That tool layer is the boundary. The GitHub token, the AWS role, and the Slack secret live in the tools. The model only ever sees the result.

That boundary is the main argument for self-hosting: your code and your secrets stay in your account, behind tools you can read the source of, instead of being handed to a vendor's cloud on trust.

The unit of delegation is a pull request

The second design decision: the agent's output is a pull request, never a push. A PR is reviewable, revertable, and CI-gated. It is the one artifact engineering teams already have a trust process for. Delegating through PRs means you build trust with the agent the same way you would with a new hire: small changes, reviewed, until the reviews get boring.

The workspace rules are yours to set. Mine are simple: always open PRs, never push to main; check logs before touching code. This is what comes back:

Getting all of this to deploy with one command took longer than building the agent itself. That taught me what "self-hosted" actually costs, and it is why the installer exists: npx @lawrencehui/citio walks you through Slack, GitHub, and AWS, and deploys the whole thing in about ten minutes.

The economics

Claude Tag assumes a company with procurement. Citio assumes a person who already pays for a coding agent. The point most people miss: that subscription is the cheapest compute you own, and it sits idle most of the day. You pay $20–200/month for an agent that works when you type. Putting it in Slack means it also works when your team types.

• Cost: the agent runs on your existing flat subscription, so usage draws on your plan's quota and nothing else. The worst case is hitting a rate limit and waiting; it is never a surprise API bill. The infrastructure is ~$11/month on Fargate Spot, or citio pause scales it to zero between uses. No per-seat upgrade.
• Control: your AWS account, your IAM, your repos. You decide who can call it and what rules it follows.
• Privacy: source and secrets never leave your infrastructure.
• No lock-in: Claude Code or Codex, switchable per deploy.

Try it, and tell me what breaks

npx @lawrencehui/citio   # guided installer → deploys to your AWS in ~10 min

It's MIT, pre-1.0, on GitHub at github.com/lawrencehui/Citio. The demo is reproducible: citio-demo is the checkout service from the gif, with the bugs deliberately planted and a script that seeds the CloudWatch logs. Point your own deploy at it and ask the same question.

Known limitations, stated plainly: it is not a hardened sandbox (the provider CLI keeps its native shell inside the container; the MCP layer is a real boundary for credentials, not policy-grade isolation); it is AWS-only for now; and it runs one task per container by design.

Feedback I want, in order:

1. What broke during install, and on which step.
2. What you would need before pointing it at a real production repo.
3. Any hole you can find in the MCP-as-credential-boundary argument. This is the one I most want tested.

Open an issue for any of the three. If it works for you, a star helps other people find it.

Claude Tag is the managed version of this idea, and for many teams that is the right choice. Citio is for the rest of us: the same capability, on your own subscription, in your own account, with the keys somewhere you can see them. It started as a way to take a holiday. It turned out to be the version I actually want to run.

If you want Citio installed and running in your own cloud account rather than doing it yourself, that is on my work page.