AI Systems & Infrastructure
AI Chief of Staff for an Agent Fleet
We run a lot of work on autopilot. Ad reviews, support cases, weekly client reports, outreach, research. Two dozen agents handle it on a schedule, and the moment there was more than a handful of them the real problem stopped being "can an agent do this" and became "how would I ever know if one quietly stopped". So we built something to sit above them. You text it the way you would text an ops manager, and it answers from what the agents actually produced rather than what they claimed.
Stack
Concepts
How it works
The whole flow, traced from your first tap.
- 01
Telegram
Ask in plain English
You text a question the way you would ask a person: what happened to the Walmart cases, why is outreach quiet, is anything broken this morning. There is nothing to learn and no syntax to get wrong.
Plain chatNo commands to memorizeAnswers in a few lines - 02
Chief of staff
The facts are gathered before anything thinks
Before the model sees the question, a plain script collects the current state: what ran, what failed, what is still going, who owns what, and what is already open. No agent is asked how it is doing, because that is the one answer you cannot check.
Deterministic snapshotOwnership mapRecent run history - 03
Chief of staff
The claim gets checked against the work itself
An alert is treated as a claim about the system rather than the system. The chief opens the file the job actually wrote and compares. Sometimes the answer is that the alert is wrong, and that is the more valuable finding, because a detector that lies will lie again tomorrow.
Reads the artifactQuotes the exact recordSays what it could not verify - 04
Telegram
You get an answer and a button
The reply is short enough to read at a glance and ends in a decision rather than a chore. Approving runs the exact action that was stored with the proposal, so the message you tapped cannot change what happens.
ApproveDenyIgnore - 05
Agent fleet
The work runs where it belongs
Each agent owns a real job: pulling ad reports, watching support cases before they auto-close, drafting and pacing outreach, keeping the books of what ran. The chief routes to the one that owns the problem instead of improvising an answer itself.
Two dozen specialist agentsShared skillsScheduled jobs - 06
Run history + Watchdog
Everything lands on the record
Success, failure, and death-in-the-middle are all written down, so a job that stops has to explain itself. The watchdog looks for silence as hard as it looks for errors, and when it finds either, someone hears about it that day.
Every run loggedStall sweepPages a human
The problem
An automated job that works is invisible, and an automated job that dies is also invisible. That is the whole trap. Success and silence look identical from the outside, so you find out something has been broken for four days when a client asks about a report nobody sent. Adding more automation makes it worse, because every new job is one more thing that can stop without telling anyone.
What we built
A chief of staff that lives in a chat thread. It knows every agent, what each one owns, and when each is supposed to run. Ask it what happened to the support cases, or why the ad refresh has gone quiet, and it goes and looks. It answers in a few lines, because it gets read on a phone while you are walking somewhere.
Alerts are treated as claims, not facts
This is the part that matters. One evening three separate alarms came in and every one of them was wrong about its own cause. One blamed the wrong job. One said no record existed when the record was right there. One reported a signed-out browser session that was live and answering. All three came from careful code that had simply never been asked to prove itself. So the first question is always whether the alert is true. The chief opens the file the job wrote, reads the row in the log, and says plainly which parts it checked and which it could not. An unverified claim reported as unverified is useful. An unverified claim reported as fact is the thing this whole role exists to stop.
It proposes, you decide
The chief cannot change anything. It has no shell, it cannot send mail or edit code, and it cannot start another agent. What it can do is propose one specific repair and put it in front of you as a button: Approve, Deny, or Ignore. Nothing runs until you tap, and what runs is the action stored when the proposal was written, never text from the message approving it. That split is deliberate. The part that reads unfamiliar files and untrusted content is not the part holding the pen.
Nothing is allowed to fail quietly
Every run of every agent is recorded, whether it succeeded, failed, or died halfway. A separate watchdog sweeps for work that has gone silent and pages a human, and it looks for the shapes of failure rather than only the marker of success, because a watcher that matches success alone stays quiet right through a crash. Findings are never left to sit. Each one ends the same day as a fix, a specific proposal you can approve, or a named blocker that says what is missing and who has to supply it. There is no fourth option and no "keep an eye on it". A finding on its fourth day gets reported louder than a new one, not quieter, because the way this kind of system fails is by becoming a calm daily summary of a machine that is falling apart.
Outcome
Two dozen agents and seventy-odd background jobs run the recurring work, and one place answers for all of it. Roughly twenty-five hundred runs are on the record so far, each one accounted for. The daily question went from "is everything fine" to a chat you can actually get a straight answer out of.
Interested in something similar?
Tell us what you need and we'll figure out how to ship it.