> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ticket-rs.io/llms.txt
> Use this file to discover all available pages before exploring further.
# The Daemon Problem: Why Beads Is 'Basically Uninstallable Malware'
> Mario Zechner (creator of pi) calls out what happens when an issue tracker runs a background daemon. It validates everything ticket-rs was built to fix.
Henrik Albihn
Creator of ticket-rs
## Someone Else Said The Quiet Part Out Loud
At AI Engineer Europe (presented by Google DeepMind), [Mario Zechner](https://www.youtube.com/watch?v=RjfbvDXpFls) — creator of [pi](https://pi.dev), the core agent framework that powers [openclaw](https://github.com/openclaw/openclaw) — put this on screen during his talk, *Building Pi in a World of Slop*:
> "You installed Beads, completely oblivious to the fact that it's basically uninstallable malware."
That's a spicy framing. But he's not wrong about the underlying mechanic, and it's the exact failure mode ticket-rs was built to avoid.
***
## The Daemon Tax
Steve Yegge's [beads](https://github.com/steveyegge/beads) introduced a lot of good ideas — structured, terminal-native issue tracking designed for coding agents, dependency-aware triage, graph-native prioritization. I [wrote about this already](/blog/introducing-ticket-rs): beads was one of the first projects to ask the right question.
Where it gets into trouble is the runtime. beads runs a long-lived SQLite-backed daemon. That daemon:
* Persists state outside your repo, in a process you didn't ask to supervise
* Holds file locks that outlive your terminal session
* Has to be cleanly shut down or you get zombie state
* Adds IPC overhead to every single command your agent runs
For a human using the CLI once every few minutes, that cost is invisible. For a **coding agent** running `triage` and `ready` and `next` in a tight loop — dozens of tool calls per session — you pay that tax on every single hop. And when the daemon misbehaves, you're debugging a background process instead of your code.
Mario's phrasing is harsh, but the point lands: software that installs a persistent background process without making that contract obvious is software that's hard to reason about, hard to uninstall, and hard to trust inside an autonomous loop.
***
## Why ticket-rs Is Stateless By Design
ticket-rs takes the beads ideas — graph-native backlog, dependency-aware triage, CLI-first UX — and deletes the daemon.
* **No background process.** `tk` is a single \~10MB Rust binary. It starts, reads files, exits.
* **State lives in your repo.** Issues are markdown files with YAML frontmatter in `.tickets/`. `git log` is your audit trail.
* **The graph is incremental.** Analytics results (PageRank, betweenness, critical path) are cached to `.tickets/.cache/` and invalidated per-file by SHA-256 hash. Change one ticket, recompute the delta, not the world.
* **Every invocation is fresh.** No zombie locks, no "is the daemon running," no supervision burden for you or your agent.
The measurable outcome: `tk triage` completes in 14–21ms on a 500-ticket repo. A daemon-backed system pays an IPC round-trip before it even starts work. Zero daemons [turns out to be faster](/blog/fastest-ticketing-system), not just cleaner.
***
## Agents Don't Want Daemons Either
This is the deeper point, and it's what Mario is really getting at with pi.
A coding agent is a stateless function call. Context in, next step out. Everything in its world should be composable, inspectable, and cheap to call. The moment you introduce a long-running process into that loop, you've added:
1. **A supervision contract the agent can't fulfill.** It can't `systemctl status` your daemon from inside a sandbox.
2. **A hidden failure mode.** When the daemon is wedged, every tool call looks like a tool bug.
3. **A trust problem.** "What else is this thing doing on my machine?"
ticket-rs — and pi — converge on the same answer: small, fast, stateless CLI primitives that agents can call without inheriting a runtime. That's why ticket-rs ships as a [pi package](https://github.com/ticket-rs/ticket/tree/main/pi-package) out of the box — the model is the same all the way down.
***
## The Thesis, Restated
* Daemons are a liability when your primary user is an autonomous loop.
* The state you want is in your git repo, not in a SQLite file a sidecar process owns.
* The graph you want is derived from that state, incrementally, every call.
* Fast, stateless, inspectable tools compose. Long-running services don't.
Steve deserves real credit for naming the problem. ticket-rs is what the solution looks like when you delete the daemon.
60 seconds. One binary. No daemon.
Mario Zechner — Building Pi in a World of Slop