We don't just talk about automation -- we run on it. This is the bridge that turns a message we
send from a phone into a finished task and a reply, unattended, without doing anything it
should not. We build what we use.
The problem
A task you think of on your phone -- "update this," "check that," "publish the thing" -- sits in
your head until you are back at a computer. The instruction and the execution are separated by a
person and a context switch. Multiply that across a day and the backlog itself becomes the
bottleneck.
The naive fix is to wire a chat bot straight to a shell or an agent. The reason most people do
not is obvious: an unattended runner that will execute whatever you text it is a liability. The
hard part is not running the work -- it is the safety envelope around it.
The workflow
[ Chat message ] -> [ Denylist filter ] -> [ Safe execute ] -> [ Reply with result ]
task request block unsafe first capped, audited back to chat
1. Message in, work out
A task message sent to a chat bot is picked up, executed by a headless agent runner, and the
result is replied back into the same chat. The round trip closes without a person in the middle.
2. Denylist-first safety
Every incoming request is screened against a denylist before execution. Payment, pricing,
legal, and deletion actions are refused outright. The agent runs with a constrained,
safety-scoped prompt that is allowed to do safe work only. The dangerous categories are blocked
structurally, not trusted to good behavior.
3. Blast-radius limits
A per-run execution cap of one bounds how much any single trigger can do. A kill switch -- a
sentinel file that halts the bridge the instant it appears -- gives an immediate stop. An
append-only audit log records everything attempted. Duplicate requests are de-duplicated so a
retry does not double-execute.
4. Unattended on a schedule
The bridge polls every 15 minutes, so messages are picked up without anyone watching the queue.
It runs whether or not you are looking.
5. Hardened from a real failure
An early version broke because the runner binary was not on the scheduler's PATH (a WinError 2),
fixed by switching to absolute paths. That is the kind of environment-specific bug that only
shows up when something runs unattended on a real machine -- never in a hand-run demo.
The result
- A phone message becomes a completed task and a reply -- no context switch, no waiting to be at a desk.
- Unattended on a 15-minute cycle, with a denylist, a per-run cap, a kill switch, and a full audit trail, so it is safe to leave running.
- Unsafe categories -- payments, pricing, legal, deletion -- are structurally blocked, not trusted to good behavior.
Stack
A chat-bot inbox poller - a denylist pre-filter - a headless agent runner with a constrained
safety prompt - a per-run cap plus a file-based kill switch plus a JSONL audit log - a task
scheduler on a 15-minute interval.
The takeaway
This is the pattern behind "text our system and it does the work." The valuable part is not that
an agent can run -- it is the safety envelope: a denylist that refuses the dangerous categories,
a cap that bounds the damage, a kill switch, and an audit log. That envelope is what turns
message-driven automation into something you can actually deploy in a business, instead of
something that only survives a demo.
We build automation systems like this for businesses drowning in repetitive busywork --
content, reporting, customer replies, lead follow-up. If a daily task is eating your team's
hours, that's usually a one-time build away from running itself.
Top comments (0)