cd /news/ai-agents/how-we-cut-ten-alerting-agents-down-… · home › topics › ai-agents › article
[ARTICLE · art-138774] src=kznconsulting.com ↗ pub= topic=ai-agents verified=true sentiment=· neutral

How we cut ten alerting agents down to one

A team consolidated ten specialized AI alerting agents into one general agent plus scheduled jobs, after the ten agents' independent urgency rules left a single person sorting every alert. The new system routes routine findings to a daily briefing queue and reserves human interruptions for urgent deadlines, currently blocked work, same-day decisions and urgent client support requests, with repeat alerts on the same work item waiting six hours by default. The team's stated lesson is that noticing a finding and deciding to interrupt a person are separate jobs that should be assigned to separate parts of the system.

by read4 min views18 publishedSep 8, 2026
How we cut ten alerting agents down to one
Image: Kznconsulting (auto-discovered)

We had ten AI agents, and each one checked one part of the business. Most of them could also send an alert to a person on their own. Taken one at a time, the alerts were useful. Together, they left one person to sort through all of them. Giving each agent its own rule for what counts as urgent made that sorting harder.

We replaced them with one general agent and a set of scheduled jobs. The jobs still check their own parts of the business. Routine findings go into a queue for the daily briefing, and one set of written rules decides what is urgent enough to interrupt someone.

The lesson for anyone designing agents: noticing something and deciding to interrupt a person are two separate jobs. Give them to separate parts of the system.

Give one agent the decision about what is urgent #

Our general agent holds routine findings for the briefing. It interrupts a person only for urgent deadlines, work that is blocked now, decisions needed the same day and urgent client support requests.

If you are designing a similar system, ask which part of it can weigh a finding against everything else happening that day. A specialist job can notice that a renewal is coming up. Deciding whether that renewal is worth an interruption needs a view of all the other work competing for attention. Write these rules before you add another way to send notifications. List the conditions that justify an interruption, and give routine findings a place to wait.

Check each finding again before the briefing #

Our briefing instructions tell the agent to look up each record again before it repeats a finding. They also tell it to drop meeting acceptances and out-of-office replies that have expired, and to group receipts together.

So the briefing is a summary of where things stand now, built from the records themselves. It is more useful than a list of messages in the order they arrived.

When you design your own queue, decide what makes each kind of finding out of date, and make the briefing check for it. One good test: change the underlying record after a finding is queued and before the briefing runs. The briefing should report the current record, and drop the old text.

Our system cannot send an alert to a phone unless the alert is attached to a work item. The alert links to that record, so the person who gets it goes straight to the work it is about.

A repeat alert about the same work item waits six hours by default. The agent can override the wait when the situation has changed in a material way.

Some urgent events follow fixed rules and do not wait for the general agent, including client requests to schedule a meeting and failed jobs. These alerts still attach to a work item in the same way.

If you run your own agents, settle these questions in writing: what record must exist before an alert goes out, how often an alert can repeat, and what kind of change allows an override. You can inspect and test these rules alongside the model's instructions.

List every way an agent can interrupt a person #

The specialist jobs are still part of our system. The general agent gives them one place to send routine findings and one rule for what is urgent.

If your team runs several AI workflows, start by listing every path that can interrupt a person. For each one, record:

  • Who decides whether it is urgent.
  • What evidence supports the finding.
  • When that evidence must be checked again.
  • What makes the finding expire.
  • Which work record the alert opens.
  • What stops repeat alerts about the same work.

This list is a good starting point for a conversation about AI implementation. It connects each agent's instructions to how people receive and act on what the agents produce.

For the same approach applied to deadlines, read How to automate follow-up when deadlines slip. For everything the agent does today, and the rules it follows, see How we run Kaizen on AI.

── more in #ai-agents 4 stories · sorted by recency
── more on @kaiz 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/how-we-cut-ten-alert…] indexed:0 read:4min 2026-09-08 · —