Several AI workflows can each produce useful findings while leaving one person to sort through all of them. A separate urgency rule for every workflow makes that sorting problem harder.
At KZN, we replaced thirteen separately interrupting agents with one generalist agent and specialized scheduled jobs. The jobs still observe their parts of the business. Routine findings enter a typed briefing queue, and one shared attention policy governs escalation.
That change gives us a concrete way to think about agent design: observation and interruption are separate responsibilities.
Give urgency one owner
Our generalist attention policy prefers to defer routine findings. It reserves interruption for urgent deadlines, current blockers, same-day decisions and urgent client support.
For a team designing a similar system, the useful question is who can judge a finding against the rest of the day. A specialist can identify an approaching renewal, for example. Deciding whether that renewal deserves an interruption also requires a view of competing work. That is a design example, rather than a reason to make every renewal urgent.
Write the attention policy before adding another notification path. Name the conditions that justify an interruption and give routine observations a place to wait.
Recheck what waited
Our briefing procedure instructs the agent to re-query referenced live records before repeating findings. It also instructs the agent to drop expired meeting acknowledgments and out-of-office replies, and to group receipts.
Those instructions give the briefing a different job from a chronological message feed. Its purpose is to assemble a current view from the underlying records.
When designing your own queue, define what makes each kind of finding stale. Then make the briefing check that condition. A useful test case is a finding whose underlying record changes between collection and briefing: the test can show whether the system follows the live record or repeats the earlier text.
Link the alert to the work
Our phone-alert API requires a work item. The phone payload links to that record, so an interruption has a specific place to lead.
Repeat alerts on the same work item have a default six-hour server-side cooldown. There is an explicit override for a materially changed situation.
Some urgent events use deterministic paths, including client scheduling requests and job failures. Those paths still use the work-item alert mechanism. They do not depend on the generalist making every escalation decision.
For another team, the same design questions are worth settling explicitly: what record must exist before an alert can be sent, how often can it repeat, and what change permits an override? These are rules you can inspect and test alongside the model's instructions.
Review the paths to a person
Specialized jobs and skills remain part of our architecture. One generalist attention policy gives them a shared place to bring routine findings and a common rule for escalation.
If your team has several AI workflows, start by listing every path that can interrupt a person. For each path, record:
- Who owns the escalation decision.
- Which evidence supports the finding.
- When that evidence must be checked again.
- What makes the finding expire.
- Which work record the alert opens.
- What prevents repeated alerts about the same work.
This is a practical review to bring to an AI implementation conversation. It connects individual prompts to the way people receive and act on their output.
You can find more implementation notes in Writing.