PRD-021 — Agentic Proactive Intelligence & Autonomous Operations
1. Objetivo
O Agentic Proactive Intelligence & Autonomous Operations será a camada responsável por permitir que o Agentic Work deixe de ser exclusivamente reativo e passe a identificar antecipadamente situações relevantes, avaliar riscos, propor ações e, quando autorizado, executar ações automaticamente.
A arquitetura deverá permitir que o agente responda não apenas:
“O que devo fazer?”
mas também:
“Existe alguma coisa que eu deveria saber ou fazer agora?”
e:
“Existe algum problema futuro que posso evitar?”
O sistema deverá, entretanto, manter uma fronteira rígida:
Ser proativo não significa ter liberdade arbitrária para agir.
Toda ação proativa deverá passar pelos mesmos mecanismos de:
Policy → Capability → Authorization → Execution → Verification → Audit
já definidos nos PRDs anteriores.
2. Motivação
O SST possui inúmeras situações que podem ser identificadas antes de se transformarem em problemas.
Exemplos:
- treinamento obrigatório vencendo;
- exame ocupacional próximo do vencimento;
- trabalhador sem treinamento necessário para determinado risco;
- permissão de trabalho que perderá validade;
- documento obrigatório ausente;
- equipamento próximo da manutenção;
- requisito legal alterado;
- risco identificado em determinado ambiente;
- aprovação pendente há vários dias;
- workflow parado;
- tarefa atrasada;
- inconsistência entre registros;
- excesso de permissões abertas;
- determinada condição operacional recorrente.
O modelo tradicional espera o usuário perguntar.
O Agentic Work deverá permitir:
Evento
↓
Análise
↓
Identificação de situação futura
↓
Avaliação de risco
↓
Política
↓
Recomendação
↓
Aprovação, se necessária
↓
Workflow
↓
Capability
↓
Execução
↓
Verificação
3. Princípios fundamentais
3.1 Proatividade não é autonomia irrestrita
O agente pode:
- detectar;
- analisar;
- recomendar;
- preparar;
- solicitar aprovação;
- executar ações explicitamente autorizadas.
Não pode:
- inventar ações;
- alterar políticas;
- alterar suas próprias permissões;
- ignorar regras;
- contornar aprovação;
- executar operações não registradas no Capability Registry.
4. Reativo vs. Proativo
4.1 Modelo reativo
Usuário
↓
Comando
↓
Intent
↓
Capability
↓
Execução
Exemplo:
“Mostre os treinamentos vencendo.”
4.2 Modelo proativo
Sistema
↓
Sinal
↓
Análise
↓
Risco
↓
Recomendação
↓
Ação
Exemplo:
“Existem 37 permissões de trabalho vinculadas a trabalhadores cujo treinamento obrigatório vencerá nos próximos 15 dias.”
O sistema pode então:
- identificar os trabalhadores;
- identificar os treinamentos;
- identificar as permissões afetadas;
- calcular o impacto;
- avaliar as políticas;
- gerar uma recomendação;
- criar um workflow;
- solicitar aprovação;
- executar ações autorizadas.
5. Arquitetura
A arquitetura deverá utilizar os componentes já definidos:
┌─────────────────────┐
│ Event Fabric │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Signal Detection │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Evidence Collector │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Risk Engine │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Policy Engine │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Recommendation │
│ Engine │
└──────────┬──────────┘
│
┌──────────┴──────────┐
│ │
▼ ▼
Human Approval Autonomous Action
│ │
└──────────┬──────────┘
▼
┌─────────────────────┐
│ Workflow Engine │
└──────────┬──────────┘
▼
┌─────────────────────┐
│ Capability Runtime │
└──────────┬──────────┘
▼
┌─────────────────────┐
│ Verification │
└─────────────────────┘
6. Signal Detection Engine
O Signal Detection Engine identifica situações que podem exigir atenção.
Um sinal não é necessariamente um problema.
Exemplo:
Training expires in 30 days
é um sinal.
Depois da análise pode se transformar em:
HIGH_RISK_OPERATIONAL_SITUATION
7. Modelo de Signal
interface ProactiveSignal {
signalId: string;
type: string;
tenantId: string;
source: SignalSource;
occurredAt: string;
detectedAt: string;
entity?: {
type: string;
id: string;
};
severity: SignalSeverity;
confidence: number;
horizon?: {
startsAt?: string;
expectedAt?: string;
expiresAt?: string;
};
evidenceRefs: string[];
metadata: Record<string, unknown>;
}
8. Tipos de sinais
O sistema deverá suportar inicialmente:
EVENT
TEMPORAL
THRESHOLD
STATE_CHANGE
PATTERN
ANOMALY
EXPIRATION
DEADLINE
WORKFLOW_STALLED
COMPLIANCE
DEPENDENCY
RISK
USER_BEHAVIOR
SYSTEM
9. Sinais temporais
Um dos mecanismos mais importantes será a detecção temporal.
Exemplo:
training.expirationDate <= now + 15 days
Outro exemplo:
workPermit.validUntil <= now + 24 hours
Outro:
approval.pendingDuration >= 48 hours
Essas regras deverão ser executadas sem LLM.
10. Temporal Rules
Uma regra poderá ser definida declarativamente:
id: training.expiration.15d
entity: training
condition:
field: expirationDate
operator: within
value: 15d
severity: medium
action:
type: PROACTIVE_RECOMMENDATION
cooldown: 24h
11. Fontes de sinais
O Signal Engine poderá consumir:
11.1 Event Fabric
Eventos:
TrainingCompleted
TrainingExpired
WorkPermitCreated
WorkPermitApproved
WorkPermitReleased
WorkPermitCompleted
11.2 Dados de negócio
Consultas periódicas.
11.3 Workflow Engine
Exemplo:
WorkflowWaitingTooLong
WorkflowFailed
WorkflowDeadlineApproaching
11.4 Scheduler
Para situações temporais.
11.5 Knowledge Base
Alterações em:
- requisitos;
- procedimentos;
- documentação;
- regras.
11.6 Sistemas externos
Quando integrações estiverem disponíveis.
12. Evidence Model
Nenhuma recomendação importante deverá surgir apenas de uma inferência sem evidência.
Deverá existir uma estrutura:
interface Evidence {
evidenceId: string;
tenantId: string;
type: string;
source: string;
entity?: {
type: string;
id: string;
};
timestamp: string;
value?: unknown;
confidence?: number;
knowledgeVersion?: string;
metadata?: Record<string, unknown>;
}
Exemplo:
Evidence #1
Training: NR-10
Worker: EMP-104
Expiration: 2026-09-15
Evidence #2
Worker EMP-104
Work Permit: WP-10231
Evidence #3
WP-10231
Required training: NR-10
O sistema então consegue construir:
EMP-104
│
├── NR-10 expires
│
└── WP-10231 requires NR-10
13. Risk Engine
O Risk Engine transforma sinais em avaliação de risco.
A avaliação deverá considerar:
Severity
×
Probability
×
Impact
×
Time Horizon
×
Scope
×
Business Criticality
O resultado deverá ser estruturado.
interface RiskAssessment {
riskId: string;
score: number;
level: "LOW" | "MEDIUM" | "HIGH" | "CRITICAL";
probability?: number;
impact?: number;
urgency?: number;
confidence: number;
evidenceRefs: string[];
factors: RiskFactor[];
evaluatedAt: string;
}
14. Risco não é fato
O sistema deverá distinguir claramente:
FACT
PREDICTION
INFERENCE
RECOMMENDATION
Exemplo:
Fato
O treinamento vence em 15 dias.
Inferência
Existem permissões vinculadas a esse treinamento.
Predição
Se não houver renovação, essas permissões poderão ficar inválidas.
Recomendação
Iniciar processo de renovação.
Essa distinção será obrigatória na interface e nos registros de auditoria.
15. Time Horizon
O sistema deverá considerar horizontes temporais:
IMMEDIATE < 24h
SHORT_TERM 1–7d
MEDIUM_TERM 8–30d
LONG_TERM > 30d
Isso permitirá priorizar situações.
Exemplo:
| Situação | Horizonte | Prioridade |
|---|---|---|
| Permissão expira em 2h | Immediate | Critical |
| Treinamento vence em 5 dias | Short | High |
| Documento vence em 25 dias | Medium | Medium |
| Renovação futura em 90 dias | Long | Low |
16. Confidence Score
O sistema deverá separar:
Risk Score
de:
Confidence
Exemplo:
Risk: 95
Confidence: 99%
é diferente de:
Risk: 95
Confidence: 52%
O segundo caso deverá normalmente resultar em:
REVIEW_REQUIRED
e não em ação automática.
17. Recommendation Engine
Depois da avaliação de risco, o sistema deverá gerar uma recomendação.
interface ProactiveRecommendation {
recommendationId: string;
tenantId: string;
title: string;
description: string;
priority: "LOW" | "MEDIUM" | "HIGH" | "CRITICAL";
riskAssessmentId: string;
evidenceRefs: string[];
affectedEntities: EntityReference[];
suggestedCapabilities: string[];
suggestedWorkflow?: string;
autonomyLevel: AutonomyLevel;
requiresApproval: boolean;
expiresAt?: string;
status:
| "NEW"
| "VIEWED"
| "ACCEPTED"
| "REJECTED"
| "EXPIRED"
| "EXECUTED";
}
18. Recomendações não são ações
Este é um princípio importante.
Uma recomendação:
“Renovar treinamento de EMP-104”
não significa que o sistema está autorizado a fazê-lo.
O fluxo será:
Recommendation
↓
Policy Evaluation
↓
Capability Discovery
↓
Authorization
↓
Approval?
↓
Execution
19. Autonomy Levels
Deverão existir níveis explícitos de autonomia.
enum AutonomyLevel {
OBSERVE,
INFORM,
RECOMMEND,
PREPARE,
REQUIRE_APPROVAL,
AUTO_EXECUTE
}
OBSERVE
Apenas registra.
INFORM
Notifica o usuário.
RECOMMEND
Sugere uma ação.
PREPARE
Prepara um workflow ou dados, sem executar mutação.
REQUIRE_APPROVAL
Prepara e aguarda aprovação.
AUTO_EXECUTE
Executa automaticamente quando todas as políticas permitirem.
20. Autonomia por risco
Configuração padrão:
| Risco | Autonomia máxima |
|---|---|
| LOW | AUTO_EXECUTE |
| MEDIUM | PREPARE |
| HIGH | REQUIRE_APPROVAL |
| CRITICAL | HUMAN_REVIEW |
Isso será apenas o default.
A Policy Engine poderá estabelecer regras mais restritivas.
21. Autonomous Action Boundary
Uma operação só poderá ser executada automaticamente se:
Capability = ACTIVE
AND
Policy = ALLOW
AND
User/Tenant authorization = VALID
AND
Resource state = VALID
AND
Risk <= autonomy threshold
AND
No approval required
AND
Context = CURRENT
AND
Idempotency = VALID
AND
Verification = AVAILABLE
Caso qualquer condição falhe:
NO AUTO EXECUTION
22. Human Approval
Quando necessário:
Recommendation
↓
Approval Request
↓
Human
↓
Approve / Reject
A aprovação deverá estar vinculada a:
tenantId
userId
recommendationId
workflowId
capabilityId
resource
risk
policyVersion
expiration
Uma aprovação nunca poderá ser genérica.
23. Blast Radius
Operações proativas deverão calcular o impacto potencial.
Exemplo:
1 worker
3 permits
é diferente de:
1.245 workers
3.812 permits
O sistema deverá classificar:
SINGLE_RESOURCE
SMALL_BATCH
LARGE_BATCH
TENANT_WIDE
SYSTEM_WIDE
Quanto maior o blast radius, maior deverá ser o nível de proteção.
24. Batch Protection
Por exemplo:
maxAutoExecution:
resources: 10
Se uma recomendação afetar:
37 resources
ela não poderá ser automaticamente executada.
Deverá entrar em:
REVIEW_REQUIRED
25. Suppression e Deduplication
Sistemas proativos podem rapidamente gerar milhares de alertas.
Isso não será permitido.
Uma mesma situação deverá possuir uma chave de deduplicação:
tenantId
+
signalType
+
entityType
+
entityId
+
ruleId
Exemplo:
tenant-1
training.expiration
worker
EMP-104
15d
26. Cooldown
Uma recomendação poderá possuir:
cooldown: 24h
Durante esse período, sinais equivalentes não gerarão novas notificações.
27. Alert Fatigue
O sistema deverá acompanhar:
alerts generated
alerts viewed
alerts ignored
alerts dismissed
alerts accepted
alerts acted upon
false positives
Se uma regra gerar continuamente recomendações ignoradas, ela deverá ser sinalizada para revisão.
28. Priorização
A prioridade deverá considerar:
Risk
Urgency
Confidence
Blast Radius
Business Impact
Time Horizon
User Relevance
Uma função inicial:
Priority =
Risk ×
Urgency ×
Confidence ×
BusinessImpact
O cálculo poderá evoluir posteriormente.
29. Notification Channels
O mecanismo deverá ser desacoplado do canal.
interface NotificationChannel {
send(notification: Notification): Promise<void>;
}
Possíveis canais:
IN_APP
EMAIL
PUSH
WEBHOOK
CHAT
SMS
O PRD não obriga todos os canais na primeira versão.
30. Proactive Workflow
Quando uma situação exigir vários passos, deverá ser criado um Workflow.
Exemplo:
Training expiring
↓
Find affected workers
↓
Find affected permits
↓
Evaluate policy
↓
Create renewal tasks
↓
Notify responsible users
↓
Wait
↓
Training renewed
↓
Revalidate permits
O Workflow Engine do PRD-019 será utilizado.
31. Scheduling
O sistema deverá suportar verificações periódicas.
Exemplo:
Every day at 02:00
executar:
training expiration detection
document expiration detection
workflow timeout detection
permit validity detection
A arquitetura deverá permanecer compatível com Cloudflare Workers.
Não deverá depender de um processo permanentemente ativo.
32. Tenant Configuration
Cada tenant poderá configurar:
enabled proactive rules
thresholds
notification preferences
autonomy level
business hours
escalation rules
risk tolerance
cooldowns
Porém:
Tenant configuration nunca poderá reduzir uma regra de segurança global.
Exemplo:
Global Policy:
CRITICAL → human approval
Um tenant não poderá configurar:
CRITICAL → auto execute
33. LLM Usage
O LLM deverá ser utilizado apenas quando existir valor real.
Determinístico
expiration
threshold
deadline
state
dependency
known relationship
não requer LLM.
LLM pode ser utilizado para:
- interpretar situações complexas;
- correlacionar evidências não estruturadas;
- resumir riscos;
- gerar explicações;
- produzir recomendações em cenários complexos.
Mesmo nesses casos:
LLM
↓
Structured Recommendation
↓
Schema Validation
↓
Policy Engine
Nunca:
LLM → API
34. Knowledge Graph Integration
O HAG existente deverá ser utilizado para descobrir relações.
Exemplo:
Training
↓ REQUIRES
Work Permit
↓ BELONGS_TO
Worker
↓ BELONGS_TO
Company
Isso permite descobrir impacto sem depender exclusivamente de consultas semânticas.
O Graph Expansion deverá permanecer limitado para evitar explosão combinatória.
35. Explanation Engine
Toda recomendação relevante deverá poder responder:
Por que estou recebendo isso?
Exemplo:
Treinamento NR-10 de João vence em 15/09/2026.
A permissão WP-10231 exige esse treinamento.
A permissão está ativa e permanece válida até 20/09/2026.
Por isso existe risco de interrupção operacional caso o
treinamento não seja renovado.
A explicação deverá apresentar:
Facts
Evidence
Rules
Risk
Recommendation
Não deverá expor chain-of-thought interno.
36. Auditoria
Toda operação proativa deverá gerar eventos de auditoria.
Exemplo:
PROACTIVE_SIGNAL_DETECTED
RISK_ASSESSED
RECOMMENDATION_CREATED
RECOMMENDATION_VIEWED
RECOMMENDATION_ACCEPTED
RECOMMENDATION_REJECTED
AUTO_EXECUTION_ALLOWED
AUTO_EXECUTION_BLOCKED
APPROVAL_REQUESTED
APPROVAL_GRANTED
PROACTIVE_WORKFLOW_STARTED
PROACTIVE_ACTION_EXECUTED
PROACTIVE_ACTION_VERIFIED
37. Segurança
O agente proativo deverá operar com:
Zero Trust
+
Tenant Isolation
+
RBAC
+
ABAC
+
Capability Registry
+
Policy Engine
+
Audit
Nunca deverá assumir:
“Como o sistema descobriu o problema, ele pode corrigi-lo.”
Descoberta ≠ autorização.
38. Fail Safe
Se qualquer componente crítico estiver indisponível:
Risk Engine unavailable
Policy Engine unavailable
Authorization unavailable
Capability Registry unavailable
Verification unavailable
ações automáticas deverão ser bloqueadas.
O sistema poderá continuar:
detectando
registrando
informando
mas não executando mutações.
39. Kill Switch
Deverá existir um mecanismo de emergência:
AUTONOMOUS_OPERATIONS_ENABLED = false
Isso deverá desabilitar:
AUTO_EXECUTE
sem necessariamente desabilitar:
OBSERVE
INFORM
RECOMMEND
Deverá ser auditado.
40. Continuous Evaluation
As regras proativas deverão ser avaliadas continuamente.
Métricas:
Detection Precision
Detection Recall
False Positive Rate
False Negative Rate
Recommendation Acceptance Rate
Recommendation Rejection Rate
Auto Execution Success Rate
Rollback Rate
Alert Fatigue Rate
Average Lead Time
Risk Prediction Accuracy
41. Operational Memory Integration
O PRD-012 deverá receber os resultados das operações.
Exemplo:
Rule:
training.expiration.15d
Resultados:
1,000 detections
950 valid
50 false positives
O sistema poderá recomendar:
“Essa regra apresenta 5% de falsos positivos.”
Mas não poderá alterar automaticamente a regra.
A alteração deverá passar por:
Suggestion
→ Human Review
→ Evaluation
→ Release
42. Observabilidade
Cada ciclo deverá possuir:
traceId
signalId
riskId
recommendationId
workflowId
executionId
tenantId
Permitindo reconstruir:
Signal
↓
Evidence
↓
Risk
↓
Policy
↓
Recommendation
↓
Approval
↓
Workflow
↓
Capability
↓
API
↓
Verification
43. Performance
O caminho determinístico deverá ser extremamente rápido.
Objetivos iniciais:
Signal evaluation P95 < 100ms
Risk evaluation P95 < 50ms
Policy evaluation P95 < 30ms
Recommendation generation P95 < 100ms
Operações agendadas poderão processar grandes volumes de forma assíncrona.
O sistema não deverá bloquear a aplicação principal.
44. Escalabilidade
Para milhares de tenants:
Tenant
↓
Tenant-aware signal evaluation
↓
Shared infrastructure
Não deverá existir uma infraestrutura dedicada por tenant sem necessidade.
As principais chaves de particionamento deverão incluir:
tenantId
entityType
entityId
signalType
ruleId
45. Cache
Poderão ser armazenados em cache:
rules
tenant configuration
policy decisions
entity relationships
risk calculations
deduplication state
recommendation state
Nunca deverá ser permitido cache compartilhado entre tenants quando o conteúdo for tenant-specific.
46. Exemplo completo
Imagine:
Training NR-10
Worker: João
Expiration: 15/09/2026
Current date: 01/09/2026
O Signal Engine detecta:
training.expiration < 15 days
↓
Encontra:
Worker EMP-104
↓
HAG encontra:
EMP-104
└── WP-10231
└── requires NR-10
↓
Risk Engine:
Risk = HIGH
Confidence = 99%
↓
Policy:
HIGH → REQUIRE_APPROVAL
↓
Recommendation:
“O treinamento NR-10 de João vencerá em 14 dias e afeta a permissão WP-10231.”
↓
Usuário recebe:
Revisar situação
↓
Workflow:
Find affected permits
↓
Create renewal task
↓
Notify responsible user
↓
Wait for renewal
↓
Revalidate permit
Quando o treinamento for renovado:
TrainingCompleted
↓
Event Fabric
↓
Workflow
↓
Revalidate WP-10231
↓
Verification
↓
Workflow completed
Todo o processo fica auditável.
47. Primeira Vertical Slice
A primeira implementação deverá utilizar o domínio:
Work Permit + Training
Regra
Quando um treinamento obrigatório associado a uma Work Permit
estiver a menos de 15 dias do vencimento:
- detectar;
- identificar trabalhador;
- identificar Work Permits afetadas;
- calcular risco;
- verificar política;
- gerar recomendação;
- solicitar aprovação;
- iniciar workflow;
- executar apenas capabilities autorizadas;
- verificar resultado;
- registrar auditoria.
48. Critérios de Aceitação
A implementação será considerada concluída quando:
- Event Fabric puder alimentar sinais proativos.
- Regras temporais puderem ser configuradas sem LLM.
- Sinais possuírem tenant isolation.
- Evidências forem armazenadas e referenciáveis.
- Risk Engine produzir avaliação estruturada.
- Confidence for separada de Risk.
- Recommendation Engine gerar recomendações.
- Recomendações não puderem executar APIs diretamente.
- Toda ação passar pela Policy Engine.
- Autonomy Level estiver explicitamente definido.
- Blast radius for calculado.
- Batch protection estiver ativo.
- Deduplicação e cooldown estiverem implementados.
- Aprovação estiver vinculada à operação específica.
- Workflows puderem ser iniciados por recomendações.
- Ações automáticas puderem ser desabilitadas por kill switch.
- Operações críticas falhem fechando.
- Todas as ações forem auditadas.
- Explicações apresentem evidências.
- LLM não possa executar capabilities diretamente.
- Regras possam ser avaliadas posteriormente.
- Primeira vertical slice de Training → Work Permit esteja funcionando ponta a ponta.
Evidência parcial de implementação — 2026-09-04
O runtime recebe sinais idempotentes do Event Fabric, exige evidência/confiança/autonomia explícitas e persiste avaliação/recomendação tenant-safe. Regras temporais são determinísticas, deduplicação/cooldown limitam repetição e recomendações permanecem não executáveis, sujeitas a Policy, approval, kill switch e audit. Falha de evidência é isolada e não é convertida em ação segura.
Em canário remoto de 2026-09-06, uma meta de conformidade avançou de AT_RISK (50%) para ACHIEVED (100%) após uma task de treinamento delegada e um replanejamento. O fluxo gravou GOAL_CREATED, GOAL_ACTIVATED, GOAL_AT_RISK, TASK_ASSIGNED, TASK_STATE_CHANGED, TASK_COMPLETED e GOAL_ACHIEVED; preservou isolamento tenant, não concedeu autoridade de execução e removeu os dados sintéticos (remainingRows: 0).
Em 2026-09-04, o Event Fabric passou a aceitar agentic.proactive-signal: o consumidor valida tipo, severidade, confiança, evidências e escopo tenant antes de persistir um sinal PENDING idempotente. A ponte não chama capability, workflow ou ação; ela apenas entrega o sinal ao runtime de análise governada. Foram aprovados 25 testes focados de Queue/runtime/rota e a pré-publicação do Worker (53 arquivos, 311 testes); o Worker foi publicado na versão b5f7cd10-da13-4702-83a9-302930459d25, com /health público saudável.
Em 2026-09-05, as suítes de Proactive Intelligence passaram com 30 testes em 5 arquivos. O canário de Risk Prevention comprovou, em tenant isolado, hazard, registry, sinal, duas avaliações, aceitação, Attention, Decision e intervenção preventiva somente planejada, com negação anônima e authorizesExecution:false. O canário LMS remoto já comprovou a vertical slice Training → Work Permit após autorização e confirmação externa. O catálogo amplo de detectores permanece como expansão futura, sem reduzir os controles certificados.
Em 2026-09-06, a regressão atual de runtime, rota e ações de recomendação passou com 5 testes, e o typecheck do Agent passou novamente. O health público do Worker confirmou runtime e bindings. O estado permanece PARTIAL pela execução autorizada pós-aprovação e pelo catálogo amplo de detectores.
49. Resultado arquitetural
Com o PRD-021, o Agentic Work passa a ter três formas de operação:
REACTIVE
Usuário → Agente → Ação
PROACTIVE
Evento/Sinal → Agente → Recomendação → Ação
AUTONOMOUS
Evento/Sinal → Risco → Política → Capability → Execução
A terceira modalidade só existe quando explicitamente autorizada pela arquitetura de segurança.
Isso cria uma distinção fundamental:
O agente pode perceber continuamente o que está acontecendo, mas só pode agir dentro dos limites que o sistema determinou.
PRD-022 — Agentic Attention, Notification & Human Decision Center
O próximo componente deverá resolver um problema criado diretamente pela proatividade:
Se o sistema começar a perceber tudo, como garantir que o usuário receba apenas aquilo que realmente precisa da atenção dele?
O PRD-022 deverá criar uma camada de Attention Management, centralizando:
- recomendações;
- aprovações;
- alertas;
- exceções;
- tarefas pendentes;
- riscos;
- escalonamentos;
- decisões humanas;
- notificações;
- prioridades;
- agrupamento de eventos relacionados;
- supressão de ruído;
- inbox operacional do agente.
A ideia será transformar dezenas ou centenas de sinais técnicos em algo muito mais útil:
┌────────────────────────────────────────────┐
│ AGENT ATTENTION CENTER │
├────────────────────────────────────────────┤
│ │
│ 🔴 3 decisões críticas │
│ │
│ 🟠 8 situações de alto risco │
│ │
│ 🟡 17 recomendações │
│ │
│ 🔵 5 processos aguardando terceiros │
│ │
│ ⚪ 42 itens agrupados automaticamente │
│ │
└────────────────────────────────────────────┘
E, principalmente, o sistema deverá evoluir de:
“Tenho 37 alertas.”
para:
“Existem 3 situações que realmente precisam da sua atenção agora.”
Esse será o foco do PRD-022 — Agentic Attention, Notification & Human Decision Center.