Iris Life Manager Triage and Notification Fatigue Research

Date: 2026-06-11 Type: Research Status: Recommendation: redesign Iris from “many proactive scans that message Elmar” into a “quiet command centre” with escalation tiers, digests, and one-tap/numbered actions. Sources: iris-life-manager-triage-notification-fatigue-research-2026-06-11.sources.json

Executive summary

Elmar’s current pain is not that Iris is finding too little. It is that Iris is converting discovery into more visible work for Elmar. The research pattern is clear across productivity systems, executive-assistant workflows, notification studies, and calm-technology design:

1. A good assistant is a filter and doer, not a broadcaster.
2. Most discoveries should be silently filed, resolved, drafted, or batched.
3. Only a tiny class of items deserves interruptive notification.
4. A “trusted system” depends on capture → clarify → organize → reflect → engage, not capture → message user.
5. When a user is overwhelmed, the UI should reduce response cost: fewer choices, default recommendations, and one-tap commands.

The proposed new operating model is: Iris should message Elmar only when there is a decision she cannot safely make, a same-day risk, or a high-confidence recommended action. Everything else should go to a private dashboard, Life ticket, daily digest, or silent archive.

What I found

1. GTD: the assistant must protect the “trusted system”

GTD’s five steps are capture, clarify, organize, reflect, and engage. The important implication for Iris is that raw capture is not value. Value starts when Iris clarifies what something means and decides whether it is actionable, reference, trash, delegated, waiting-for, or someday/maybe.

Applied to Iris: a cron job that surfaces ten “possible things” has stopped too early. It captured and maybe classified, but it did not sufficiently clarify, organize, or recommend engagement.

Source: Getting Things Done official overview — https://gettingthingsdone.com/what-is-gtd/

2. Notification research: batching beats constant interruption

Notification batching research found that receiving notifications in predictable batches can improve attention, well-being, and productivity compared with random intermittent notification streams. A 2023 occupational-health study also links automatic communication notifications to interruptions, strain, and performance effects.

Applied to Iris: the current multi-cron model creates many separate attention events. Even if each message is useful in isolation, the aggregate effect feels like a second inbox.

Sources: - https://communities.springernature.com/posts/batching-notifications-can-improve-attention-well-being-and-productivity - https://www.sciencedirect.com/science/article/abs/pii/S0747563219302596 - https://pmc.ncbi.nlm.nih.gov/articles/PMC10244611/

3. Calm technology: require the smallest possible amount of attention

Calm Technology principles say technology should require the smallest possible amount of attention, inform without overwhelming, and move between the periphery and centre only when needed.

Applied to Iris: Telegram should be the centre channel only for urgent or decision-ready items. The dashboard/report can be the periphery. Most scans should update the peripheral state, not speak.

Source: - https://calmtech.com/ - https://principles.design/examples/principles-of-calm-technology

4. Executive assistant practice: calendar and inbox management are proactive preparation, not forwarding

EA calendar-management guidance emphasizes making sure the executive understands the purpose of meetings, is prepared, and has time protected. EA inbox-management guidance emphasizes batching, triage, VIP rules, templates, routine delegation, and summaries.

Applied to Iris: the highest-value diary/inbox work is not “here are ten events/emails.” It is “I prepared tomorrow’s three meetings; only one needs your input” or “I drafted two replies; approve D1/D2.”

Sources: - https://theeacampus.com/blog/effective-calendar-management/ - https://basehq.com/executive-resources/best-email-management-strategies-for-busy-executives/ - https://blog.superhuman.com/executive-email-management/ - https://www.getinboxzero.com/blog/post/executive-inbox-management-guide

5. Email overload is a systems problem, not a user-discipline problem

Email-overload literature frames overload as a queueing/governance/workflow issue: unclear response expectations, unstructured requests, CC/FYI noise, and email functioning as an accidental task system.

Applied to Iris: if Iris simply creates more tasks and messages, she amplifies the system problem. She should instead enforce governance: suppress FYI, batch approvals, convert emails into tracked next actions, and recommend closure.

Source: https://www.getinboxzero.com/blog/post/how-to-reduce-email-overload-in-organizations

6. Contact management: useful reminders need relationship context and cadence

Personal CRM products focus on remembering context, last interaction, and suggested follow-ups. The weak version is “contact reminders”; the strong version is “relationship memory with a recommended next touch.”

Applied to Iris: contact management should not become another stream of “you haven’t contacted X.” It should appear only when context makes it useful: before meetings, after meaningful interactions, or when a relationship has an explicit pending follow-up.

Source: https://getdex.com/blog/personal-crm-for-networking/

Current Iris setup observation

I checked the current Iris cron list. There are 13 active jobs. Several deliver to Telegram/origin, including:

• 9bcac23a94b2 — missed-communications guardian, 4x per weekday
• fb5adefb3a65 — daytime Life delta surfacing, hourly business-day scan
• 8e3f4122244b — diary hygiene and meeting intelligence, twice daily
• 385516de148c — daily email cleanup recommendations
• d974fe831191 — twice-daily noisy email focus sweep
• f20303462abe — Life admin morning/evening digest
• abea0474eb08 — Control Room watcher, every 15 minutes to a Telegram thread

This explains the subjective overload: Iris is architected as multiple proactive emitters. Even with “high-signal” prompts, the system has many chances per day to create a message.

Design diagnosis

The current system is closer to:

“Many scouts report findings to Elmar.”

The target should be:

“Many scouts update Iris’s private operating picture; Iris speaks only when she has a small, confident recommendation or needs approval.”

Recommended new operating model

1. Three-tier delivery policy

Tier 0 — Silent work

No Telegram message. Iris updates tickets, notes, contact context, dashboard state, or drafts.

Examples: - FYI emails - newsletters/noise candidates - already-resolved threads - low-confidence possible actions - contact context updates - future meeting prep that does not need Elmar

Tier 1 — Digest only

Appears in one daily or twice-daily digest, never as separate alerts.

Examples: - “I found 5 low-risk cleanup candidates” - “3 meetings now have prep packs” - “2 old tickets remain waiting for other people” - “1 relationship follow-up suggestion for later this week”

Tier 2 — Interruptive Telegram alert

Only if it meets at least one condition:

• Same-day deadline or real risk
• Explicit direct ask of Elmar
• Approval/send decision required
• Time-sensitive family/travel/exam item
• Iris has done the prep and needs a yes/no/choice

Hard cap: max 1 proactive alert bundle per half-day, unless critical.

2. Replace “10 suggestions” with “Iris recommends 1 next move”

Bad pattern:

“Here are 10 things you may want to do.”

Better pattern:

“I recommend doing A now. I can handle B and C silently. D can wait. Reply: 1 approve A, 2 ask me to draft, 3 snooze all.”

The assistant’s job is to reduce decision load by choosing a default.

3. One Telegram card should have at most 3 actions

For mobile/Telgram use, cap the card:

• 1 recommended action
• up to 2 secondary actions
• one “snooze/quiet” option

If there are more than 3 items, Iris should say:

“I found 9 items, but only 2 need you. The rest are filed in the dashboard.”

4. Shift from “tasks” to “offers”

Every proactive message should be phrased as an offer of work Iris can do, not a burden Elmar must absorb.

Examples:

• “I can draft the reply; reply D1.”
• “I can mark this no-action; reply N1.”
• “I can prepare a meeting brief; reply B1.”
• “I can snooze this until Monday; reply S1.”

5. Introduce an “Iris attention budget”

Suggested defaults:

• Critical alerts: anytime, but only true risk.
• Workday proactive bundles: 10:30 and 16:30 only.
• Evening personal digest: 19:30 only if there are true personal/family items.
• All cleanup/noise/rule suggestions: weekly batch, not daily, unless user explicitly asks.

6. Consolidate cron jobs behind an aggregator

Instead of multiple jobs independently messaging Elmar, keep scanners but route them into one aggregator state:

• Scanner jobs collect signals and write state/tickets.
• Aggregator decides what, if anything, to say.
• Delivery gate applies caps, dedupe, and quiet hours.
• Telegram gets only final recommendations.

7. Make “no reply” meaningful

If Elmar does not reply to an Iris suggestion, Iris should not repeat it unchanged. It should automatically downgrade:

• First surfacing: direct offer
• No response: snooze until next digest
• Repeated no response: ask once whether to suppress this class
• Continued no response: silently file unless deadline/risk changes

8. Add a friction metric to Iris itself

Each cron output should score itself before delivery:

• How many decisions am I asking Elmar to make?
• Can I do any of these without asking?
• Is this old information?
• Is there a recommended default?
• Would this be better as a dashboard item?

If decision_count > 3, the message should not send as-is.

Proposed Telegram formats

Format A: “One recommendation”

Iris recommends: approve the school-fee reply today.
Why: deadline tomorrow; draft is ready.

Reply:
1 send draft
2 show draft
3 snooze to 16:00

Format B: “Digest with only exceptions”

Life scan: 2 things need you. I handled/filed 7 others.

1) Travel booking: hotel confirmation missing — I can search again or draft a chaser.
2) Calendar: Friday meeting has no venue — I found likely venue; approve update?

Reply: 1 chaser, 2 approve venue, Q quiet until 16:30

Format C: “No-action reassurance”

I checked inbox, WhatsApp, and diary. No current actions.
I filed 4 FYIs and updated tomorrow’s prep note.

But even this should be limited; silence is usually better than “no actions” unless Elmar wants reassurance.

Specific changes I recommend for Iris cron

Immediate low-risk changes

1. Pause or reduce the daily email cleanup and noisy email sweep messages.
2. These are useful, but not daily Telegram-worthy.

3. Move them to weekly or dashboard-only.

4. Merge daytime Life delta and missed-communications guardian into a single delivery gate.

5. They can still scan separately.

6. Only one should be allowed to message Elmar in a given window.

7. Add a strict output contract to every Iris proactive job:

8. max 3 bullets
9. must include one recommended default
10. must include “I can do X” action offers

11. do not send if only low-confidence suggestions

12. Add “quiet mode” commands:

13. Q2 quiet for 2 hours
14. QT quiet until tomorrow
15. W weekly-only cleanup suggestions

16. STOPCLASS <class> suppress this category

17. Introduce “handled silently” logging.

18. Iris should get credit for invisible work in the digest/dashboard, not by sending a Telegram each time.

Structural change

Create an iris_attention_gate cron/script that receives candidate findings from all Iris scanners and decides:

• send now
• batch into next digest
• dashboard only
• ticket only
• suppress as duplicate/no-action

This is the key architectural improvement.

Counterpoints

1. If Iris becomes too quiet, she may miss time-sensitive items or reduce trust. The answer is not silence; it is escalation rules with auditability.
2. Some people like more frequent reassurance. Elmar’s feedback here is clear: the current volume is too high, so the default should move toward quiet batching.
3. AI triage can wrongly suppress items. Therefore suppression should be conservative for high-risk categories: family, travel, money, legal, school/exams, deadlines, direct asks.
4. Dashboards can become graveyards. The daily/weekly digest must still surface “what changed” and “what needs Elmar,” not just hide everything.

Stage 6: GAP_ANALYSIS

• gaps:
• Need exact delivery history from Telegram to measure actual message volume per day and category.
• Need current cron prompts for the highest-noise jobs to patch them precisely.
• Need user preference calibration: how many proactive Iris messages per day feels acceptable?
• threads:
• Build an attention-budget ledger and dedupe cache shared by cron jobs.
• Convert cleanup/recommendation jobs from “message user” to “prepare approval cards only when confidence is high.”
• Add negative-feedback learning: no response should reduce future surfacing of similar items.
• contradictions:
• Executive-assistant advice often encourages frequent check-ins, while notification research favours batching. For Elmar, batching should win unless the item is genuinely urgent.

Stage 7: ITERATE round 1

Targeted follow-up focused on the identified gap: current Iris cron architecture. The live cron list confirms that Iris has multiple independent emitters, including several daily/weekday jobs and one 15-minute Control Room watcher. This supports the diagnosis that the issue is structural, not just wording.

Recommendation after iteration: keep the scanners, but move delivery authority into one gate.

Stage 7.5: RED-TEAM CRITIQUE

The red-team critique was run against the draft and produced three important implementation warnings:

• Skeptical practitioner: The proposal may over-focus on notification frequency; output relevance and confidence also need to improve. GTD is useful as an analogy, but an AI assistant can also do work directly, not only organize human tasks.
• Adversarial reviewer: A centralized attention gate can become a single point of failure. Critical categories need a bypass/fallback path, and “no reply” should not always mean “not interested” because Elmar may be flying, sleeping, or in meetings.
• Implementation engineer: The design needs a concrete state schema, command routing for Telegram replies, and failure reporting for silent jobs.

Blockers before full build:

• Define the shared candidate/action schema between scanner jobs and the gate.
• Ensure Telegram reply commands map to specific cards even when messages are out of order.
• Add a critical-alert bypass and watchdog for gate failure.

Stage 7.6: CRITIQUE LOOP-BACK

The critique flagged several under-sourced load-bearing claims. I added a loop-back source round for:

• notification batching: ScienceDirect paper record for Fitz/Kushlev et al.
• calm technology: principles.design mirror/summary of Calm Technology principles
• executive inbox management: Superhuman and Inbox Zero executive-inbox guidance

Remaining low-confidence area: broad personal-CRM design patterns were sourced mainly from vendor material. This does not affect the core recommendation, but contact-management changes should be treated as a later phase and validated against Elmar’s actual relationship workflows.

Recommended implementation sequence

Phase 1 — Stop the bleeding today

• Reduce proactive Telegram outputs to two main bundles per day plus critical exceptions.
• Convert email cleanup/noise scans to weekly or dashboard-only.
• Patch all proactive prompts to max 3 actions, one recommendation, and “I can do this” offers.

Phase 2 — Make Iris useful, not noisy

• Add shared dedupe and attention-budget state.
• Add category suppression learning.
• Add “no response = downgrade/snooze” logic.
• Add digest lines that show invisible work: “handled/filed/drafted,” not just tasks.

Phase 3 — Build the proper Life Manager command centre

• One dashboard/private state store for all findings.
• One attention gate for all outbound messages.
• One daily “what Iris thinks Elmar should do” recommendation.
• One weekly relationship/contact review, only with suggested concrete follow-ups.

Bottom-line recommendation

Iris should stop acting like a set of cron jobs that report findings and start acting like an executive assistant with an attention budget.

The core rule should be:

Iris may scan constantly, but she may interrupt rarely — and only with a small, confident, actionable recommendation.