PRD-030 — Agentic Multi-Agent Collaboration & Swarm Orchestration

1. Objetivo

O PRD-030 define a arquitetura para permitir que múltiplos agentes especializados trabalhem conjuntamente dentro do Agentic Work.

A motivação é simples: determinadas tarefas do SST atravessam vários domínios.

Por exemplo:

“Verifique se a Work Permit do funcionário está apta para ser liberada.”

Essa solicitação pode exigir:

Employee Agent
      ↓
Training Agent
      ↓
Risk Agent
      ↓
Compliance Agent
      ↓
Decision Agent
      ↓
Policy Engine
      ↓
Work Permit Agent

Entretanto, não queremos transformar o sistema em um conjunto de LLMs conversando livremente.

O objetivo é criar uma arquitetura de colaboração controlada:

Agent
 ↓
Agent Contract
 ↓
Delegation
 ↓
Task
 ↓
Capability / Evidence
 ↓
Result
 ↓
Verification

2. Princípio Fundamental

Um agente não deverá possuir autoridade simplesmente porque outro agente pediu alguma coisa.

Portanto:

Agent A
   │
   │ request
   ▼
Agent B

não significa:

Agent A → autoriza Agent B

A autoridade continua derivando de:

Human / System Authority
        ↓
Delegation
        ↓
Agent Identity
        ↓
Capability
        ↓
Policy
        ↓
Execution

3. Multi-Agent ≠ Multi-Authority

Essa distinção é fundamental.

Podemos ter:

10 agents

mas:

security model
tenant boundary
policy system
audit fabric

Não deverá existir uma política diferente de segurança simplesmente porque a operação foi executada por outro agente.

4. Objetivos Específicos

O PRD deverá permitir:

agentes especializados por domínio;
descoberta dinâmica de agentes;
delegação controlada;
handoff de tarefas;
execução paralela;
composição de resultados;
agentes supervisores;
agentes especialistas;
validação cruzada;
resolução de conflitos;
retry;
timeout;
cancelamento;
isolamento de contexto;
autenticação Agent-to-Agent;
observabilidade;
auditoria;
controle de custos;
prevenção de loops;
limites de profundidade;
proteção contra escalada de privilégios.

5. Não Objetivos

O PRD não pretende criar:

agentes autônomos sem limites;
autoridade implícita entre agentes;
comunicação livre entre todos os agentes;
compartilhamento irrestrito de memória;
acesso direto do LLM a APIs;
alteração automática de policies;
auto-criação de agentes em produção;
auto-modificação de capacidades;
swarm sem supervisão.

6. Arquitetura Geral

                         USER
                           │
                           ▼
                  CONVERSATION RUNTIME
                           │
                           ▼
                   SUPERVISOR AGENT
                           │
                 ┌─────────┼─────────┐
                 │         │         │
                 ▼         ▼         ▼
            TRAINING     RISK    COMPLIANCE
             AGENT       AGENT      AGENT
                 │         │         │
                 └─────────┼─────────┘
                           ▼
                    DECISION AGENT
                           │
                           ▼
                     POLICY ENGINE
                           │
                           ▼
                    CAPABILITY
                           │
                           ▼
                      EXECUTION

7. Agent Registry

Todo agente deverá estar registrado.

interface AgentDefinition {
  agentId: string;

  name: string;

  version: string;

  description: string;

  domains: string[];

  capabilities: string[];

  inputSchema: JSONSchema;

  outputSchema: JSONSchema;

  status:
    | "DRAFT"
    | "ACTIVE"
    | "DEPRECATED"
    | "DISABLED";

  riskLevel:
    | "LOW"
    | "MEDIUM"
    | "HIGH"
    | "CRITICAL";
}

8. Agent Semantic ID

Os agentes deverão possuir IDs estáveis.

Exemplos:

agent.training
agent.risk
agent.compliance
agent.workPermit
agent.decision
agent.workflow
agent.supervisor

9. Agent Registry ≠ Capability Registry

Capability Registry

descreve o que pode ser executado.

Agent Registry

descreve quem é especializado em determinada tarefa.

Exemplo:

agent.training

pode utilizar:

training.getStatus
training.validate
training.search

10. Agent Contract

Todo agente deverá possuir um contrato formal.

interface AgentContract {
  agentId: string;

  version: string;

  acceptedInputs: JSONSchema;

  producedOutputs: JSONSchema;

  supportedTasks: string[];

  requiredContext: string[];

  allowedDelegations: string[];

  timeoutMs: number;

  maxDepth: number;
}

Isso impede que um agente seja chamado com parâmetros desconhecidos.

11. Agent Discovery

O supervisor poderá consultar:

Agent Registry

para descobrir qual agente é adequado.

Exemplo:

Task:
"Verificar treinamento NR-10"

→ agent.training

12. Discovery Determinístico

A descoberta deverá preferir:

exact task mapping
↓
domain mapping
↓
capability mapping
↓
semantic graph
↓
LLM fallback

O LLM não deverá ser utilizado para descobrir algo que o Registry já consegue resolver.

13. Agent Manifest

O release poderá conter:

{
  "agentId": "agent.training",
  "version": "1.2.0",
  "domains": ["training"],
  "capabilities": [
    "training.getStatus",
    "training.validate"
  ]
}

Esse manifesto deverá integrar-se ao Agent Release Bundle do PRD-016.

14. Agent Identity

Cada agente deverá possuir identidade própria.

agentId
agentVersion
tenantScope
delegationId

O agente nunca deverá se passar diretamente pelo usuário.

15. Agent-to-Agent Authentication

A comunicação entre agentes deverá ser autenticada.

Agent A
   ↓
A2A Authentication
   ↓
Agent B

A mensagem deverá conter:

interface AgentAuthContext {
  callerAgentId: string;

  callerVersion: string;

  tenantId: string;

  delegationId: string;

  audience: string;

  issuedAt: string;

  expiresAt: string;

  scopes: string[];
}

16. Delegation

A delegação deverá seguir o PRD-027.

Exemplo:

User
 ↓
Supervisor Agent
 ↓ delegated
Training Agent

O Training Agent recebe apenas o escopo necessário.

17. Authority Subset

Formalmente:

AgentAuthority ⊆ DelegatorAuthority

Um agente jamais poderá adquirir uma autoridade superior àquela que recebeu.

18. No Recursive Privilege Escalation

Não permitido:

Agent A
 ↓
Agent B
 ↓
Agent C
 ↓
"give me admin privileges"

A delegação deverá ser limitada por:

maxDepth
allowedAgents
allowedCapabilities
allowedResources
expiration

19. Agent Task

A unidade básica de colaboração será uma AgentTask.

interface AgentTask {
  taskId: string;

  parentTaskId?: string;

  agentId: string;

  tenantId: string;

  delegationId: string;

  taskType: string;

  input: unknown;

  context: TaskContext;

  deadline: string;

  status:
    | "CREATED"
    | "RUNNING"
    | "WAITING"
    | "COMPLETED"
    | "FAILED"
    | "CANCELLED";
}

20. Task Hierarchy

Uma tarefa pode gerar subtarefas:

Task A
├── Task B
├── Task C
└── Task D

Isso cria uma árvore de execução.

21. Task DAG

Quando existirem dependências:

Training
    │
    ▼
Risk
    │
    ▼
Decision

deverá ser representado como DAG.

Training ─────┐
              ▼
             Risk
              │
Compliance ───┘
              │
              ▼
           Decision

22. Parallel Execution

Quando as tarefas forem independentes:

Training ─────┐
Risk ─────────┼──→ Decision
Compliance ───┘

podem executar paralelamente.

Isso é essencial para performance.

23. Parallelism Policy

Cada plano deverá possuir:

interface ParallelismPolicy {
  maxConcurrentAgents: number;

  maxConcurrentTasks: number;

  maxDepth: number;

  maxTotalTasks: number;
}

24. Blast Radius

O sistema deverá limitar:

max agents
max tasks
max capabilities
max resources
max mutations

Isso evita que uma solicitação simples gere centenas de operações.

25. Swarm Protection

Não deverá ser permitido:

Agent A
→ 10 agents
→ cada um chama 10
→ cada um chama 10

sem limite.

Deverão existir:

maxDepth
maxTasks
maxExecutionTime
maxCost
maxLLMCalls

26. Agent Loop Detection

O runtime deverá detectar:

A → B → C → A

e bloquear.

Cada execução deverá manter:

visitedAgents: string[];

27. Agent Call Graph

O runtime poderá registrar:

Supervisor
 ├── Training
 ├── Risk
 │    └── Compliance
 └── Decision

Esse grafo será útil para observabilidade e análise de custos.

28. Shared Context

Nem todo contexto precisa ser privado.

Poderá existir:

Shared Task Context

contendo:

employeeId
workPermitId
trainingStatus
riskStatus

29. Private Agent Context

Um agente poderá possuir contexto privado:

Agent Private Context

que não será compartilhado automaticamente.

Isso é importante para:

minimização de dados;
segurança;
redução de tokens;
isolamento de raciocínio interno.

30. Context Contract

Cada agente deverá declarar:

interface ContextRequirement {
  field: string;

  required: boolean;

  sensitivity:
    | "PUBLIC"
    | "INTERNAL"
    | "CONFIDENTIAL"
    | "RESTRICTED";
}

31. Context Minimization

Se o Training Agent precisa de:

employeeId
courseId

não deverá receber:

salary
medicalData
personalAddress

simplesmente porque estão disponíveis no contexto geral.

32. Tenant Context

Toda tarefa deverá carregar:

tenantId

e esse valor deverá ser obtido do contexto de segurança.

Nunca:

tenantId fornecido livremente pelo LLM

33. Agent Result

Os resultados deverão ser estruturados.

interface AgentResult<T = unknown> {
  taskId: string;

  agentId: string;

  status:
    | "SUCCESS"
    | "PARTIAL"
    | "FAILED"
    | "UNCERTAIN";

  data?: T;

  evidenceIds: string[];

  confidence?: number;

  trustEvaluation?: TrustEvaluation;

  warnings?: string[];

  nextActions?: string[];
}

34. Result ≠ Truth

O resultado de um agente deverá ser considerado uma saída de processamento, não automaticamente um fato.

Exemplo:

Training Agent:
"Training probably expired."

Isso deverá permanecer:

INFERENCE

até que haja evidência adequada.

35. Evidence Propagation

Se um agente consulta uma fonte oficial:

Training Agent
 ↓
LMS
 ↓
Evidence

o evidenceId deverá acompanhar o resultado.

Isso integra diretamente ao PRD-029.

36. Result Provenance

Cada resultado importante deverá responder:

Quem produziu?
Qual agente?
Qual versão?
Com base em quais evidências?
Qual knowledge version?
Qual policy version?

37. Supervisor Agent

O Supervisor será responsável por:

interpretar tarefa
decompor
selecionar agentes
criar plano
coordenar
agregar resultados

Mas não deverá possuir autoridade especial para ignorar policies.

38. Supervisor ≠ Root Authority

Mesmo o Supervisor deverá passar por:

Policy Engine

antes de executar uma capability.

39. Specialist Agent

Agentes especialistas deverão possuir escopo limitado.

Exemplo:

Training Agent

é especialista em:

training
certificates
validity
courses

Não deverá executar:

workPermit.delete

se essa capability não fizer parte de sua autorização.

40. Agent Roles

Poderemos ter:

SUPERVISOR
SPECIALIST
VALIDATOR
ANALYZER
DECISION
EXECUTOR
MONITOR

Um agente pode possuir mais de uma função, desde que explicitamente definida.

41. Validator Agent

Alguns processos poderão exigir validação independente.

Exemplo:

Decision Agent
      ↓
Validator Agent

O Validator deverá verificar:

evidence
rules
constraints
policy requirements

42. Independent Validation

Para ações críticas:

Agent A recommends
        ↓
Agent B validates
        ↓
Human / Policy

Mas o segundo agente não deverá simplesmente repetir a primeira resposta.

Ele deverá receber evidências adequadas e executar validação independente.

43. Conflict Between Agents

Exemplo:

Risk Agent:
HIGH

Compliance Agent:
PASS

Isso não deverá ser resolvido por maioria simples.

O sistema deverá identificar:

CONFLICT

e aplicar regras de domínio.

44. Agent Consensus

Quando apropriado, poderá existir:

CONSENSUS

Mas consenso não substitui autoridade.

Exemplo:

3 agents → approve

não significa:

Policy → ALLOW

45. Weighted Consensus

Em domínios específicos poderá existir:

Risk Agent = weight 3
Compliance Agent = weight 5
Training Agent = weight 2

Mas esses pesos deverão ser definidos por configuração/policy.

Nunca pelo LLM.

46. Majority Vote

Pode ser usado apenas para decisões classificatórias de baixo risco.

Exemplo:

Is this document relevant?

Não deverá ser usado para:

Release Work Permit

sem validação formal.

47. Agent Negotiation

Agentes poderão solicitar informações adicionais.

Exemplo:

Risk Agent
→ Training Agent:
"Preciso da validade do treinamento."

Training Agent
→ Risk Agent:
"2026-09-15."

Isso deverá ocorrer através de mensagens estruturadas.

48. Agent Message

interface AgentMessage {
  messageId: string;

  conversationId?: string;

  executionId: string;

  taskId: string;

  senderAgentId: string;

  receiverAgentId: string;

  type:
    | "REQUEST"
    | "RESPONSE"
    | "QUESTION"
    | "RESULT"
    | "ERROR"
    | "CANCEL";

  payload: unknown;

  correlationId: string;

  causationId?: string;
}

49. No Free-Form Agent Chat

Internamente não deverá existir:

"Hey, what do you think?"

como protocolo.

O transporte deverá ser estruturado.

O LLM pode produzir texto internamente, mas o runtime deverá trabalhar com schemas.

50. Agent Task Schema

Cada tarefa deverá ter:

{
  "taskType": "training.validate",
  "input": {
    "employeeId": "EMP-104"
  }
}

O schema será validado antes da execução.

51. Agent Handoff

Um agente poderá transferir uma tarefa:

Agent A
 ↓ HANDOFF
Agent B

O handoff deverá incluir:

task
reason
context
evidence
deadline
delegation

52. Handoff Security

O Agent B deverá verificar novamente:

caller identity
delegation
tenant
scope
capability
policy

Nunca confiar apenas no Agent A.

53. Handoff Idempotency

O handoff deverá possuir:

handoffId

para evitar duplicação.

54. Agent Cancellation

Uma tarefa poderá ser cancelada:

Supervisor
 ↓
Cancellation
 ↓
Child Agents

Os agentes deverão respeitar cancelamento sempre que tecnicamente possível.

55. Cancellation Propagation

Se:

parent task = CANCELLED

subtarefas ainda não concluídas deverão ser:

CANCEL_REQUESTED

e posteriormente:

CANCELLED

ou:

COMPLETED

se não puderem ser interrompidas.

56. Timeout

Cada tarefa deverá possuir deadline.

interface TaskDeadline {
  createdAt: string;

  deadlineAt: string;

  timeoutMs: number;
}

57. Timeout Strategy

Dependendo da tarefa:

retry
fallback
partial result
human review
abort

58. Agent Failure

Falha de um agente não deverá necessariamente derrubar todo o plano.

Exemplo:

Training ✓
Risk ✓
Compliance ✗

O Planner deverá decidir:

retry
fallback
partial
review
abort

com base na policy.

59. Agent Fallback

Um agente poderá ter fallback:

agent:
  primary: agent.training
  fallback:
    - agent.externalTraining

O fallback deverá ser explicitamente autorizado.

60. No Arbitrary Fallback

O Supervisor não poderá decidir:

“Esse agente falhou; vou chamar qualquer outro.”

Fallback deverá estar registrado.

61. Agent Versioning

Um agente deverá possuir:

agent.training@1.2.0

O execution plan deverá registrar a versão utilizada.

62. Execution Pinning

Uma execução iniciada com:

agent.training@1.2.0

não deverá mudar silenciosamente para:

agent.training@1.3.0

durante a mesma operação.

63. Agent Release

O agente fará parte do:

Agent Release Bundle

do PRD-016.

Assim teremos:

Agent
Knowledge
Capability
Policy
UI
Evaluation
Runtime

versionados em conjunto.

64. Agent Lifecycle

DRAFT
 ↓
TESTING
 ↓
EVALUATING
 ↓
APPROVED
 ↓
CANARY
 ↓
ACTIVE
 ↓
DEPRECATED
 ↓
RETIRED

65. Agent Evaluation

Antes de produção:

Intent tests
Capability tests
Security tests
Knowledge tests
Performance tests
Multi-agent tests

deverão passar.

66. Agent Simulation

O PRD-014 deverá permitir:

Supervisor
 ↓
Training Agent
 ↓
Risk Agent
 ↓
Decision Agent

em ambiente simulado.

Sem mutações reais.

67. Agent Replay

Uma execução real poderá ser reproduzida:

Execution
 ↓
Replay
 ↓
Same inputs
 ↓
New agent version
 ↓
Compare

68. Determinism

Sempre que possível:

routing
authorization
capability selection
policy
validation

deverão ser determinísticos.

LLM deverá ficar principalmente em:

interpretation
unstructured analysis
complex synthesis

69. Agent LLM Budget

Cada agente deverá possuir limites:

interface AgentBudget {
  maxLLMCalls: number;

  maxInputTokens: number;

  maxOutputTokens: number;

  maxCost: number;

  timeoutMs: number;
}

70. Cost Aggregation

O runtime deverá calcular:

cost per task
cost per agent
cost per workflow
cost per tenant
cost per operation

Isso integra ao PRD-015.

71. Token Sharing

Contexto compartilhado deverá ser minimizado.

Não devemos fazer:

Agent A output = 20k tokens
→ Agent B recebe tudo
→ Agent C recebe tudo

Preferir:

Structured Facts
Evidence IDs
Entity IDs
Relevant Context

72. Agent Memory

Agentes não deverão compartilhar automaticamente memória de longo prazo.

Existem três categorias:

Conversation Context
Task Context
Operational Memory

Cada uma possui lifecycle próprio.

73. Agent Knowledge Access

Um agente poderá consultar a Knowledge Fabric, mas sempre com:

tenant
permissions
scope
knowledgeVersion
trust requirements

74. Agent Knowledge Scope

O Agent Registry poderá declarar:

agent.training:
  knowledgeScopes:
    - training
    - employee

Isso permite restringir retrieval.

75. Agent Capability Scope

Da mesma forma:

agent.training:
  capabilities:
    - training.getStatus
    - training.validate

76. Agent UI Interaction

Quando um agente precisar alterar a UI, deverá utilizar:

UI Command Registry

do PRD-011.

Nunca:

agent → arbitrary DOM

77. Agent Workflow Interaction

Agentes poderão iniciar workflows através de:

Workflow Capability

e não diretamente manipulando o Workflow Store.

78. Agent Event Interaction

Eventos deverão passar pelo Event Fabric.

Agent
 ↓
Event Capability
 ↓
Event Fabric

Não:

Agent
 ↓
direct event database insert

79. Agent Decision Interaction

Agentes poderão produzir:

Decision Input

mas a decisão final seguirá o PRD-023.

80. Agent Exception Handling

Falhas multi-agent deverão ser tratadas pelo PRD-024.

Exemplo:

Training Agent timeout

gera:

AgentTaskTimeout

que pode acionar:

retry
fallback
incident

81. Agent Event Types

O Event Fabric deverá registrar eventos como:

AgentTaskCreated
AgentTaskStarted
AgentTaskCompleted
AgentTaskFailed
AgentTaskTimedOut
AgentTaskCancelled
AgentHandoffRequested
AgentHandoffCompleted
AgentConflictDetected
AgentConsensusReached
AgentDelegationDenied

82. Agent Observability

Cada task deverá possuir:

traceId
executionId
taskId
parentTaskId
agentId
agentVersion
tenantId
delegationId

83. Agent Call Tree

A observabilidade deverá permitir visualizar:

Execution #123

Supervisor
├── Training
│   └── LMS
├── Risk
│   └── Knowledge
└── Compliance

84. Agent Performance

Métricas:

task latency
success rate
failure rate
timeout rate
LLM calls
token usage
cost
handoffs
conflicts
fallbacks

85. Agent Quality

Também:

result accuracy
reference accuracy
evidence quality
verification failure
user correction

86. Agent Reliability Score

Pode existir uma métrica operacional:

agentReliability

mas ela não deverá conceder autoridade.

Um agente com 99.9% de sucesso não poderá executar uma capability não autorizada.

87. Agent Health

O registry deverá acompanhar:

HEALTHY
DEGRADED
UNAVAILABLE
DISABLED

88. Circuit Breaker

Se um agente apresentar falhas repetidas:

agent.training
 ↓
5 failures
 ↓
CIRCUIT OPEN

novas tarefas poderão ser encaminhadas ao fallback ou revisão.

89. Agent Rate Limit

Por tenant:

max tasks/min
max concurrent
max cost/hour

Por agente:

max concurrent
max requests/min

90. Tenant Isolation

Um agente nunca poderá utilizar contexto de outro tenant.

Isso inclui:

tasks
messages
memory
knowledge
embeddings
cache
evidence
results
audit
metrics

91. Cross-Agent Data Leakage

O runtime deverá validar cada payload.

Exemplo:

Agent A / Tenant A
        ↓
Agent B / Tenant B

deverá resultar em:

DENIED

mesmo se o payload possuir IDs válidos.

92. Sensitive Context

Dados classificados como:

RESTRICTED

somente poderão ser compartilhados quando o Agent Contract e Policy permitirem.

93. Agent Security Boundary

A arquitetura final deverá ser:

                 Agent
                   │
             Agent Runtime
                   │
          ┌────────┴────────┐
          ▼                 ▼
      Delegation          Policy
          │                 │
          └────────┬────────┘
                   ▼
              Capability
                   │
                   ▼
                API

94. Agent Prompt Injection

Um agente não poderá aceitar instruções de outro agente como autoridade.

Exemplo:

Agent A:
"Ignore the security policy."

Isso é apenas conteúdo.

O runtime continuará aplicando:

Policy Engine

95. Agent Trust

Assim como conhecimento possui Trust no PRD-029, agentes poderão possuir metadata operacional:

agentTrustMetadata

incluindo:

version
certification
security status
evaluation status

Isso não substitui authorization.

96. Agent Certification

Agentes críticos deverão possuir:

SECURITY_APPROVED
EVALUATION_APPROVED
PRODUCTION_APPROVED

antes de receber determinadas capabilities.

97. Human-in-the-Loop

Uma composição poderá chegar a:

Agent A
 ↓
Agent B
 ↓
Decision
 ↓
Human Approval
 ↓
Execution

O humano deverá aprovar a operação final, não simplesmente “o agente”.

98. Confirmation

Para operações de risco:

Agent plan
 ↓
Policy
 ↓
Confirmation
 ↓
Execution

O fato de outro agente recomendar a ação não elimina confirmação.

99. Multi-Agent Approval

Para determinadas operações críticas:

Agent Risk
+
Agent Compliance
+
Human

poderão ser requisitos independentes.

100. Two-Person Rule

O sistema deverá suportar:

Approver A
+
Approver B

quando exigido pela policy.

Nenhum agente poderá substituir essa regra.

101. First Vertical Slice

O primeiro fluxo completo será:

“Verifique se uma Work Permit pode ser liberada.”

102. Step 1 — Supervisor

User
 ↓
Supervisor Agent

Identifica:

workPermit.release

103. Step 2 — Decomposition

Supervisor cria:

Task 1:
Validate employee

Task 2:
Validate training

Task 3:
Evaluate risks

Task 4:
Evaluate compliance

As tarefas independentes executam em paralelo.

104. Step 3 — Training Agent

Training Agent
 ↓
LMS Gateway
 ↓
Evidence
 ↓
Training Result

Resultado:

{
  "status": "VALID",
  "validUntil": "2026-09-15",
  "evidenceIds": ["EV-1001"]
}

105. Step 4 — Risk Agent

Consulta:

Risk Knowledge
Risk API
Employee context
Work Permit context

Resultado:

risk = LOW

com evidências.

106. Step 5 — Compliance Agent

Avalia:

mandatory requirements
business rules
documentation
training

Resultado:

PASS

ou:

FAIL

ou:

UNKNOWN

107. Step 6 — Decision Agent

Recebe:

Training Result
Risk Result
Compliance Result
Work Permit State
Evidence

e produz:

Decision:
READY_FOR_RELEASE

ou:

BLOCKED

108. Step 7 — Trust Evaluation

O PRD-029 verifica:

evidence authority
freshness
conflicts
verification

109. Step 8 — Policy

O Policy Engine verifica:

user authorization
tenant
workPermit state
decision
risk
trust
segregation of duties

110. Step 9 — Confirmation

Se necessário:

CONFIRM RELEASE

111. Step 10 — Capability

Somente então:

workPermit.release

poderá ser executada.

112. Step 11 — Verification

Depois:

GET workPermit

confirmando:

status = RELEASED

113. Complete Flow

                         USER
                           │
                           ▼
                     SUPERVISOR
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
       TRAINING          RISK         COMPLIANCE
            │              │              │
            └──────────────┼──────────────┘
                           ▼
                       DECISION
                           │
                           ▼
                         TRUST
                           │
                           ▼
                        POLICY
                           │
                           ▼
                      CONFIRMATION
                           │
                           ▼
                       CAPABILITY
                           │
                           ▼
                         API
                           │
                           ▼
                     VERIFICATION
                           │
                           ▼
                        RESULT

114. Critérios de Aceitação

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

Planos de swarm têm limites persistentes de tarefa, profundidade e orçamento, com DAG/ciclo validados. A comunicação entre agentes usa envelope versionado, audience/receiver exatos, sequência, expiração, idempotência, hashes de corpo/contexto e trilha de estados. Handoffs requerem delegação tenant/swarm/capability/resource específica; deadlines expirados propagam estado terminal. Validação de resultados exige evidência e agente independente, e a aprovação colaborativa já aplica SoD e two-person rule.

Em 2026-09-05, o gate de colaboração passou com 27 testes em 3 arquivos e o canário remoto confirmou workspace tenant-isolado com dois humanos independentes, handoff rejeitado/reassignment, takeover de agente com override humano sem burlar policy, contexto minimizado, delegação limitada ao workspace, SoD rejeitada, aprovação QUORUM com dois votos/two-person/token único e revalidação de execução; drift de binding exigiu reapproval, e tamper de policy/voto foi rejeitado. Somado ao canário de swarm, há prova de DAG, limites, cancelamento e timeout. A recertificação focada passou com 13 testes em 3 arquivos e confirma camadas paralelas determinísticas para especialistas independentes, sujeitas a dependências, orçamento e limites de profundidade. Casos versionados por agente agora executam no AgentSandbox e passam pelo evaluateSuite do PRD-014, preservando gates de segurança e regressão sem execução. A rota persistente do runtime armazena consumo acumulado de chamadas LLM e micros de custo em cada execução, aplica os limites imutáveis correspondentes antes de adaptar o fluxo e termina em fail-closed com LLM_CALL_BUDGET_EXHAUSTED ou COST_BUDGET_EXHAUSTED. O endpoint de replay auditável reconstrói, sem escrita e por tenant, entradas pinadas, snapshots, passos, observações, adaptações e eventos imutáveis; a comparação de resultado contra nova versão de agente permanece aberta.

Em 2026-09-06, a regressão atual de swarm runtime, comunicação, colaboração, aprovação, projeção operacional e orquestração passou com 32 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 remoto registrado; esta execução revalidou os contratos locais correspondentes.

115. Resultado Arquitetural

Com o PRD-030, o Agentic Work passa a suportar uma verdadeira arquitetura de agentes especializados:

                    ┌───────────────────────┐
                    │    Agent Registry     │
                    └───────────┬───────────┘
                                │
                                ▼
                        Supervisor Agent
                                │
                ┌───────────────┼───────────────┐
                ▼               ▼               ▼
          Specialist A    Specialist B    Specialist C
                │               │               │
                └───────────────┼───────────────┘
                                ▼
                         Result Aggregation
                                │
                                ▼
                        Trust Evaluation
                                │
                                ▼
                         Decision Engine
                                │
                                ▼
                          Policy Engine
                                │
                                ▼
                       Capability Runtime
                                │
                                ▼
                           Execution

A arquitetura ganha especialização sem perder controle centralizado de segurança.

O ponto mais importante é que o Agentic Work passa a poder distribuir inteligência, mas não distribuir autoridade.

PRD-031 — Agentic Communication, Negotiation & Protocol Fabric

O próximo PRD deverá aprofundar a camada de comunicação criada no PRD-030.

Agora que temos múltiplos agentes, precisamos definir como eles conversam de maneira confiável, eficiente e interoperável.

O PRD-031 deverá tratar:

Agent Message Protocol
Message Envelope
Request / Response
Task / Result
Query / Answer
Proposal / Accept / Reject
Handoff
Negotiation
Subscriptions
Agent Events
Streaming
Message Ordering
Correlation
Causation
Delivery Guarantees
Deduplication
Retry
Dead Letter Queue
Backpressure
Priority
Message Expiration
Schema Evolution
Protocol Versioning
Agent Discovery
Agent Addressing
Authentication
Authorization
Encryption
Tenant Isolation
Message Size Limits
Sensitive Data
Context References
Evidence References
Conversation References
Workflow References
Cross-Agent Transactions
Conflict Resolution

A evolução será:

PRD-030
Agent Collaboration
       │
       ▼
PRD-031
Agent Communication Fabric
       │
       ▼
Agent Network
       │
       ├── Supervisor
       ├── Training
       ├── Risk
       ├── Compliance
       ├── Decision
       └── Workflow

E novamente haverá uma regra central:

Os agentes não conversarão livremente como pessoas. Eles se comunicarão por um protocolo estruturado, versionado, autenticado, observável e governado.

1. Objetivo​

2. Princípio Fundamental

3. Multi-Agent ≠ Multi-Authority

4. Objetivos Específicos

5. Não Objetivos

6. Arquitetura Geral

7. Agent Registry

8. Agent Semantic ID

9. Agent Registry ≠ Capability Registry

10. Agent Contract

11. Agent Discovery

12. Discovery Determinístico

13. Agent Manifest

14. Agent Identity

15. Agent-to-Agent Authentication

16. Delegation

17. Authority Subset

18. No Recursive Privilege Escalation

19. Agent Task

20. Task Hierarchy

21. Task DAG

22. Parallel Execution

23. Parallelism Policy

24. Blast Radius

25. Swarm Protection

26. Agent Loop Detection

27. Agent Call Graph

28. Shared Context

29. Private Agent Context

30. Context Contract

31. Context Minimization

32. Tenant Context

33. Agent Result

34. Result ≠ Truth

35. Evidence Propagation

36. Result Provenance

37. Supervisor Agent

38. Supervisor ≠ Root Authority

39. Specialist Agent

40. Agent Roles

41. Validator Agent

42. Independent Validation

43. Conflict Between Agents

44. Agent Consensus

45. Weighted Consensus

46. Majority Vote

47. Agent Negotiation

48. Agent Message

49. No Free-Form Agent Chat

50. Agent Task Schema

51. Agent Handoff

52. Handoff Security

53. Handoff Idempotency

54. Agent Cancellation

55. Cancellation Propagation

56. Timeout

57. Timeout Strategy

58. Agent Failure

59. Agent Fallback

60. No Arbitrary Fallback

61. Agent Versioning

62. Execution Pinning

63. Agent Release

64. Agent Lifecycle

65. Agent Evaluation

66. Agent Simulation

67. Agent Replay

68. Determinism

69. Agent LLM Budget

70. Cost Aggregation

71. Token Sharing

72. Agent Memory

73. Agent Knowledge Access

74. Agent Knowledge Scope

75. Agent Capability Scope

76. Agent UI Interaction

77. Agent Workflow Interaction

78. Agent Event Interaction

79. Agent Decision Interaction

80. Agent Exception Handling

1. Objetivo

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