PRD-022 — Agentic Attention, Notification & Human Decision Center

1. Objetivo

O Agentic Attention, Notification & Human Decision Center será a camada responsável por transformar a enorme quantidade de eventos, sinais, riscos, recomendações, aprovações e exceções produzidos pelo Agentic Work em uma experiência de atenção humana priorizada, contextual e acionável.

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

O objetivo é criar um sistema de gerenciamento de atenção operacional.

A arquitetura deverá responder:

O que realmente precisa da minha atenção agora?

Qual decisão preciso tomar, por quê, qual o impacto e o que acontece se eu não fizer nada?

2. Problema

Com os PRDs anteriores, o sistema passa a ser capaz de:

detectar eventos;
identificar riscos;
gerar recomendações;
iniciar workflows;
executar ações;
solicitar aprovação;
detectar situações futuras;
monitorar processos.

Isso cria um novo problema.

Sem uma camada de Attention Management, o sistema pode produzir:

100 eventos
↓
35 sinais
↓
20 recomendações
↓
12 notificações
↓
7 emails
↓
5 push notifications

O usuário passa a sofrer de:

Alert Fatigue

Portanto:

Signal ≠ Notification
Notification ≠ Attention Item
Attention Item ≠ Human Decision

Esses conceitos deverão ser separados.

3. Princípio fundamental

O sistema deverá seguir:

Notificar menos, mas com maior relevância.

A prioridade será:

Relevância
>
Urgência
>
Impacto
>
Ação necessária
>
Canal

Não deverá existir uma regra simplista:

event → notification

O fluxo correto será:

Event
 ↓
Signal
 ↓
Risk
 ↓
Recommendation
 ↓
Attention Evaluation
 ↓
Decision:
 ├── Ignore
 ├── Aggregate
 ├── Digest
 ├── Notify
 ├── Escalate
 └── Require Human Decision

4. Arquitetura

                   Event Fabric
                        │
                        ▼
                Proactive Intelligence
                        │
                        ▼
                 Risk / Recommendation
                        │
                        ▼
             ┌────────────────────────┐
             │ Attention Engine        │
             └───────────┬────────────┘
                         │
          ┌──────────────┼───────────────┐
          │              │               │
          ▼              ▼               ▼
      Aggregate       Prioritize      Suppress
          │              │               │
          └──────────────┼───────────────┘
                         ▼
                 Attention Item
                         │
          ┌──────────────┼───────────────┐
          ▼              ▼               ▼
      Notification    Decision        Escalation
          │              │               │
          ▼              ▼               ▼
       Channels      Human Action    Workflow

5. Attention Item

A unidade central do sistema será o Attention Item.

interface AttentionItem {
  attentionId: string;

  tenantId: string;

  type: AttentionType;

  title: string;

  summary: string;

  priority: AttentionPriority;

  urgency: number;

  impact: number;

  relevance: number;

  riskScore?: number;

  confidence?: number;

  source: AttentionSource;

  entityRefs: EntityReference[];

  recommendationId?: string;

  workflowId?: string;

  approvalId?: string;

  requiredAction?: RequiredAction;

  status: AttentionStatus;

  createdAt: string;

  expiresAt?: string;

  acknowledgedAt?: string;

  resolvedAt?: string;
}

6. Tipos

Inicialmente:

RISK
RECOMMENDATION
APPROVAL
EXCEPTION
DEADLINE
ESCALATION
WORKFLOW_BLOCKED
WORKFLOW_FAILED
COMPLIANCE
SYSTEM_ALERT
HUMAN_DECISION

7. Status

enum AttentionStatus {
  NEW,
  SEEN,
  ACKNOWLEDGED,
  IN_PROGRESS,
  WAITING,
  RESOLVED,
  DISMISSED,
  EXPIRED,
  ESCALATED
}

Importante:

SEEN ≠ ACKNOWLEDGED

Visualizar não significa assumir responsabilidade.

8. Required Action

O sistema deverá indicar claramente o que espera do usuário.

interface RequiredAction {
  type:
    | "VIEW"
    | "APPROVE"
    | "REJECT"
    | "REVIEW"
    | "CORRECT"
    | "CONFIRM"
    | "ASSIGN"
    | "EXECUTE"
    | "WAIT";

  capabilityId?: string;

  workflowId?: string;

  deadline?: string;
}

Exemplo:

“Aprovar a liberação da Work Permit WP-10231.”

9. Atenção vs. Notificação

Um Attention Item pode existir sem gerar notificação.

Exemplo:

Risk LOW
↓
Attention Item
↓
Dashboard

Nenhum push é enviado.

Já:

Risk CRITICAL
+
Deadline < 2h
+
User responsible

poderá gerar:

In-App
+
Push
+
Escalation

10. Attention Scoring

O sistema deverá calcular um score de atenção.

Uma primeira implementação:

AttentionScore =
  Risk
  × Urgency
  × Impact
  × Relevance
  × Confidence

Com normalização para 0–100.

Por exemplo:

Risk       = 90
Urgency    = 95
Impact     = 80
Relevance  = 100
Confidence = 99

AttentionScore ≈ 68

O cálculo exato deverá ser configurável e versionado.

11. Urgency

Urgência deverá considerar tempo.

Exemplo:

Deadline > 30d → low
Deadline 7–30d → medium
Deadline 1–7d → high
Deadline < 24h → critical

Mas regras específicas do domínio poderão substituir os defaults.

12. Relevance

Nem todo risco interessa igualmente a todos os usuários.

O sistema deverá considerar:

user role
tenant
responsibility
department
location
entity ownership
workflow participation
current UI context
previous interaction

Exemplo:

Uma aprovação de Work Permit para a área de manutenção deverá possuir relevância maior para o responsável pela manutenção do que para um usuário administrativo sem relação com o processo.

13. Current UI Context

A camada deverá utilizar o Semantic UI Context do PRD-011.

Se o usuário estiver em:

Work Permit WP-10231
Tab: Components

um Attention Item relacionado à mesma Work Permit deverá receber um boost de relevância.

Isso permite que o agente diga:

“Enquanto você está analisando essa permissão, existe uma pendência importante relacionada a ela.”

14. Aggregation

Itens relacionados deverão ser agrupados.

Exemplo:

workers
training expirations
affected permits

Em vez de:

160 notifications

o usuário verá:

37 trabalhadores possuem treinamentos próximos do vencimento, afetando 82 permissões de trabalho.

15. Attention Group

interface AttentionGroup {
  groupId: string;

  tenantId: string;

  title: string;

  summary: string;

  priority: AttentionPriority;

  itemCount: number;

  entityRefs: EntityReference[];

  itemIds: string[];

  suggestedAction?: string;

  createdAt: string;
}

16. Grouping Rules

O agrupamento poderá utilizar:

same tenant
same entity
same worker
same Work Permit
same rule
same workflow
same risk
same time window
same responsible user
same causal chain

O Knowledge Graph poderá auxiliar na identificação de relações.

17. Causal Grouping

Esse será um recurso particularmente importante.

Considere:

Training Expiring
        ↓
Worker affected
        ↓
Work Permit affected
        ↓
Workflow created
        ↓
Approval pending

Não deverão existir cinco alertas independentes.

O sistema deverá entender que todos pertencem a uma mesma situação operacional.

Resultado:

“Renovação de treinamento está bloqueando a liberação de 3 Work Permits.”

18. Deduplication

A mesma situação não deverá aparecer repetidamente.

Chave:

tenantId
+
attentionType
+
entityRefs
+
ruleId
+
responsibleParty

O sistema deverá suportar:

deduplication window
cooldown
aggregation window

19. Suppression

O usuário ou política poderá suprimir determinados itens.

Exemplo:

“Não me avise novamente sobre esse treinamento até amanhã.”

Isso deverá criar uma configuração estruturada:

interface AttentionSuppression {
  suppressionId: string;

  tenantId: string;

  scope: "ITEM" | "ENTITY" | "RULE" | "TYPE";

  target: string;

  expiresAt: string;

  createdBy: string;
}

20. Segurança da Suppression

Suppression não poderá apagar uma obrigação de segurança.

Por exemplo:

CRITICAL compliance issue

não poderá ser simplesmente escondido pelo usuário.

Nesse caso:

User suppression
      ↓
Policy Engine
      ↓
DENY

21. Notification Policy

Cada Attention Item deverá passar por uma Notification Policy.

Attention
   ↓
Notification Policy
   ↓
Should notify?
   ↓
Which channel?
   ↓
When?
   ↓
Who?

22. Notification Channels

A arquitetura deverá suportar:

IN_APP
WEB_PUSH
EMAIL
MOBILE_PUSH
SMS
WEBHOOK
CHAT

O MVP poderá implementar somente:

IN_APP
EMAIL

mantendo a interface preparada para os demais.

23. Notification Preferences

O usuário poderá configurar preferências:

priority
channel
quiet hours
digest
frequency
domain

Exemplo:

notifications:
  high:
    channels:
      - IN_APP
      - EMAIL

  medium:
    channels:
      - IN_APP

  low:
    channels:
      - DIGEST

24. Quiet Hours

O sistema deverá suportar períodos em que notificações não críticas não sejam enviadas.

Exemplo:

22:00 → 07:00

Porém:

CRITICAL

poderá continuar sendo enviado caso a Policy Engine permita.

25. Digest

Itens de baixa prioridade poderão ser agrupados em um resumo.

Exemplo:

Resumo diário de Segurança — 01/09/2026

treinamentos próximos do vencimento
documentos pendentes
recomendações
workflow parado

Isso reduz drasticamente o ruído.

26. Escalation

Se uma situação não for tratada:

Attention
   ↓
T + 24h
   ↓
Not resolved
   ↓
Escalate

Exemplo:

Responsible
↓
Supervisor
↓
Manager
↓
Safety Administrator

27. Escalation Policy

interface EscalationPolicy {
  policyId: string;

  trigger: {
    after: string;
    condition: string;
  };

  levels: EscalationLevel[];
}

Cada nível deverá possuir:

recipient
delay
channel
condition

28. Human Decision Center

Além de notificações, deverá existir uma área central:

Agentic Decision Center

Ela deverá mostrar:

┌─────────────────────────────────────────┐
│ MINHAS DECISÕES                         │
├─────────────────────────────────────────┤
│ 🔴 3 críticas                           │
│ 🟠 7 importantes                        │
│ 🟡 12 aguardando revisão                │
├─────────────────────────────────────────┤
│ [Aprovar] [Rejeitar] [Revisar]          │
└─────────────────────────────────────────┘

29. Decision Card

Cada decisão deverá apresentar:

O QUE?
POR QUÊ?
IMPACTO?
EVIDÊNCIAS?
RISCO?
QUEM É AFETADO?
O QUE ACONTECE SE EU NÃO FIZER NADA?
QUAL A AÇÃO PROPOSTA?

Exemplo:

Aprovar liberação da WP-10231

Risco: Alto

Motivo: Todos os requisitos obrigatórios foram satisfeitos.

Impacto: Liberação de 4 trabalhadores.

Ação proposta: Aprovar.

Evidências: 8

Workflow: WP Lifecycle #8421

30. Human Decision

interface HumanDecision {
  decisionId: string;

  attentionId: string;

  userId: string;

  decision:
    | "APPROVE"
    | "REJECT"
    | "ACCEPT"
    | "DISMISS"
    | "REQUEST_CHANGES"
    | "DEFER";

  reason?: string;

  decidedAt: string;
}

Decisões relevantes deverão ser auditadas.

31. Decision Expiration

Uma decisão pendente poderá expirar.

Exemplo:

Approval valid for 4 hours

Depois:

EXPIRED

e uma nova avaliação deverá ser realizada.

Isso impede que uma decisão antiga seja utilizada sobre um estado que mudou.

32. Stale Decision Protection

Antes da execução:

Decision
+
Policy
+
Resource
+
Context

deverão ser revalidados.

Se o recurso mudou:

Decision → INVALID

O sistema deverá solicitar nova decisão quando necessário.

33. Natural Language Interaction

O Decision Center deverá funcionar também através do Agent.

Exemplos:

“Quais decisões estão pendentes?”

“Mostre só as críticas.”

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

“Tem alguma coisa bloqueando minhas Work Permits?”

“Aprovar todas as que não têm risco alto.”

A última instrução deverá ser tratada como operação potencialmente em lote e passar pelas proteções de Batch/Policy.

34. Contextual Attention

O agente poderá responder:

“Você está analisando a WP-10231. Há uma pendência de aprovação relacionada a ela.”

Esse comportamento será baseado em:

Current UI Context
+
Attention Store
+
Knowledge Graph
+
Conversation Context

35. Attention Inbox API

Deverá existir uma API conceitual:

GET /agent/attention

Filtros:

status
priority
type
entity
domain
assignedTo
createdAfter
dueBefore

Exemplo:

GET /agent/attention?status=NEW&priority=CRITICAL

A API deverá respeitar integralmente tenant isolation e authorization.

36. Attention Actions

As ações nunca deverão ser endpoints arbitrários.

Exemplo:

interface AttentionAction {
  actionId: string;

  attentionId: string;

  capabilityId: string;

  label: string;

  risk: RiskLevel;

  requiresConfirmation: boolean;
}

O capabilityId deverá apontar para o Capability Registry.

37. Relationship com Capability Registry

A arquitetura ficará:

Attention
   ↓
Suggested Action
   ↓
Capability Registry
   ↓
Policy Engine
   ↓
Execution Engine

Nunca:

Attention
   ↓
HTTP endpoint

38. Relationship com Workflow Engine

Uma atenção poderá apontar para:

workflowId

permitindo:

Open workflow
Pause workflow
Resume workflow
Approve step
Reject step
Cancel workflow

Cada ação deverá ser uma capability registrada.

39. Notification Reliability

O sistema deverá garantir:

notificationId
idempotencyKey
deliveryStatus
attempts
lastAttemptAt
providerResponse

Estados:

PENDING
SENT
DELIVERED
FAILED
RETRYING
EXPIRED

40. Retry

Falhas transitórias:

timeout
5xx
rate limit
network

poderão gerar retry.

Falhas permanentes:

invalid recipient
permission denied
invalid payload

não deverão ser repetidas indefinidamente.

41. Notification Outbox

Para garantir consistência:

Business Transaction
       ↓
Attention Created
       ↓
Notification Outbox
       ↓
Dispatcher
       ↓
Provider

O envio não deverá depender de uma transação HTTP síncrona.

42. Tenant Isolation

Todas as estruturas deverão conter:

tenantId

quando aplicável.

Não poderá ocorrer:

Tenant A
 ↓
Attention
 ↓
Notification
 ↓
Tenant B

Também deverá existir isolamento em:

cache;
filas;
aggregation;
digest;
analytics;
escalation;
preferences.

43. Privacy

Notificações poderão carregar informações sensíveis.

Portanto:

Sensitive Data
     ↓
Minimize
     ↓
Channel-specific representation

Exemplo:

No push:

“Uma decisão importante precisa da sua atenção.”

Em vez de:

“O trabalhador João da Silva possui determinada condição médica...”

O detalhe poderá ficar protegido dentro da aplicação autenticada.

44. Audit

Deverão existir eventos:

ATTENTION_CREATED
ATTENTION_GROUPED
ATTENTION_SUPPRESSED
ATTENTION_VIEWED
ATTENTION_ACKNOWLEDGED
ATTENTION_DISMISSED
NOTIFICATION_CREATED
NOTIFICATION_SENT
NOTIFICATION_FAILED
ESCALATION_TRIGGERED
DECISION_REQUESTED
DECISION_MADE
DECISION_EXPIRED

45. Metrics

Métricas principais:

Attention Items Created
Notifications Sent
Notifications Suppressed
Notification Delivery Rate
Attention Open Rate
Acknowledgement Rate
Decision Completion Rate
Decision SLA
Escalation Rate
Dismissal Rate
False Alert Rate
Alert Fatigue Rate
Average Time To Attention
Average Time To Decision

46. Attention Effectiveness

Uma métrica importante será:

Attention Effectiveness =
Actionable Items / Total Attention Items

O objetivo será aumentar:

Signal → Useful Attention

e reduzir:

Signal → Noise

47. Feedback

O usuário poderá informar:

Útil
Não é relevante
Já resolvido
Não deveria ter sido alertado
Preciso ser notificado antes

Esses eventos alimentarão o PRD-012.

Porém:

Feedback nunca deverá alterar automaticamente uma política de segurança.

48. Inteligência sobre Attention

O Agent poderá detectar padrões como:

“Você costuma resolver esse tipo de pendência imediatamente.”

ou:

“Essas 12 recomendações são relacionadas ao mesmo problema.”

Mas qualquer mudança comportamental relevante deverá passar pelo ciclo de avaliação e release.

49. Priority Learning

Futuramente, o sistema poderá aprender:

quais itens são ignorados
quais são resolvidos rapidamente
quais geram ações
quais são frequentemente rejeitados

Isso poderá melhorar o ranking.

Porém:

learned ranking
≠
authorization

O aprendizado poderá alterar ordenação, nunca permissões.

50. Cost Optimization

O sistema deverá evitar enviar notificações redundantes.

Exemplo:

10 signals
→ 1 Attention Group
→ 1 notification

em vez de:

10 signals
→ 10 notifications

Isso reduz:

custo;
processamento;
chamadas externas;
emails;
push;
carga cognitiva.

51. Performance

Objetivos:

Attention creation P95 < 100ms
Ranking P95 < 50ms
Deduplication P95 < 30ms
In-app inbox P95 < 150ms

Processamentos em massa deverão ser assíncronos.

52. First Vertical Slice

O primeiro domínio será:

Work Permit + Training Expiration

Cenário:

Training expires
       ↓
Event/Temporal Signal
       ↓
Risk
       ↓
Recommendation
       ↓
Attention Engine

Em vez de gerar dezenas de notificações:

1 Attention Group

Exemplo:

Treinamentos próximos do vencimento

12 trabalhadores possuem treinamentos que vencerão nos próximos 15 dias, afetando 23 Work Permits.

A ação:

[Revisar]

abrirá o contexto semântico correto.

53. Segundo cenário

Work Permit aguardando aprovação.

Workflow
   ↓
WAITING_APPROVAL
   ↓
Attention
   ↓
Decision Center

O responsável verá:

3 Work Permits aguardam sua aprovação.

Cada item terá:

[Revisar]
[Aprovar]
[Rejeitar]

As ações serão executadas através do Capability Registry.

54. Terceiro cenário — Escalation

Se uma aprovação ficar parada:

48h
 ↓
Escalation
 ↓
Supervisor

O supervisor receberá:

“A aprovação da WP-10231 está pendente há 48 horas.”

55. Critérios de Aceitação

Evidência parcial de implementação — 2026-09-04

Attention Item, score e occurrence inbox são separados de signal/notification e persistem deduplicação, agregação, prioridade e timeline tenant-safe. O runtime protege alerta crítico, expiração e decisão stale; escalonamento e notificação continuam policy-bound e não autorizam capability. Dados de ocorrência são minimizados e auditáveis.

Em 2026-09-04, recomendações proativas abertas passaram a ser projetadas de modo idempotente como ocorrências e Attention Items NOTICE/REVIEW_REQUIRED na fila humana proactive-review. O vínculo preserva tenant, severidade, evidência e dedupe, mas não envia notificação nem autoriza workflow, capability ou execução. Foram aprovados 20 testes focados de runtime proativo/Attention/rota e a pré-publicação do Worker (53 arquivos, 311 testes); o Worker foi publicado na versão c460faee-ec66-4e5c-845b-2fc6b08b5c11, com /health público saudável.

Em 2026-09-05, o gate de Attention Orchestration passou com 43 testes em 6 arquivos. O canário remoto comprovou 23 ocorrências de seis fontes, score 80/prioridade URGENT, roteamento delegado, template localizado, canais EMAIL e IN_APP, payload minimizado, token de ação one-time, lifecycle OPEN → ACKNOWLEDGED → IN_PROGRESS → ESCALATED → RESOLVED → CLOSED, dois níveis de escalonamento e reconciliação na versão 2. A execução permaneceu não autorizativa e o cleanup confirmou remainingRows:0.

Em 2026-09-06, a regressão atual de runtime, notificações, escalonamento, rotas e classificação de falhas de canário passou com 51 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. O estado permanece PARTIAL: outbox, roteamento e UI de escalonamento ainda precisam de cobertura completa.

56. Resultado arquitetural

Com o PRD-022, o Agentic Work passa a possuir uma cadeia completa:

┌─────────────────────────────────────────────┐
│ EVENT                                       │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│ SIGNAL                                      │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│ RISK                                        │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│ RECOMMENDATION                              │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│ ATTENTION ENGINE                            │
└──────────────────────┬──────────────────────┘
                       ▼
             ┌─────────┴─────────┐
             ▼                   ▼
      NOTIFICATION          HUMAN DECISION
             │                   │
             └─────────┬─────────┘
                       ▼
                  WORKFLOW
                       ▼
                 CAPABILITY
                       ▼
                    POLICY
                       ▼
                  EXECUTION
                       ▼
                 VERIFICATION
                       ▼
                    AUDIT

O resultado é importante: o Agentic Work deixa de ser apenas um agente conversacional que executa comandos e passa a funcionar como uma camada operacional contínua do sistema SST, capaz de observar situações, decidir quando a atenção humana é necessária e conduzir o processo até a resolução.

PRD-023 — Agentic Decision Intelligence & Risk Reasoning

O próximo PRD deverá avançar um nível acima.

Até aqui temos:

Event Fabric → percebe o que aconteceu;
Proactive Intelligence → identifica o que pode acontecer;
Attention Engine → decide o que merece atenção;
Decision Center → coloca a decisão diante do humano.

O próximo passo será estruturar como o Agentic Work raciocina sobre decisões complexas envolvendo múltiplos fatores, evidências, regras, riscos e alternativas.

O PRD-023 deverá criar o Decision Intelligence & Risk Reasoning Layer, responsável por:

Evidence
   ↓
Facts
   ↓
Relationships
   ↓
Rules
   ↓
Constraints
   ↓
Risk
   ↓
Alternatives
   ↓
Decision
   ↓
Recommendation

Com uma distinção fundamental:

O LLM poderá ajudar a raciocinar sobre alternativas, mas não será a autoridade final sobre regras, autorização, segurança ou compliance.

Esse componente será especialmente importante para situações SST em que não existe simplesmente um:

if X then Y

mas sim uma decisão baseada em múltiplas evidências, dependências, exceções, contexto operacional e consequências.

1. Objetivo​

2. Problema

3. Princípio fundamental

4. Arquitetura

5. Attention Item

6. Tipos

7. Status

8. Required Action

9. Atenção vs. Notificação

10. Attention Scoring

11. Urgency

12. Relevance

13. Current UI Context

14. Aggregation

15. Attention Group

16. Grouping Rules

17. Causal Grouping

18. Deduplication

19. Suppression

20. Segurança da Suppression

21. Notification Policy

22. Notification Channels

23. Notification Preferences

24. Quiet Hours

25. Digest

26. Escalation

27. Escalation Policy

28. Human Decision Center

29. Decision Card

30. Human Decision

31. Decision Expiration

32. Stale Decision Protection

33. Natural Language Interaction

34. Contextual Attention

35. Attention Inbox API

36. Attention Actions

37. Relationship com Capability Registry

38. Relationship com Workflow Engine

39. Notification Reliability

40. Retry

41. Notification Outbox

42. Tenant Isolation

43. Privacy

44. Audit

45. Metrics

46. Attention Effectiveness

47. Feedback

48. Inteligência sobre Attention

49. Priority Learning

50. Cost Optimization

51. Performance

52. First Vertical Slice

Work Permit + Training Expiration​

53. Segundo cenário

54. Terceiro cenário — Escalation

55. Critérios de Aceitação

Evidência parcial de implementação — 2026-09-04​

56. Resultado arquitetural

PRD-023 — Agentic Decision Intelligence & Risk Reasoning

1. Objetivo

Work Permit + Training Expiration

Evidência parcial de implementação — 2026-09-04