PRD-038 — Agentic Attention, Notification & Escalation Orchestration

1. Objetivo

O PRD-038 define a camada responsável por transformar eventos, riscos, exceções, deadlines e decisões em atenção humana ou automática, entregando a informação correta à pessoa ou equipe adequada.

A arquitetura passa a ter:

EVENT / SIGNAL
      ↓
INTERPRETATION
      ↓
RISK / PRIORITY
      ↓
ATTENTION ITEM
      ↓
AUDIENCE RESOLUTION
      ↓
CHANNEL SELECTION
      ↓
NOTIFICATION
      ↓
ACKNOWLEDGEMENT
      ↓
ESCALATION
      ↓
RESOLUTION

O objetivo não é simplesmente criar um sistema de notificações.

É criar uma orquestração de atenção.

2. Problema

Um sistema SST pode gerar milhares de eventos diariamente:

TrainingExpired
TrainingExpiringSoon
WorkPermitBlocked
ApprovalPending
DeadlineApproaching
SLAWarning
SLAExpired
IntegrationFailure
WorkflowBlocked
RiskDetected
GoalAtRisk

Enviar tudo para todos seria operacionalmente inviável.

O Agentic Work precisa responder:

Essa situação realmente exige atenção humana?

E, caso exija:

Quem deve agir, em quanto tempo e através de qual canal?

3. Princípio Fundamental

Uma ocorrência não deve automaticamente gerar uma notificação.

EVENT
  ↓
SIGNAL
  ↓
EVALUATION
  ↓
ATTENTION DECISION
  ↓
NOTIFICATION

Pode acontecer:

EVENT
 ↓
no human attention required

ou:

EVENT
 ↓
automatic action
 ↓
no notification

ou:

EVENT
 ↓
human approval required

4. Attention ≠ Notification

Essa distinção será central.

Attention

Representa:

“Existe algo que alguém precisa perceber ou resolver.”

Notification

Representa:

“Entregue uma mensagem por determinado canal.”

Portanto:

Attention Item
 ├── Notification A
 ├── Notification B
 └── Escalation

5. Attention Item

interface AttentionItem {
  attentionId: string;

  tenantId: string;

  type: AttentionType;

  title: string;

  description: string;

  priority: AttentionPriority;

  severity: AttentionSeverity;

  status: AttentionStatus;

  source: AttentionSource;

  entityRefs: EntityRef[];

  goalId?: string;

  taskId?: string;

  workflowId?: string;

  executionId?: string;

  assignedTo?: AttentionAssignee;

  dueAt?: string;

  createdAt: string;

  updatedAt: string;
}

6. Attention Types

INFORMATION
NOTICE
REMINDER
WARNING
ACTION_REQUIRED
APPROVAL_REQUIRED
REVIEW_REQUIRED
ESCALATION
INCIDENT
CRITICAL

7. Priority

Prioridade deverá ser distinta de severidade.

LOW
NORMAL
HIGH
URGENT
CRITICAL

8. Severity

Severidade representa impacto potencial:

LOW
MEDIUM
HIGH
CRITICAL

Exemplo:

Severity = HIGH
Priority = LOW

pode significar uma situação grave, mas que não requer intervenção imediata.

9. Urgency

A urgência poderá ser calculada usando:

deadline
risk
impact
dependency
goal importance
current state

10. Attention Score

Uma pontuação poderá ser calculada:

attentionScore =
impact
× urgency
× risk
× businessPriority

O algoritmo deverá ser versionado.

11. No Arbitrary LLM Priority

O LLM não poderá simplesmente declarar:

“Isso parece urgente.”

A prioridade deverá utilizar:

regras;
políticas;
métricas;
deadlines;
risco;
contexto.

O LLM poderá auxiliar na classificação semântica, mas não terá autoridade final.

12. Deduplication

Se o sistema receber:

TrainingExpired
TrainingExpired
TrainingExpired

não deverá criar três alertas idênticos.

Deverá produzir:

1 Attention Item
occurrences = 3

13. Attention Aggregation

Exemplo:

127 Work Permits
training expiring

Em vez de:

127 notifications

poderá existir:

1 aggregated Attention Item

com:

14. Alert Fatigue Protection

O sistema deverá controlar:

notification frequency
duplicate rate
acknowledgement rate
dismissal rate
escalation rate

15. Suppression

Uma atenção poderá ser temporariamente suprimida:

SUPPRESSED

sem apagar o evento original.

16. Suppression TTL

Exemplo:

Lembrar novamente em 4 horas.

{
  "suppressedUntil": "2026-09-01T20:00:00Z"
}

17. Acknowledgement

A pessoa poderá reconhecer:

ACKNOWLEDGED

Isso não significa necessariamente:

RESOLVED

18. Attention Lifecycle

CREATED
 ↓
OPEN
 ↓
ACKNOWLEDGED
 ↓
IN_PROGRESS
 ↓
RESOLVED
 ↓
CLOSED

Alternativas:

DISMISSED
SUPPRESSED
ESCALATED
EXPIRED
CANCELLED

19. Assignment

Attention Items poderão ser atribuídos a:

USER
TEAM
ROLE
DEPARTMENT
AGENT
QUEUE

20. Assignment Resolution

Exemplo:

Work Permit
 ↓
employee.department
 ↓
Safety Team
 ↓
Supervisor

A resolução deverá ser determinística e baseada em regras.

21. Responsibility Graph

O Knowledge Graph poderá ajudar a descobrir:

WorkPermit
 → Employee
 → Department
 → Supervisor
 → Safety Team

Mas a atribuição final deverá passar por Policy.

22. Escalation

Se uma atenção não for resolvida:

Supervisor
 ↓
Manager
 ↓
Safety Director

23. Escalation Policy

interface EscalationPolicy {
  policyId: string;

  levels: EscalationLevel[];

  maxEscalations: number;

  stopCondition: string;
}

24. Escalation Level

interface EscalationLevel {
  level: number;

  after: string;

  audience: AttentionAssignee;

  channels: NotificationChannel[];

  priorityIncrease?: boolean;
}

25. Example

0h  → Supervisor
4h  → Manager
8h  → Safety Director

26. Temporal Integration

O PRD-037 será responsável por:

when escalation occurs
when reminder occurs
when SLA expires

Assim:

Attention
 ↓
Temporal Scheduler
 ↓
Reminder / Escalation

27. Notification Channels

A arquitetura deverá permitir:

IN_APP
EMAIL
PUSH
SMS
WEBHOOK
CHAT
WHATSAPP
VOICE

A disponibilidade concreta dependerá das integrações instaladas.

28. Channel Abstraction

interface NotificationChannel {
  channelId: string;

  type: string;

  send(
    notification: NotificationRequest
  ): Promise<NotificationResult>;
}

29. External Gateway

Canais externos deverão utilizar o PRD-025.

Nunca:

Agent → WhatsApp API

diretamente.

Sempre:

Agent
 ↓
Capability
 ↓
Policy
 ↓
External Gateway
 ↓
Channel

30. Notification Model

interface Notification {
  notificationId: string;

  attentionId: string;

  tenantId: string;

  recipient: NotificationRecipient;

  channel: string;

  templateId: string;

  payload: Record<string, unknown>;

  priority: AttentionPriority;

  scheduledAt?: string;

  expiresAt?: string;

  status: NotificationStatus;
}

31. Templates

Mensagens deverão usar templates versionados.

training-expiring.v3
work-permit-blocked.v2
approval-required.v4

32. Localization

Templates poderão possuir:

pt-BR
en-US
es

e respeitar locale do destinatário.

33. Notification ≠ Business Action

Receber:

“Seu Work Permit está bloqueado.”

não significa executar:

UNBLOCK

A notificação é apenas comunicação.

34. Actionable Notification

Algumas notificações poderão possuir ação:

[Revisar]
[Aprovar]
[Ver detalhes]

Mas cada botão deverá mapear para uma Capability registrada.

35. Deep Link

O link deverá apontar para uma rota semântica:

/work-permits/WP-1001

ou um identificador semântico equivalente.

Não deverá embutir autorização no link.

36. Authentication

Ao abrir a ação:

User
 ↓
Authentication
 ↓
Authorization
 ↓
Capability

será revalidada.

37. Notification Action Token

Quando necessário, poderá existir um token curto:

attentionActionToken

Esse token deverá ser:

limitado;
expirável;
vinculado ao usuário;
vinculado ao tenant;
vinculado à atenção;
incapaz de ampliar permissões.

38. Approval Notification

Para:

“Aprovar Work Permit”

a notificação poderá levar ao Decision Center.

A aprovação real seguirá:

Notification
 ↓
Decision Center
 ↓
Policy
 ↓
Confirmation
 ↓
Capability
 ↓
Execution

39. Quiet Hours

Usuários poderão possuir períodos:

22:00–07:00

durante os quais notificações não críticas são adiadas.

40. Critical Override

Notificações CRITICAL poderão ultrapassar quiet hours quando autorizado pela Policy.

41. Notification Preferences

interface NotificationPreferences {
  userId: string;

  channels: ChannelPreference[];

  quietHours?: QuietHours;

  digestMode?: DigestMode;

  categories: CategoryPreference[];
}

42. User Preference ≠ Policy

Um usuário poderá dizer:

“Não quero receber e-mail.”

Mas não poderá desativar uma comunicação que uma Policy determine como obrigatória.

43. Channel Selection

O sistema poderá escolher:

IN_APP

para informação normal e:

PUSH + EMAIL

para alta prioridade.

44. Adaptive Channel Selection

A seleção poderá considerar:

priority
urgency
user preference
channel availability
delivery history
time
policy

45. No Manipulative Notification

O Agent não poderá gerar mensagens projetadas para pressionar indevidamente o usuário.

Exemplo proibido:

“Você precisa aprovar agora ou o sistema inteiro ficará indisponível.”

sem evidência.

46. Evidence in Notifications

Quando relevante, a notificação deverá incluir evidência:

Training expires:
15/09/2026

Affected Work Permits:
23

Source:
LMS synchronization

47. Explainability

O usuário deverá poder acessar:

Why am I seeing this?

e obter:

origem;
entidade;
regra;
deadline;
evidência;
prioridade;
política aplicável.

48. Notification Batching

Exemplo:

23 notifications

podem virar:

Daily summary:
23 Work Permits require attention

desde que a urgência permita.

49. Digest

DAILY
HOURLY
WEEKLY

50. Immediate Delivery

Itens:

CRITICAL
URGENT
APPROVAL_REQUIRED

poderão exigir entrega imediata.

51. Notification Delivery States

QUEUED
SENDING
SENT
DELIVERED
FAILED
EXPIRED
CANCELLED

52. Delivery Confirmation

Quando o canal suportar:

SENT
DELIVERED
READ

serão estados diferentes.

53. No False Acknowledgement

O sistema nunca deverá interpretar:

SENT

como:

READ

54. Failed Delivery

Se:

email failed

o Orchestrator poderá selecionar outro canal, conforme Policy:

EMAIL
 ↓
PUSH
 ↓
IN_APP

55. Channel Failure

Integração externa indisponível:

WhatsApp unavailable

deverá gerar uma exceção tratada pelo PRD-024.

56. Notification Retry

Retries deverão:

respeitar idempotência;
possuir limite;
usar backoff;
não gerar duplicatas.

57. Idempotency

notificationKey =
attentionId +
recipientId +
channel +
templateVersion +
occurrenceId;

58. Attention Ownership

A mesma atenção poderá mudar de responsável:

Supervisor
 ↓
Manager

O histórico deverá ser preservado.

59. Assignment History

interface AssignmentEvent {
  attentionId: string;

  from?: AttentionAssignee;

  to: AttentionAssignee;

  reason: string;

  occurredAt: string;
}

60. Attention Queue

Equipes poderão possuir filas:

Safety Review
Training Review
Incident Response
Work Permit Approval

61. Queue Prioritization

Dentro da fila:

CRITICAL
 ↓
URGENT
 ↓
HIGH
 ↓
NORMAL

com deadline e SLA como fatores adicionais.

62. Load Balancing

A atribuição poderá considerar:

team capacity
current workload
skill
availability
location
shift

Integrando com PRD-033.

63. Skill-Based Routing

Exemplo:

Risk issue
 ↓
requires skill = "industrial-risk"
 ↓
route to qualified team

64. Qualification

A Policy deverá determinar se um usuário pode assumir determinada atenção.

65. Delegation

PRD-027 permitirá delegação temporária:

Supervisor unavailable
 ↓
delegation active
 ↓
Manager receives attention

66. Delegation Expiration

Quando expirar:

reassign

ou:

escalate

conforme policy.

67. Attention Center

O PRD-022 será a interface principal.

┌────────────────────────────────────┐
│ Attention Center                   │
├────────────────────────────────────┤
│ 🔴 3 Critical                      │
│ 🟠 17 Urgent                       │
│ 🟡 42 Action Required              │
│                                    │
│ [Filter] [Assign] [Snooze]         │
└────────────────────────────────────┘

68. Semantic UI

A UI deverá expor semanticamente:

attentionCenter
attentionList
attentionItem
attentionActions
attentionFilters

conforme PRD-011.

69. Agent Access

O usuário poderá perguntar:

“O que precisa da minha atenção?”

O Agent deverá consultar:

Attention Center
+
permissions
+
assignment
+
priority
+
deadline

70. Natural Language Actions

“Mostre os críticos.”

→ filtro semântico.

“Resolva o primeiro.”

→ referência à atenção atual.

“Passe esse para João.”

→ Assignment Capability + Policy.

71. Ambiguous Reference

Se existirem:

3 critical items

e o usuário disser:

“Resolva aquele.”

o sistema deverá utilizar contexto/foco ou pedir esclarecimento.

72. Bulk Actions

“Resolva todos.”

será considerado potencialmente alto risco.

Deverá existir:

limite;
preview;
confirmação;
Policy;
audit.

73. Attention Bulk Aggregation

Uma operação em massa poderá tratar:

100 Attention Items

como:

1 bulk operation

sem perder o histórico individual.

74. Goal Integration

Goals poderão gerar:

GoalAtRisk

que vira:

AttentionItem

75. Exception Integration

Incidentes críticos:

Incident
 ↓
Critical Attention
 ↓
Incident Response Team

76. Proactive Integration

O PRD-021 poderá produzir:

Recommendation

e o Attention Orchestrator decidir:

inform
remind
require action
escalate

77. Decision Integration

Uma decisão que necessita aprovação:

Decision
 ↓
APPROVAL_REQUIRED
 ↓
Attention
 ↓
Decision Center

78. Workflow Integration

Workflow bloqueado:

Workflow
 ↓
WAITING_APPROVAL
 ↓
Attention

79. Temporal Integration

Attention
 ↓
dueAt
 ↓
Scheduler
 ↓
reminder
 ↓
escalation

80. Event Fabric Integration

Eventos de atenção:

AttentionCreated
AttentionAssigned
AttentionAcknowledged
AttentionEscalated
AttentionResolved
AttentionClosed
NotificationSent
NotificationFailed

81. State Fabric Integration

Attention deverá possuir versão:

attentionVersion

evitando duas pessoas resolverem o mesmo item simultaneamente.

82. Optimistic Concurrency

User A:
attention version 5

User B:
attention version 5

User A resolves
→ version 6

User B resolves
→ VERSION_CONFLICT

83. Security

O Attention Center deverá filtrar por:

tenant
user
roles
permissions
resource access
delegation
policy

84. Information Leakage Protection

Mesmo a existência de uma atenção pode ser informação sensível.

Não revelar:

"Você não tem acesso ao incidente X"

quando isso permitir inferir que X existe.

85. Notification Data Minimization

E-mails e mensagens externas deverão evitar dados sensíveis desnecessários.

Exemplo:

Em vez de:

“João da Silva, CPF ..., teve treinamento de NR-... vencido...”

poder usar:

“Um treinamento associado a um Work Permit requer atenção.”

O detalhe completo fica no sistema autenticado.

86. External Channel Security

Nunca enviar:

tokens;
credentials;
dados secretos;
links permanentes de autorização;
informações de outro tenant.

87. Audit

Cada etapa deverá ser auditável:

Attention created
Priority calculated
Assigned
Notification scheduled
Notification sent
Notification delivered
Acknowledged
Escalated
Resolved
Closed

88. Audit Reason

Mudanças de prioridade/assignment deverão registrar:

reason
actor
policyVersion
timestamp

89. Observability

Métricas:

attention_created
attention_resolved
attention_escalated
attention_overdue
notification_sent
notification_failed
notification_delivered
notification_read
duplicate_suppressed
attention_suppressed
false_alert_rate

90. Attention Quality

Medir:

Time To Acknowledge
Time To Resolution
Time To Escalation
Notification Delivery Rate
Alert Fatigue Rate
Dismissal Rate
False Positive Rate

91. Intelligent Suppression

O sistema poderá identificar:

100 identical low-risk alerts

e agrupá-los.

Mas a supressão deverá respeitar Policy.

92. No Silent Suppression of Critical Items

Itens:

CRITICAL
SECURITY
SAFETY
COMPLIANCE

não poderão ser silenciosamente suprimidos por modelos estatísticos.

93. Learning Integration

PRD-012 poderá identificar:

90% of notifications dismissed

e sugerir:

Reduzir frequência dessa categoria.

Mas a mudança deverá passar por revisão.

94. Notification Experimentation

Poderá existir A/B testing para:

horário;
canal;
template;
agrupamento.

Não para:

segurança;
autorização;
critical escalation.

95. Cost Optimization

Canais externos possuem custos diferentes.

O sistema poderá preferir:

IN_APP

antes de:

SMS

quando a urgência permitir.

96. Channel Fallback Matrix

Exemplo:

Prioridade	Principal	Fallback
Normal	In-App	Digest
High	Push	Email
Urgent	Push + Email	SMS
Critical	Push + Email	Escalation

A configuração será por tenant/policy.

97. Rate Limits

Existirão limites por:

tenant
user
team
channel
attention type
time window

98. Notification Storm Protection

Se um evento sistêmico gerar:

50,000 notifications

o sistema deverá:

aggregate
throttle
prioritize
deduplicate

em vez de disparar tudo imediatamente.

99. Incident Mode

Durante um incidente:

10,000 errors

o sistema poderá criar:

1 Incident
+
1 Critical Attention

em vez de 10.000 notificações.

100. Attention Resolution

Resolver uma atenção não significa necessariamente resolver a causa.

Exemplo:

Notification acknowledged

mas:

Work Permit still blocked

Então:

ACKNOWLEDGED
≠
RESOLVED

101. Automatic Resolution

Uma atenção poderá ser automaticamente resolvida quando a condição desaparecer.

Exemplo:

TrainingExpired
 ↓
TrainingRenewed
 ↓
condition false
 ↓
Attention RESOLVED

102. Resolution Verification

A resolução deverá utilizar o State Fabric:

state changed
 ↓
verify
 ↓
resolve attention

103. Stale Attention

Se uma atenção tiver sido criada sobre:

WorkPermit version 42

mas o estado atual for:

version 43

ela deverá ser reavaliada.

104. Attention Reconciliation

Attention
 ↓
State Fabric
 ↓
Current state
 ↓
still valid?
 ├── YES → remain open
 └── NO  → auto-resolve/update

105. First Vertical Slice

Caso:

Training expiration → Work Permit compliance → Human attention

106. Scenario

Training expires in 15 days

Temporal Intelligence gera:

DeadlineApproaching

107. Proactive Evaluation

PRD-021 identifica:

23 Work Permits affected

108. Goal Evaluation

PRD-036:

Goal:
Maintain Work Permit Compliance

Status:
AT_RISK

109. Attention Creation

Attention:
23 Work Permits require training renewal

Priority:
HIGH

Owner:
Safety Team

110. Notification

IN_APP
+
EMAIL

para o responsável.

111. Escalation

Se não houver acknowledgement em:

24 hours

→ Supervisor.

Após:

48 hours

→ Manager.

112. Resolution

Quando o LMS informar:

Training renewed

o State Fabric atualiza o estado.

A atenção é reavaliada.

Se todos os 23 estiverem conformes:

Attention → RESOLVED
Goal → progress updated

113. Acceptance Criteria

Evidência de implementação e produção — 2026-09-05

A base de atenção está implementada com itens e eventos imutáveis por tenant, pontuação versionada que separa prioridade de severidade, deduplicação/agregação limitada contra storm, supressão, roteamento por qualificação/capacidade/delegação ativa, ciclo de vida e escalonamento. Rotas autenticadas persistem templates versionados, políticas, atribuições, tokens de ação de uso único e reconciliação com evidência. O runtime expira itens vencidos e despacha entregas in-app e externas idempotentes via Event Fabric; entregas externas registram tentativas, recibos ou falhas.

Em 2026-09-05, verify:attention passou com 43 testes em 6 arquivos. O canário autenticado em produção comprovou 23 ocorrências agregadas de seis fontes, prioridade URGENT e severidade HIGH, delegação, template pt-BR, canais EMAIL/IN_APP, payload minimizado, token de ação de 64 caracteres consumido uma vez, lifecycle completo, escalonamento de dois níveis, reconciliação versionada, isolamento de tenant e negação sem autenticação; terminou com remainingRows: 0 e sem conceder execução. A prova valida o contrato de orquestração; aceite pelo provedor externo continua uma observação operacional distinta de entrega registrada pelo sistema.

Em 2026-09-06, a regressão atual de runtime, notificações, orquestração, escalonamento e projeções de Attention passou com 51 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A classificação PROVEN_CLOUDFLARE permanece sustentada pelo canário autenticado registrado.

114. Resultado Arquitetural

Com o PRD-038, o Agentic Work passa a fechar o ciclo entre inteligência e atenção humana:

                    EVENT
                      │
                      ▼
                   SIGNAL
                      │
                      ▼
               PROACTIVE / GOAL
                      │
                      ▼
                RISK / DECISION
                      │
                      ▼
               ATTENTION ENGINE
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
       ASSIGN       NOTIFY      ESCALATE
          │           │           │
          └───────────┼───────────┘
                      ▼
                   HUMAN
                      │
                      ▼
                  ACTION
                      │
                      ▼
                VERIFICATION
                      │
                      ▼
                 STATE FABRIC
                      │
                      ▼
                  RESOLUTION

A grande mudança é que o sistema deixa de simplesmente produzir alertas.

Ele passa a administrar um ciclo completo:

detectar → priorizar → direcionar → comunicar → acompanhar → escalar → verificar → resolver.

PRD-039 — Agentic Resource & Workforce Coordination Fabric

A próxima camada surge naturalmente do PRD-038.

Agora sabemos:

o que precisa ser feito — Goals;
quando — Temporal Intelligence;
quem precisa saber — Attention;
qual ação executar — Capabilities;
como executar — Planning;
como adaptar — Runtime;
qual estado é verdadeiro — State Fabric.

Mas existe uma pergunta ainda não resolvida:

Quem ou o que possui capacidade real para realizar o trabalho?

Isso envolve muito mais que infraestrutura computacional.

O Agentic Work deverá coordenar:

HUMANS
TEAMS
AGENTS
SYSTEMS
APIs
MACHINES
RESOURCES
EXTERNAL PROVIDERS

O PRD-039 deverá portanto criar uma camada de Resource & Workforce Coordination, cobrindo:

Resource Registry;
Human Resources;
Team Resources;
Agent Resources;
System Resources;
Physical Resources;
Skills;
Qualifications;
Certifications;
Availability;
Capacity;
Shift;
Location;
Workload;
Reservations;
Allocation;
Assignment;
Skill Matching;
Workforce Scheduling;
Resource Conflicts;
Resource Dependencies;
Capacity Forecasting;
Workload Balancing;
Priority;
SLA;
Cost;
Resource Health;
Qualification Expiration;
Delegation;
Substitution;
Absence;
Escalation;
Multi-tenant quotas;
Human + Agent collaboration;
Human-in-the-loop assignment;
Resource-aware planning;
Resource-aware execution;
Dynamic reassignment;
Resource reservation;
Release of resources;
Resource contention;
Capacity exhaustion;
External resource availability;
audit;
observability.

O conceito central será:

TASK
  ↓
REQUIRED CAPABILITIES
  ↓
REQUIRED SKILLS
  ↓
AVAILABLE RESOURCES
  ↓
QUALIFICATION
  ↓
CAPACITY
  ↓
ASSIGNMENT
  ↓
EXECUTION

E isso permitirá que o Agentic Work evolua de:

“Eu sei o que precisa ser feito.”

para:

“Eu sei o que precisa ser feito, quem ou o que pode fazê-lo, se essa capacidade está disponível, quando pode fazê-lo e como alocar o recurso sem violar as regras do sistema.”

1. Objetivo​

2. Problema

3. Princípio Fundamental

4. Attention ≠ Notification

Attention​

Notification​

5. Attention Item

6. Attention Types

7. Priority

8. Severity

9. Urgency

10. Attention Score

11. No Arbitrary LLM Priority

12. Deduplication

13. Attention Aggregation

14. Alert Fatigue Protection

15. Suppression

16. Suppression TTL

17. Acknowledgement

18. Attention Lifecycle

19. Assignment

20. Assignment Resolution

21. Responsibility Graph

22. Escalation

23. Escalation Policy

24. Escalation Level

25. Example

26. Temporal Integration

27. Notification Channels

28. Channel Abstraction

29. External Gateway

30. Notification Model

31. Templates

32. Localization

33. Notification ≠ Business Action

34. Actionable Notification

35. Deep Link

36. Authentication

37. Notification Action Token

38. Approval Notification

39. Quiet Hours

40. Critical Override

41. Notification Preferences

42. User Preference ≠ Policy

43. Channel Selection

44. Adaptive Channel Selection

45. No Manipulative Notification

46. Evidence in Notifications

47. Explainability

48. Notification Batching

49. Digest

50. Immediate Delivery

51. Notification Delivery States

52. Delivery Confirmation

53. No False Acknowledgement

54. Failed Delivery

55. Channel Failure

56. Notification Retry

57. Idempotency

58. Attention Ownership

59. Assignment History

60. Attention Queue

61. Queue Prioritization

62. Load Balancing

63. Skill-Based Routing

64. Qualification

65. Delegation

66. Delegation Expiration

67. Attention Center

68. Semantic UI

69. Agent Access

70. Natural Language Actions

71. Ambiguous Reference

72. Bulk Actions

73. Attention Bulk Aggregation

74. Goal Integration

75. Exception Integration

76. Proactive Integration

77. Decision Integration

78. Workflow Integration

1. Objetivo

Attention

Notification

Evidência de implementação e produção — 2026-09-05