AI Chief-of-Staff Agent
A design exercise in building accountability into operational alerting
Problem Statement
In fast-moving teams, critical issues get buried across Slack, email, and spreadsheets. Most alerting tools notify once and move on — there's no ownership tracking, no forced acknowledgment, and no escalation path if something is ignored. That gap, between notifying a problem and ensuring it gets resolved, is what I wanted to design around.
What I Designed
I designed an autonomous layer that monitors Slack in real time, classifies urgency using an LLM, and tracks every issue through an explicit state machine: Pending → Acknowledged → Escalated; So nothing critical can silently fall through. The intent was to force accountability into the workflow itself, rather than relying on someone remembering to follow up.
The system:
- Monitors Slack and routes flagged messages into a structured tracking layer.
- Uses Google Gemini to classify urgency from context and tone, not just keywords.
- Requires a human-in-the-loop acknowledgment before an issue is marked resolved.
- Auto-escalates to a secondary channel if an issue stays unacknowledged past a target SLA window.
How It Works (System Design)
I built this on a decoupled architecture, by design, so that a failure in one communication channel (say, Telegram going down) wouldn't take down the rest of the recovery process.
Scenario 1: Intelligent Filtering (Entry Point)
Watches Slack in real time and uses Gemini to assess context and sentiment rather than matching keywords. Messages classified as critical get a unique ID and are logged into the state machine.
Scenario 2: Human-in-the-Loop Acknowledgment (Accountability Layer)
Alerts are dispatched to Telegram. The system waits for a structured reply (Acknowledge [ID]) and, on receipt, updates the record's state from Pending to Acknowledged. This step exists specifically to prevent issues from being silently marked done without a human confirming it.
Scenario 3: Automatic Escalation (Fail-Safe)
A scheduled background process audits the database on an interval, looking for "ghost incidents", records still Pending past their target SLA. These bypass standard chat entirely and trigger a high priority alert through a separate channel (Pushbullet), so an ignored issue can't just stay quietly unresolved.
Key Design Decisions
- Used a strict-string ID scheme instead of relying on default numeric IDs, to prevent ID-matching errors (e.g. decimal drift) when syncing between different APIs, a small but important reliability choice.
- Separated escalation logic from ingestion logic, running them as independent scheduled processes so an ingestion failure wouldn't silently disable the safety-net escalation path.
- Chose Gemini for classification over keyword rules, since natural-language Slack messages don't map cleanly to fixed triggers, this was a deliberate tradeoff of added complexity for better real-world accuracy.
- Designed for low Make.com operation cost, consolidating logic into fewer modules per scenario, an operational constraint I treated as a real design input, not an afterthought.
What This Demonstrates
- Modeling an ambiguous operational problem ("things get missed") as an explicit state machine with defined transitions.
- Designing for failure independently, isolating channels so one outage doesn't cascade.
- Thinking about accountability and escalation as product requirements, not just notification plumbing.