Skip to main content

PRD-020 — Agentic Event Fabric & Reactive Architecture

1. Objetivo​

Criar uma camada de eventos transversal para o Agentic Work, permitindo que mudanças relevantes no sistema possam disparar automaticamente:

  • workflows;
  • capabilities;
  • notificações;
  • reavaliações;
  • tarefas;
  • aprovações;
  • análises;
  • ações agentic controladas.

O objetivo é transformar o Agentic Work de um sistema predominantemente request-driven em uma arquitetura request-driven + event-driven.

2. Motivação

Hoje:

Usuário
   ↓
Comando
   ↓
Agente
   ↓
Ação

Com o Event Fabric:

Usuário ────────────────┐
                       ▼
                    Agentic
                       │
                       ▼
                 Event Fabric
                       ▲
                       │
Sistema ───────────────┘

O sistema poderá reagir a acontecimentos sem que o usuário precise iniciar uma conversa.

3. Exemplos SST

Treinamento vencido​

TrainingExpired
      ↓
Find affected employees
      ↓
Find active permits
      ↓
Evaluate policy
      ↓
Create review workflow

Permissão aprovada​

WorkPermitApproved
      ↓
Continue workflow
      ↓
Release permit

Mudança de risco​

RiskChanged
      ↓
Find affected permits
      ↓
Reevaluate controls
      ↓
Create review task

Documento anexado​

DocumentUploaded
      ↓
Validate document
      ↓
Continue workflow

4. Princípio Fundamental

Eventos são fatos, não comandos.

Evento:

WorkPermitApproved

não significa:

executeRelease()

Ele significa:

“Uma permissão foi aprovada.”

A decisão sobre o que fazer com esse fato pertence ao:

Policy
Workflow
Capability

5. Arquitetura

                 BUSINESS SYSTEMS
                       │
                       ▼
                Event Producers
                       │
                       ▼
                ┌──────────────┐
                │ Event Fabric │
                └──────────────┘
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
         Workflow    Policy    Analytics
         Engine      Engine      Engine
             │         │
             └────┬────┘
                  ▼
             Agentic Runtime
                  │
          ┌───────┴────────┐
          ▼                ▼
      Capability         Human
       Execution        Approval

6. Event Envelope

Todo evento deverá possuir um envelope padronizado.

interface AgentEvent<T = unknown> {
  eventId: string;

  eventType: string;

  eventVersion: string;

  occurredAt: string;

  tenantId: string;

  source: EventSource;

  actor?: Principal;

  entity?: EntityReference;

  correlationId?: string;

  causationId?: string;

  payload: T;

  metadata?: Record<string, unknown>;
}

7. Event Identity

Cada evento deverá possuir:

eventId

globalmente único.

Isso permitirá:

  • deduplicação;
  • idempotência;
  • auditoria;
  • replay.

8. Event Version

Eventos deverão ser versionados:

WorkPermitApproved.v1
WorkPermitApproved.v2

Mudanças incompatíveis deverão gerar nova versão.

9. Tenant Boundary

Todo evento deverá possuir:

tenantId

exceto eventos explicitamente classificados como:

GLOBAL

Mesmo eventos globais deverão ser filtrados antes de produzir ações tenant-scoped.

10. Event Scope

Classificação:

GLOBAL
TENANT
USER
RESOURCE
WORKFLOW

Exemplo:

PlatformMaintenance
→ GLOBAL

WorkPermitApproved
→ TENANT

UserPreferenceChanged
→ USER

11. Event Producers

Eventos poderão ser produzidos por:

Business API
Workflow Engine
Approval Engine
UI
Capability Runtime
External Integration
Scheduled Job
System

12. Business Events

Priorizar eventos semânticos.

Evitar:

POST /api/workpermit/123

como evento.

Preferir:

WorkPermitCreated
WorkPermitSubmitted
WorkPermitApproved
WorkPermitReleased
WorkPermitCancelled
WorkPermitCompleted

13. Domain Event Registry

Criar um registro formal:

interface EventDefinition {
  eventType: string;

  version: string;

  domain: string;

  description: string;

  scope: "GLOBAL" | "TENANT" | "USER" | "RESOURCE";

  schema: JSONSchema;

  source: string;

  sensitivity: DataSensitivity;

  replayable: boolean;
}

14. Event Schema

Cada evento deverá possuir JSON Schema.

Exemplo:

WorkPermitApproved.v1

deverá definir exatamente:

permitId
approvedBy
approvedAt
tenantId

e seus tipos.

15. Event Catalog

O Agentic Manifest deverá eventualmente incluir:

events

Além de:

capabilities
policies
knowledge
ui

16. Event Routing

O Event Fabric deverá encaminhar eventos somente para consumidores interessados.

WorkPermitApproved
        │
        ├── Workflow Engine
        ├── Notification
        ├── Audit
        └── Analytics

17. Subscription

Um consumidor poderá declarar:

interface EventSubscription {
  subscriptionId: string;

  eventTypes: string[];

  tenantScope: TenantScope;

  filter?: EventFilter;

  handler: string;

  enabled: boolean;
}

18. Event Filter

Exemplo:

eventType = WorkPermitApproved
AND
permit.status = APPROVED

Filtros deverão ser determinísticos sempre que possível.

19. Agentic Trigger

O workflow poderá declarar:

trigger:
  type: EVENT
  eventType: WorkPermitApproved.v1

20. Event → Workflow

Fluxo:

Event
 ↓
Subscription
 ↓
Policy
 ↓
Workflow Instance

O evento não deverá executar diretamente código arbitrário.

21. Event → Capability

Em casos específicos:

Event
 ↓
Policy
 ↓
Capability

Mas o padrão preferencial deverá ser:

Event
 ↓
Workflow
 ↓
Capability

porque o workflow oferece:

  • estado;
  • retry;
  • audit;
  • compensação;
  • espera;
  • aprovação.

22. Reactive Agent

O agente poderá ser acionado por evento.

Exemplo:

TrainingExpired
       ↓
Policy
       ↓
Agentic Workflow
       ↓
Analyze impacted permits

O agente não deverá simplesmente receber:

“Faça alguma coisa.”

Ele receberá um evento estruturado.

23. Event Context

O runtime deverá criar:

interface EventExecutionContext {
  event: AgentEvent;

  tenantContext: TenantContext;

  securityPrincipal?: Principal;

  workflowContext?: WorkflowContext;

  knowledgeVersion: string;

  releaseId: string;
}

24. System Actor

Eventos automáticos podem não ter usuário humano.

Nesse caso:

actor.type = SYSTEM

ou:

actor.type = AGENT

dependendo da origem.

25. Human Attribution

Mesmo uma ação automática deverá registrar:

triggerEvent
workflow
policy
capability
system/agent identity

Isso permite responder:

Por que o agente fez isso?

26. Causation

Eventos deverão manter:

causationId

Exemplo:

WorkPermitApproved
      ↓
causes
      ↓
WorkPermitReleased

Assim é possível reconstruir causalidade.

27. Correlation

Eventos relacionados ao mesmo processo terão:

correlationId

Exemplo:

workflow-982

Todos os eventos daquele workflow podem compartilhar a correlação.

28. Event Chain

Exemplo:

TrainingExpired
       │
       ▼
ReviewRequired
       │
       ▼
ApprovalRequested
       │
       ▼
ReviewApproved
       │
       ▼
PermitSuspended

A cadeia deverá ser reconstruível.

29. Ordering

O sistema deverá garantir ordenação quando ela for necessária dentro de um determinado contexto.

Exemplo:

WorkPermitCreated
WorkPermitSubmitted
WorkPermitApproved

Não permitir que:

Approved

seja processado antes de:

Submitted

quando a semântica do domínio exigir essa ordem.

30. At-Least-Once Delivery

O design deverá assumir que eventos podem ser entregues mais de uma vez.

Portanto:

Consumidores devem ser idempotentes.

31. Deduplication

Um consumidor poderá armazenar:

eventId
consumerId
processedAt

Antes de processar:

alreadyProcessed?

Se sim:

ACK

sem repetir a operação.

32. Exactly Once

Não depender de “exactly once” como premissa arquitetural.

O sistema deverá alcançar comportamento efetivamente idempotente mesmo sob:

duplicate
retry
replay
timeout
worker restart

33. Retry

Eventos com falha poderão ser reprocessados.

EVENT
 ↓
CONSUMER FAILURE
 ↓
RETRY
 ↓
RETRY
 ↓
DLQ

34. Dead Letter Queue

Eventos não processáveis deverão ir para:

Dead Letter

com:

eventId
consumer
attempts
error
lastAttempt

35. Poison Event

Um evento estruturalmente inválido ou que sempre falha não deverá bloquear os demais.

Deverá ser isolado.

36. Backpressure

Se um produtor gerar:

10.000 events/sec

e consumidor suportar:

1.000 events/sec

o sistema deverá utilizar:

queue
batching
backpressure
rate limiting

em vez de tentar processar tudo simultaneamente.

37. Priority

Eventos críticos poderão ter prioridade.

Exemplo:

SafetyCriticalEvent

pode ter prioridade maior que:

AnalyticsEvent

38. Event Retention

Nem todo evento precisa ser mantido indefinidamente.

Políticas poderão definir:

short retention
long retention
archive
immutable audit

Eventos relevantes para compliance poderão ter retenção superior.

39. Event Storage

O Event Fabric deverá separar:

Hot event processing
Long-term event archive
Audit

Não transformar um único storage em solução para tudo.

40. Replay

Eventos deverão poder ser reproduzidos em ambientes controlados.

Event History
     ↓
Replay
     ↓
Sandbox

Nunca executar replay diretamente em produção sem proteção explícita.

41. Replay Security

Replay deverá possuir:

mode:
DRY_RUN
SIMULATION
PRODUCTION

PRODUCTION deverá exigir autorização elevada.

42. Event Filtering by Tenant

Um consumidor global poderá receber:

GLOBAL

ou eventos tenant-scoped somente quando autorizado.

Um consumidor Tenant A:

tenantId = A

nunca deverá receber eventos de B.

43. Cross-Tenant Protection

Mesmo que uma subscription tenha sido configurada incorretamente:

Tenant A subscription

o Event Fabric deverá aplicar uma segunda validação.

44. Event Security

Eventos deverão possuir classificação de sensibilidade:

PUBLIC
INTERNAL
CONFIDENTIAL
RESTRICTED

Isso poderá determinar:

  • quem pode consumir;
  • onde pode ser armazenado;
  • se pode entrar no LLM context.

45. LLM Event Context

Nunca enviar automaticamente o payload completo de qualquer evento para o LLM.

Fluxo:

Event
 ↓
Policy
 ↓
Data Minimization
 ↓
Relevant Context
 ↓
LLM

46. Event Data Minimization

Se o evento possui:

employee
medical-related metadata
documents

o agente deverá receber apenas o necessário para a tarefa.

47. Event-to-Knowledge

Eventos poderão disparar consultas ao HAG.

Exemplo:

RiskChanged
 ↓
Knowledge Resolver
 ↓
Find applicable safety procedure

Mas conhecimento encontrado não é autorização para agir.

48. Event-to-Policy

O evento poderá disparar:

Policy Evaluation

Exemplo:

TrainingExpired
 ↓
Policy
 ↓
Is active permit affected?

49. Event-to-Approval

Alguns eventos poderão criar aprovação:

CriticalRiskDetected
 ↓
Policy
 ↓
Human Review

50. Event Storm Protection

Uma alteração poderá gerar vários eventos relacionados.

Exemplo:

EmployeeChanged
 ↓
TrainingChanged
 ↓
PermitChanged
 ↓
RiskChanged

O sistema deverá evitar cascatas desnecessárias.

51. Debouncing

Quando permitido:

10 changes
within 5 seconds

poderão ser consolidadas em:

EmployeeProfileChanged

ou evento agregado equivalente.

52. Event Aggregation

Exemplo:

RiskChanged × 20

pode gerar:

RiskSetUpdated

quando a semântica permitir.

53. Recursion Protection

O Event Fabric deverá impedir loops:

Event A
 ↓
Workflow
 ↓
Event B
 ↓
Workflow
 ↓
Event A

Deverá existir:

causation chain
depth limit
cycle detection

54. Maximum Reaction Depth

Cada cadeia poderá possuir:

maxDepth

Exemplo:

A → B → C → D

Depois de determinado limite:

REACTION_DEPTH_EXCEEDED

e encaminhamento para análise.

55. Event Loop Detection

Registrar:

eventType
workflowId
capabilityId
causationChain

para detectar padrões repetitivos.

56. Scheduled Events

Além de eventos de negócio, o Fabric poderá receber:

SCHEDULED_EVENT

Exemplo:

Every day at 02:00
 ↓
Find expiring permits

57. Temporal Rules

Exemplo:

Se uma permissão estiver vencendo em 24 horas, criar tarefa de revisão.

Fluxo:

Timer
 ↓
Query
 ↓
Policy
 ↓
Workflow

58. Event-driven Monitoring

O sistema poderá reagir a:

SLA_BREACHED
APPROVAL_OVERDUE
INTEGRATION_FAILURE
WORKFLOW_STUCK

59. Workflow Watchdog

O Event Fabric poderá gerar:

WORKFLOW_STUCK

quando:

workflow.state = WAITING
duration > threshold

O Agentic Runtime poderá então:

notify
escalate
review

conforme policy.

60. Business Rules

Não colocar regras de negócio diretamente no Event Fabric.

Errado:

Event Fabric:
if permitApproved then release()

Correto:

Event Fabric:
emit WorkPermitApproved

Workflow:
decide next action

Policy:
authorize

Capability:
execute

61. Event Fabric as Infrastructure

O Event Fabric deverá permanecer relativamente agnóstico ao domínio.

Ele deverá saber:

event exists
event schema
event scope
routing
delivery
retry
security

Mas não:

como uma permissão deve ser liberada

62. Domain Logic

A lógica continuará nos componentes apropriados:

Domain
Capability
Policy
Workflow

63. Event Registry Integration

O Agent Knowledge/Capability Graph do PRD-009 deverá conectar:

Semantic Resource
      │
      ├── Knowledge
      ├── Capability
      ├── Policy
      ├── UI
      └── Events

Exemplo:

workPermit.approval
      │
      ├── documentedBy
      ├── approvedBy
      ├── capability
      ├── policy
      └── event: WorkPermitApproved

64. Event Discovery

Isso permitirá ao agente responder:

“O que acontece quando uma permissão é aprovada?”

deterministicamente:

WorkPermitApproved
 ↓
registered workflows
 ↓
registered reactions

65. Agentic Event Reasoning

Quando a reação exigir raciocínio:

Event
 ↓
Deterministic Resolution
 ↓
Knowledge
 ↓
LLM
 ↓
Structured Decision
 ↓
Policy
 ↓
Workflow

O LLM continua subordinado às estruturas determinísticas.

66. LLM Minimization

Eventos simples não precisam de LLM.

Exemplo:

ApprovalApproved
 ↓
workflow.resume()

Nenhum modelo é necessário.

67. Complex Event

Exemplo:

RiskChanged

poderá exigir:

identify affected permits
interpret risk relationship
find applicable procedures

Aqui o LLM poderá ser utilizado, mas sempre produzindo uma decisão estruturada.

68. Autonomous Action Boundary

O agente poderá iniciar automaticamente uma ação somente se:

policy = ALLOW

Caso contrário:

REQUIRE_APPROVAL

ou:

REQUIRE_HUMAN_REVIEW

69. Event-triggered Mass Actions

Extremamente importante.

Exemplo:

TrainingExpired
 ↓
1,500 employees
 ↓
8,000 permits

O agente não deverá executar automaticamente milhares de operações.

Deverá aplicar:

impact analysis
batch limits
approval
workflow
rate limiting

70. Blast Radius

Antes de reação em massa:

affectedResources
affectedUsers
affectedWorkflows
affectedTenants

deverão ser calculados.

71. Human Approval for Large Blast Radius

Exemplo:

affected permits = 4,832

policy:

REQUIRE_HUMAN_REVIEW

72. Tenant Configuration

Cada tenant poderá configurar reações:

event
 ↓
tenant policy
 ↓
workflow

Mas não poderá violar políticas globais de segurança.

73. Event Subscription Lifecycle

DRAFT
 ↓
VALIDATING
 ↓
APPROVED
 ↓
ACTIVE
 ↓
DISABLED
 ↓
DEPRECATED
 ↓
REMOVED

74. Event Subscription Versioning

Subscriptions deverão ser versionadas para permitir:

rollback
audit
safe deployment

75. Deployment

O PRD-016 deverá incluir:

event definitions
event subscriptions
workflow triggers

no Release Bundle.

76. Compatibility

Uma release deverá validar:

Event schema
Consumer schema
Workflow trigger
Capability
Policy

para evitar:

producer v2
consumer expecting v1

77. Schema Evolution

Mudanças compatíveis poderão manter:

v1

Mudanças incompatíveis:

v2

O sistema poderá manter consumidores de versões anteriores durante período de transição.

78. Event Observability

Métricas:

eventsProduced
eventsConsumed
eventsFailed
eventsRetried
eventsDuplicated
eventsDeadLettered
eventProcessingLatency
queueDepth

79. Event Trace

Cada evento deverá possuir trace/correlation:

Event
 ↓
Subscription
 ↓
Workflow
 ↓
Capability
 ↓
API
 ↓
Verification

Isso integra diretamente ao PRD-015.

80. Event Audit

Eventos de negócio importantes deverão ser registrados no mecanismo de auditoria do PRD-013.

Audit não deve depender exclusivamente do Event Fabric.

81. Security Alerts

Eventos suspeitos poderão alimentar segurança:

MassActionDetected
CrossTenantAttempt
RepeatedAuthorizationFailure
UnexpectedCapabilityInvocation

82. Event Rate Limits

Deverão existir limites por:

tenant
producer
eventType
consumer
workflow

83. Tenant Isolation

Um tenant nunca deverá conseguir:

publish event for another tenant
subscribe to another tenant
consume another tenant
trigger workflow in another tenant

sem autorização explícita de plataforma.

84. External Event Gateway

Integrações externas deverão passar por uma camada:

External System
 ↓
Authenticated Gateway
 ↓
Schema Validation
 ↓
Tenant Resolution
 ↓
Event Fabric

Nunca permitir que uma API externa publique diretamente no runtime interno.

85. Event Authentication

Eventos externos deverão possuir mecanismos como:

signature
token
mTLS
authenticated integration

conforme o tipo de integração.

86. Event Replay Protection

Eventos externos também deverão proteger contra replay.

Exemplo:

eventId already processed

ou timestamp/nonce quando aplicável.

87. First Vertical Slice

Implementar inicialmente:

WorkPermitApproved

Fluxo:

Approval
 ↓
WorkPermitApproved
 ↓
Event Fabric
 ↓
Workflow Resume
 ↓
Release
 ↓
Verification
 ↓
Audit

88. Segundo Vertical Slice

Implementar:

TrainingExpired

Fluxo inicial:

TrainingExpired
 ↓
Find affected employee
 ↓
Find active permits
 ↓
Policy evaluation
 ↓
Create review workflow

Inicialmente sem execução automática de grande escala.

89. Acceptance Criteria

Event Infrastructure​

  • Event Envelope;
  • Event Registry;
  • schemas versionados;
  • routing;
  • subscriptions;
  • retry;
  • DLQ;
  • deduplicação;
  • replay.

Security​

  • tenant isolation;
  • event authentication;
  • event authorization;
  • sensitive-data classification;
  • data minimization;
  • replay protection;
  • blast-radius protection.

Workflow​

  • event triggers;
  • resume;
  • timers;
  • correlation;
  • causation;
  • cycle detection.

Agent​

  • deterministic event reactions;
  • LLM somente quando necessário;
  • structured decisions;
  • policy enforcement;
  • human approval para operações de risco.

Operations​

  • metrics;
  • tracing;
  • audit;
  • queue monitoring;
  • failure handling.

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

O Event Fabric usa envelope e registry versionados, Queue/DLQ e inbox D1 deduplicada por tenant. Consumers persistem falha, aplicam retry/backoff limitado, preservam correlation/causation e permitem replay controlado; mensagens não autorizam execução e reações permanecem policy-bound.

Em 2026-09-04, o consumidor passou a rejeitar antes do handler cadeias de causação cíclicas, auto-causação e cadeias acima de 16 ancestrais; uma cadeia fornecida precisa terminar no causationId imediato. A proteção é compatível com eventos legados sem cadeia e persiste a tentativa recusada no inbox para retry/DLQ observável. Foram aprovados 27 testes focados de Queue/registry e a pré-publicação do Worker (53 arquivos, 310 testes); o Worker foi publicado na versão 9218e7e1-f258-42ac-a43c-bd4a8fe9ba60, com /health público saudável.

Em 2026-09-05, os contratos de Event Fabric passaram com 45 testes em 6 arquivos. O canário operacional remoto comprovou eventos processados, quatro fatos auditáveis, transições de estado, projeções canônicas, risco, Attention, Decision, intervenção e isolamento tenant-safe, sempre sem autoridade automática. O roteamento reativo amplo entre domínios permanece uma expansão futura, sem reduzir os controles certificados.

Em 2026-09-06, a regressão atual de registry, Queue, rota de eventos e stream de execução passou com 54 testes, e o typecheck do Agent passou novamente. O health público do Worker confirmou runtime e bindings. O estado permanece PARTIAL porque o roteamento reativo amplo entre domínios ainda requer prova dedicada.

Em canário remoto de 2026-09-06, sete mensagens percorreram supervisor→training→supervisor→risk→supervisor→decision→supervisor; task e result receberam ACKNOWLEDGED após QUEUED→DELIVERED, progresso cancelado permaneceu CANCELLED, replay foi idempotente e ordenação/payload sensível foram recusados. Os hashes de body e contexto de autorização tiveram 64 caracteres, nenhuma mensagem autorizou execução e o cleanup PostgreSQL retornou remainingRows: 0.

90. Resultado

O Agentic Work passa a funcionar em dois sentidos:

                    ┌──────────────┐
                    │     USER     │
                    └──────┬───────┘
                           │
                        command
                           │
                           ▼
                    ┌──────────────┐
                    │    AGENT     │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │   WORKFLOW   │
                    └──────┬───────┘
                           │
                           ▼
                    BUSINESS SYSTEM
                           │
                           │ events
                           ▼
                    ┌──────────────┐
                    │ EVENT FABRIC │
                    └──────┬───────┘
                           │
                           ▼
                       AGENTIC
                      REACTION

Isso transforma o agente de um simples assistente conversacional em um componente reativo da plataforma.

PRD-021 — Agentic Proactive Intelligence & Autonomous Operations

O próximo estágio será construído sobre o Event Fabric.

Até aqui o agente reage a:

User command
Event
Workflow
Approval

O PRD-021 deverá introduzir proatividade controlada.

A diferença é importante:

Reativo​

O treinamento venceu → o sistema reage.

Proativo​

O treinamento vencerá em 15 dias e existem 37 permissões potencialmente afetadas. O agente identifica o risco antecipadamente e prepara uma ação.

O PRD-021 deverá definir:

  • detecção antecipada de situações relevantes;
  • previsões e sinais;
  • regras temporais;
  • análise de risco;
  • recomendações;
  • ações automáticas autorizadas;
  • proactive workflows;
  • alertas;
  • prioridades;
  • suppression/deduplication;
  • prevenção de alert fatigue;
  • autonomous operations;
  • limites de autonomia;
  • human approval;
  • blast-radius control;
  • explainability;
  • tenant-specific proactive policies;
  • avaliação contínua das decisões proativas.

O princípio central será:

O agente pode ser proativo, mas nunca pode ser arbitrário.

Ele deverá sempre transformar uma percepção em:

Signal
 ↓
Evidence
 ↓
Risk
 ↓
Policy
 ↓
Recommendation
 ↓
Optional Approval
 ↓
Workflow
 ↓
Capability
 ↓
Verification

Esse será o ponto em que o Agentic Work começará a evoluir de um sistema que responde ao usuário para um sistema que antecipa problemas e prepara ações, sem perder o controle humano, a segurança e a auditabilidade.