PRD-029 — Agentic Knowledge Governance, Provenance & Trust
1. Objetivo
O PRD-029 define a camada de confiança, proveniência e governança do conhecimento do Agentic Work.
O PRD-028 criou uma Knowledge Fabric capaz de receber informações de múltiplas fontes. Agora precisamos resolver um problema ainda mais importante:
Como o agente determina se uma informação é suficientemente confiável para ser usada em uma resposta, decisão ou ação?
No SST isso é crítico.
Uma informação pode estar:
- correta, mas desatualizada;
- atual, mas proveniente de uma fonte não confiável;
- proveniente de fonte oficial, mas em conflito com outra fonte;
- inferida pelo LLM;
- confirmada por um usuário;
- validada por uma pessoa autorizada;
- tecnicamente consistente, mas juridicamente inadequada para determinada decisão.
Portanto:
Knowledge ≠ Truth
Knowledge ≠ Authority
Knowledge ≠ Confidence
Knowledge ≠ Freshness
Esses conceitos deverão ser tratados separadamente.
2. Princípio Fundamental
A arquitetura deverá distinguir:
SOURCE
↓
EVIDENCE
↓
FACT
↓
CONFIDENCE
↓
TRUST
↓
DECISION
Nunca:
LLM
↓
Answer
↓
Truth
3. Trust Model
A confiança de um conhecimento deverá ser multidimensional:
TRUST
│
┌───────────┼───────────┐
▼ ▼ ▼
Authority Freshness Evidence
│ │ │
└───────────┼───────────┘
▼
Consistency
│
▼
Verification
4. Dimensões de Confiança
Cada conhecimento poderá ser avaliado por:
| Dimensão | Pergunta |
|---|---|
| Authority | A fonte tem autoridade? |
| Freshness | A informação está atualizada? |
| Evidence | Existe evidência concreta? |
| Consistency | É consistente com outras fontes? |
| Verification | Foi verificada? |
| Provenance | Sabemos exatamente de onde veio? |
| Completeness | Temos informação suficiente? |
| Temporal validity | É válida neste momento? |
5. Trust Score
O sistema poderá calcular um score interno:
interface TrustScore {
authority: number;
freshness: number;
evidence: number;
consistency: number;
verification: number;
provenance: number;
overall: number;
}
Valores:
0.0 → nenhuma confiança
1.0 → confiança máxima
Porém, o score não deverá substituir regras determinísticas.
6. Trust Score Não Autoriza Ações
Um dado com:
trust = 0.99
não poderá automaticamente executar:
workPermit.approve
A autorização continua sendo responsabilidade do:
Policy Engine
7. Trust Classes
Além do score, deverá existir classificação:
AUTHORITATIVE
VERIFIED
TRUSTED
SUPPORTED
UNVERIFIED
CONFLICTED
STALE
REVOKED
UNKNOWN
8. Source Authority
Cada fonte deverá possuir uma classificação de autoridade.
Exemplo:
sources:
government:
authority: AUTHORITATIVE
business_api:
authority: AUTHORITATIVE
external_lms:
authority: VERIFIED
uploaded_document:
authority: SUPPORTED
user_feedback:
authority: UNVERIFIED
llm_inference:
authority: UNVERIFIED
9. Authority é Contextual
Uma fonte pode ser authoritative para um domínio e não para outro.
Exemplo:
LMS
→ authoritative para status de treinamento
SST
→ authoritative para status da Work Permit
Portanto não deverá existir apenas:
source.trust = HIGH
mas algo equivalente a:
source + domain + subject
10. Source Authority Registry
Deverá existir um registry:
interface SourceAuthorityRule {
sourceId: string;
domain?: string;
entityType?: string;
authority:
| "AUTHORITATIVE"
| "VERIFIED"
| "TRUSTED"
| "SUPPORTED"
| "UNVERIFIED";
priority: number;
validFrom: string;
validUntil?: string;
}
11. Evidence
Evidence representa aquilo que sustenta uma afirmação.
Exemplo:
FACT:
Employee EMP-104 training expires 2026-09-15
Evidence:
LMS response
timestamp
externalEntityId
API operation
12. Evidence Model
interface Evidence {
evidenceId: string;
tenantId: string;
sourceId: string;
sourceType: string;
reference: string;
capturedAt: string;
observedAt?: string;
contentHash?: string;
authority: string;
status:
| "VALID"
| "STALE"
| "REVOKED"
| "CONFLICTED";
}
13. Evidence Chain
Um fato poderá ser sustentado por várias evidências:
FACT
│
├── Evidence A → LMS
├── Evidence B → SST API
└── Evidence C → Document
14. Evidence Graph
A Knowledge Graph deverá poder representar:
Fact
↓ SUPPORTED_BY
Evidence
↓ PRODUCED_BY
Source
↓ AUTHENTICATED_BY
Credential/Integration
Isso cria rastreabilidade completa.
15. Evidence Strength
Cada evidência poderá ter:
DIRECT
DERIVED
CORROBORATED
INDIRECT
INFERRED
Exemplo:
LMS API response
→ DIRECT
"Employee probably completed training"
→ INFERRED
16. Direct Evidence
Dados diretamente obtidos da fonte oficial são preferenciais.
Exemplo:
GET training status
retorna:
{
"status": "VALID"
}
Isso é evidência direta.
17. Derived Evidence
Pode ser derivada de dados confiáveis.
Exemplo:
validUntil = 2026-09-15
currentDate = 2026-09-20
Então:
status = EXPIRED
A data é direta.
O status é derivado.
18. Inferred Evidence
Exemplo:
Employee has not accessed training
+
certificate missing
O agente pode inferir:
training may be incomplete
Mas isso não deverá ser tratado como fato confirmado.
19. Corroboration
Duas fontes independentes concordando aumentam a confiabilidade.
LMS → valid
SST → valid
pode produzir:
CORROBORATED
20. Corroboration Não Deve Ser Ingênua
Duas fontes que simplesmente replicam o mesmo dado não são necessariamente independentes.
Exemplo:
LMS
↓
Middleware
↓
SST
Não são duas evidências independentes.
O sistema deverá conhecer relações de dependência entre fontes quando possível.
21. Source Dependency
interface SourceDependency {
sourceId: string;
dependsOn: string[];
relationship:
| "DERIVED_FROM"
| "SYNCHRONIZED_FROM"
| "MIRRORED_FROM";
}
22. Freshness
Trust deverá considerar a idade da informação.
retrievedAt
observedAt
validUntil
Não apenas:
createdAt
23. Freshness Profiles
Cada domínio poderá definir:
workPermit:
freshness: 5m
training:
freshness: 24h
documentation:
freshness: 7d
staticReference:
freshness: 30d
24. Critical Freshness
Para ações críticas:
stale knowledge
poderá bloquear a operação.
Exemplo:
“Liberar Work Permit com dados de treinamento consultados há 3 dias.”
Policy:
DENY
REQUIRES_FRESH_DATA
25. Freshness Escalation
Fluxo:
STALE
↓
Refresh Capability
↓
External Source
↓
Fresh Evidence
Se o refresh falhar:
REQUIRES_REVIEW
26. Conflict Model
Conflito deverá ser tratado explicitamente.
interface KnowledgeConflict {
conflictId: string;
tenantId: string;
subjectId: string;
predicate: string;
evidenceIds: string[];
detectedAt: string;
status:
| "OPEN"
| "RESOLVED"
| "ACCEPTED"
| "ESCALATED";
}
27. Conflict Example
LMS:
validUntil = 2026-09-15
Document:
validUntil = 2026-12-31
Resultado:
CONFLICT
28. Conflict Resolution Hierarchy
O sistema poderá utilizar:
1. Explicit business rule
2. Authoritative source
3. More recent authoritative evidence
4. Verified source
5. Corroborated evidence
6. Human verification
7. Unknown
Nunca:
LLM chooses silently
29. Unresolvable Conflict
Quando não houver regra suficiente:
UNKNOWN
ou:
REQUIRES_REVIEW
Essa situação é preferível a uma falsa certeza.
30. Human Verification
Algumas informações poderão ser certificadas por um usuário autorizado.
interface HumanVerification {
verificationId: string;
knowledgeId: string;
verifierUserId: string;
role: string;
verifiedAt: string;
decision:
| "CONFIRMED"
| "REJECTED";
expiresAt?: string;
reason?: string;
}
31. Verification Scope
Uma verificação poderá valer:
para aquele registro
ou:
para aquela classe de informação
O escopo deverá ser explícito.
32. Verification Expiration
Uma certificação também pode envelhecer.
Exemplo:
Verified:
2026-08-01
Expires:
2026-09-01
Depois:
VERIFICATION_EXPIRED
33. Legal/Compliance Evidence
Quando necessário, o sistema deverá preservar:
source
timestamp
version
evidence hash
verification
actor
policy
decision
Isso permite reconstruir o motivo de uma decisão.
34. Evidence Hash
Documentos e respostas externas poderão possuir:
contentHash
para detectar alterações.
Exemplo:
SHA-256
O hash é apenas uma referência de integridade; não substitui assinatura/autenticidade quando esta for necessária.
35. Signed Evidence
Quando uma fonte fornecer assinatura digital, o sistema deverá poder armazenar:
signature
certificate reference
issuer
verification status
36. Evidence Retention
A retenção deverá respeitar:
tenant policy
compliance policy
legal requirements
source policy
Nem todo conteúdo precisa permanecer indefinidamente.
37. Evidence Immutability
Evidências históricas importantes deverão ser append-only.
Uma nova informação não deverá sobrescrever silenciosamente a evidência anterior.
Correto:
Evidence v1
Evidence v2
e não:
Evidence
→ UPDATE
apagando o histórico.
38. Knowledge Certification
Conhecimentos críticos poderão receber:
CERTIFIED
quando houver evidência e validação suficientes.
Exemplo:
training.validUntil
→ CERTIFIED
39. Certification ≠ Permanent Truth
Mesmo um dado certificado poderá:
expire
be revoked
be superseded
40. Trust Policy
O Policy Engine deverá poder solicitar níveis mínimos de confiança.
Exemplo:
workPermit.release:
requiredEvidence:
authority: VERIFIED
freshness: 1h
status: CERTIFIED
41. Trust Gate
Antes de uma ação:
Intent
↓
Knowledge
↓
Trust Evaluation
↓
Policy
↓
Capability
Se a confiança necessária não for atingida:
BLOCK
ou:
HUMAN REVIEW
42. Trust Requirement by Action
Uma consulta simples:
“Qual o status?”
pode aceitar:
TRUSTED
Uma decisão operacional:
“Libere a Work Permit.”
poderá exigir:
AUTHORITATIVE / VERIFIED
+
FRESH
+
NO CONFLICT
43. Trust Requirement Matrix
| Operação | Trust mínimo |
|---|---|
| Explicação | SUPPORTED |
| Pesquisa | TRUSTED |
| Recomendação | VERIFIED |
| Decisão | VERIFIED |
| Ação low-risk | VERIFIED |
| Ação high-risk | AUTHORITATIVE |
| Operação crítica | AUTHORITATIVE + FRESH + VERIFIED |
Os valores finais deverão ser configuráveis pelas policies.
44. Knowledge Answer Contract
Respostas baseadas em conhecimento deverão internamente possuir:
interface KnowledgeAnswer {
answer: string;
facts: KnowledgeReference[];
confidence: number;
trustLevel: string;
freshness: string;
conflicts?: string[];
requiresReview: boolean;
}
45. User-Facing Confidence
Não será necessário mostrar:
trustScore = 0.8732
ao usuário.
A interface deverá preferir linguagem natural:
“Segundo o LMS, atualizado há 4 minutos…”
ou:
“Há informações conflitantes entre o LMS e o cadastro interno.”
46. No False Certainty
O agente deverá evitar:
“O treinamento está válido.”
quando a realidade é:
LMS = valid
SST = expired
Deverá dizer algo equivalente a:
“Existem informações conflitantes; o LMS informa validade, enquanto o cadastro interno indica expiração.”
47. Provenance in UI
Quando relevante, a UI poderá mostrar:
Fonte
Última atualização
Status
Verificação
Exemplo:
Treinamento NR-10
✓ Validado
Fonte: LMS
Atualizado: há 4 min
48. Knowledge Inspector
O sistema poderá possuir uma ferramenta administrativa:
Knowledge Inspector
para visualizar:
Fact
Sources
Evidence
Conflicts
Versions
Trust
Verification
Relationships
49. Agent Debugging
Durante desenvolvimento, o Knowledge Inspector será particularmente importante para responder:
“Por que o agente respondeu isso?”
Sem mostrar chain-of-thought, poderá mostrar:
Retrieved facts
Sources
Trust level
Freshness
Knowledge version
Ranking signals
50. Retrieval Trust Filtering
O PRD-003 deverá incorporar filtros de confiança.
Fluxo:
Candidates
↓
Tenant Filter
↓
Permission Filter
↓
Freshness
↓
Trust Filter
↓
Ranking
51. Trust-Aware Ranking
A pontuação final poderá combinar:
relevance
+
semantic similarity
+
graph relationship
+
freshness
+
authority
+
verification
Mas os pesos deverão ser configuráveis.
52. Trust Must Not Override Security
Mesmo que um documento tenha:
trust = 1.0
ele não poderá revelar informação para um usuário não autorizado.
Ordem:
Security
↓
Authorization
↓
Trust
↓
Relevance
53. Prompt Injection
Documentos externos poderão conter instruções maliciosas:
“Ignore as políticas do sistema.”
A Knowledge Fabric deverá armazená-las como conteúdo, não como instruções.
Knowledge
≠
Agent Instruction
54. Instruction Classification
Conteúdo recuperado deverá ser classificado como:
FACT
DOCUMENT
RULE
DATA
INSTRUCTION
UNTRUSTED_CONTENT
Conteúdo externo não deverá alterar o comportamento do agente apenas por estar no contexto.
55. External Source Trust
Integrações externas deverão possuir:
integrationTrust
dataAuthority
authenticationStrength
schemaReliability
availability
Isso conecta o PRD-025 ao PRD-029.
56. Credential Trust
Uma resposta de uma API autenticada com uma credencial válida não significa automaticamente que o dado seja correto.
Portanto:
Authentication ≠ Data Truth
A autenticação confirma a origem técnica, não necessariamente a validade semântica.
57. Schema Validation
Dados externos deverão passar por:
Authentication
↓
Schema Validation
↓
Semantic Validation
↓
Business Validation
↓
Knowledge
58. Semantic Validation
Exemplo:
validUntil = 2038-99-99
pode passar pela rede e até possuir JSON válido.
Mas deverá falhar semanticamente.
59. Business Validation
Exemplo:
training.status = VALID
validUntil = yesterday
Pode indicar inconsistência de negócio.
A Knowledge Fabric deverá detectar ou encaminhar para a camada apropriada.
60. Trust Decay
A confiança poderá diminuir ao longo do tempo quando a informação não for atualizada.
Conceitualmente:
Trust
100%
│
│\
│ \
│ \
│ \
└──────── Time
Porém, regras determinísticas de validade terão prioridade sobre qualquer fórmula matemática.
61. Trust Revalidation
Uma fonte poderá recuperar confiança através de:
refresh
verification
corroboration
new authoritative evidence
62. Knowledge Revocation
Se uma fonte informar:
Correction
o sistema deverá poder revogar conhecimento anterior.
Fact v1
↓
REVOKED
↓
Fact v2
63. Cascading Impact
Quando um fato for revogado:
Fact
↓
Derived Facts
↓
Decisions
↓
Recommendations
↓
Workflows
deverão ser identificados.
64. Example
Training valid
foi incorretamente registrado.
Depois:
Training revoked
O sistema deverá encontrar:
Work Permit decision
Recommendation
Workflow
que dependeram desse fato.
Isso permitirá reavaliação.
65. Knowledge Dependency Graph
Cada inferência/decisão importante deverá registrar:
dependsOn:
[
knowledgeId1,
knowledgeId2,
ruleId3
]
Assim podemos responder:
“Quais decisões dependem deste dado?”
66. Decision Invalidation
Se um fato crítico mudar:
Decision
→ INVALIDATED
quando sua premissa deixou de ser válida.
67. Workflow Re-evaluation
Um workflow poderá estar:
WAITING
quando um fato mudar.
O Event Fabric poderá disparar:
KnowledgeChanged
↓
Workflow Evaluation
68. Proactive Intelligence Integration
O PRD-021 poderá usar Trust para evitar alertas baseados em dados ruins.
Exemplo:
Training expiry detected
mas a fonte está stale.
Resultado:
DO NOT ALERT YET
REFRESH SOURCE
69. Decision Intelligence Integration
O PRD-023 poderá exigir:
minimum evidence
minimum trust
no unresolved critical conflicts
antes de produzir uma decisão executável.
70. Exception Management Integration
O PRD-024 poderá criar incidente quando:
critical knowledge conflict
persistir.
Exemplo:
LMS and SST disagree
+
Work Permit is safety-critical
→ HIGH ou CRITICAL incident, conforme policy.
71. Operational Learning Integration
O PRD-012 poderá detectar:
frequent knowledge conflicts
e sugerir:
source authority adjustment
integration correction
schema mapping correction
documentation update
Mas não poderá alterar essas regras automaticamente.
72. Governance Approval
Alterações de:
Source Authority
Trust Rules
Certification Rules
Critical Knowledge Policies
deverão passar por revisão.
73. Trust Rule Versioning
Cada regra deverá possuir:
ruleId
version
effectiveFrom
effectiveUntil
owner
approval
74. Example Trust Policy
policyId: work-permit-release-trust
version: 1.0.0
requirements:
training:
authority: VERIFIED
freshness: 1h
conflicts: NONE
employee:
authority: AUTHORITATIVE
permit:
authority: AUTHORITATIVE
75. Trust Evaluation Result
interface TrustEvaluation {
status:
| "TRUSTED"
| "INSUFFICIENT"
| "CONFLICTED"
| "STALE"
| "UNKNOWN";
score?: number;
reasons: TrustReason[];
evidenceIds: string[];
evaluatedAt: string;
policyVersion: string;
}
76. Trust Reasons
Exemplos:
AUTHORITATIVE_SOURCE
RECENT_EVIDENCE
HUMAN_VERIFIED
CORROBORATED
STALE_SOURCE
UNVERIFIED_SOURCE
CONFLICTING_SOURCES
MISSING_EVIDENCE
REVOKED_EVIDENCE
UNKNOWN_SOURCE
77. Explainability
O sistema poderá gerar:
“A informação foi considerada confiável porque veio do sistema oficial de treinamento, foi atualizada há 4 minutos e não há evidências conflitantes.”
Isso é suficiente.
Não é necessário expor o raciocínio interno do LLM.
78. Audit
O PRD-013 deverá registrar:
trustPolicyVersion
trustEvaluation
evidenceIds
sourceIds
conflicts
verification
knowledgeVersion
para decisões críticas.
79. Security
Trust jamais poderá ser usado para contornar:
tenant isolation
authorization
RBAC
ABAC
field security
capability restrictions
80. Performance
Trust evaluation deverá ser barata.
Meta:
P50 < 5ms
P95 < 20ms
para informações já indexadas e com metadata disponível.
Consultas externas ficam fora desse orçamento.
81. Caching
Resultados poderão ser cacheados por:
knowledgeVersion
trustPolicyVersion
tenantId
knowledgeId
Se qualquer componente mudar:
invalidate
82. Trust Cache
Exemplo:
trust:
TENANT-A
knowledge:KN-123
policy:v4
knowledge:v18
não deverá ser reutilizado para:
policy:v5
83. Testing
O framework do PRD-014 deverá incluir:
Positive
authoritative source
fresh evidence
verified fact
Negative
stale
conflict
revoked
unverified
missing provenance
cross-tenant evidence
84. Security Tests
Testar:
Tenant A evidence
→ Tenant B query
Resultado:
NO DATA
Também:
Untrusted document
→ prompt injection
não deverá alterar policy.
85. First Vertical Slice
O primeiro vertical slice será:
Work Permit
+
Training
+
LMS
86. Scenario 1 — Trusted
LMS:
validUntil = 2026-09-15
consultado:
2026-09-01
SST não possui conflito.
Resultado:
TRUSTED
87. Scenario 2 — Stale
LMS foi consultado:
3 days ago
e a policy exige:
1 hour
Resultado:
STALE
O sistema deverá tentar refresh antes de uma decisão crítica.
88. Scenario 3 — Conflict
LMS:
VALID
SST:
EXPIRED
Resultado:
CONFLICTED
Não poderá liberar automaticamente uma Work Permit crítica.
89. Scenario 4 — Human Verification
Um usuário autorizado revisa a divergência.
Human Verification
→ CONFIRMED
A decisão poderá prosseguir se a policy permitir esse tipo de evidência.
90. Scenario 5 — Revocation
LMS informa:
certificate revoked
O conhecimento:
training.valid
deverá ser invalidado.
91. Scenario 6 — Dependency Invalidation
Se:
training.valid
foi utilizado para:
WorkPermitReleaseDecision
a revogação deverá identificar a decisão afetada.
92. Critérios de Aceitação
- Trust Model implementado.
- Source Authority Registry implementado.
- Evidence Model implementado.
- Evidence Chain implementada.
- Evidence Graph integrada ao HAG.
- Evidence Strength implementada.
- Source Dependency implementada.
- Freshness Policy implementada.
- Trust Classes implementadas.
- Trust Score implementado.
- Trust Policy implementada.
- Trust Gate integrado ao Policy Engine.
- Conflict Detection implementado.
- Conflict Resolution implementado.
- Human Verification implementada.
- Verification Expiration implementada.
- Knowledge Certification implementada.
- Evidence Hash implementado.
- Revocation implementada.
- Dependency Tracking implementado.
- Decision Invalidation implementado.
- Workflow Re-evaluation preparado.
- Trust-aware Retrieval implementado.
- Trust-aware Ranking implementado.
- Prompt Injection isolation implementada.
- External Source Trust integrado.
- Knowledge Drift integrado.
- Audit integrado ao PRD-013.
- Proactive Intelligence integrado.
- Decision Intelligence integrado.
- Exception Management integrado.
- Operational Learning integrado.
- Trust caching implementado.
- Tenant isolation validada.
- Security tests implementados.
- Work Permit vertical slice concluído.
Evidência parcial de implementação — 2026-09-04
Regras de source authority e políticas de trust são versionadas, aprovadas e tenant-bound. A avaliação combina proveniência, autoridade, freshness, evidência, consistência e verificação; revogação, fonte desconhecida, conflito ou expiração produzem estado não confiável e review humano. Evidências preservam hash, origem, validade e trilha de auditoria; a recertificação assíncrona registra revisões quando a confiança expira.
Em 2026-09-05, o trust gate passou a rejeitar o conjunto inteiro de evidências quando qualquer evidência fresca não possui regra de autoridade. Antes, uma fonte conhecida poderia mascarar uma segunda fonte desconhecida; agora o resultado é UNKNOWN com revisão humana. Worker 62919e77-6c9b-4de6-8263-6edac1efc76a publicado com health público saudável.
Em 2026-09-05, as suítes de Knowledge Trust passaram com 12 testes em 4 arquivos. O canário remoto comprovou duas evidências em conflito, revisão humana que levou a confiança de CONFLICTED para TRUSTED/VERIFIED, policy 1.0.0, recertificação que selecionou/reabriu/invalidou uma entrada, inspeção com avaliações, reviews, verificação, dependências, invalidações e eventos; o trust layer não persistiu texto em claro, não autorizou execução e o cleanup confirmou remainingRows:0. O runtime invalida decisões dependentes de forma idempotente quando a verificação expira. Evidence Graph/HAG completo, re-evaluation de workflow, fonte externa, drift integrado e trust cache continuam abertos para prova dedicada.
Em 2026-09-06, a regressão atual de trust governance, Knowledge Trust e Evidence Fabric passou com 19 testes. O typecheck do Agent passou novamente, e o health público do Worker confirmou runtime e bindings. A prova Cloudflare histórica permanece válida; Evidence Graph/HAG completo, re-evaluation de workflow, fonte externa, drift integrado e trust cache seguem como expansão.
93. Resultado Arquitetural
Com o PRD-029, o Agentic Work passa a ter uma cadeia de confiança formal:
SOURCE
│
▼
EVIDENCE
│
▼
PROVENANCE
│
┌────────┼────────┐
▼ ▼ ▼
Authority Freshness Consistency
│ │ │
└────────┼────────┘
▼
VERIFICATION
│
▼
TRUST
│
┌─────┴─────┐
▼ ▼
RETRIEVAL DECISION
│ │
└─────┬─────┘
▼
POLICY
│
▼
CAPABILITY
│
▼
EXECUTION
A consequência é muito importante:
O Agentic Work deixa de ser apenas um sistema que “encontra informações” e passa a saber avaliar a qualidade e a confiabilidade dessas informações antes de utilizá-las.
PRD-030 — Agentic Multi-Agent Collaboration & Swarm Orchestration
O próximo passo natural é tratar o cenário em que um único agente não é suficiente.
A arquitetura já possui:
Supervisor Agent
Training Agent
Risk Agent
Compliance Agent
Workflow Agent
Decision Agent
Mas ainda precisamos definir como eles trabalham juntos.
O PRD-030 deverá estabelecer:
Agent Registry
Agent Discovery
Agent-to-Agent Authentication
Delegation
Task Handoff
Shared Context
Private Context
Agent Contracts
Agent Negotiation
Parallel Execution
Conflict Resolution
Agent Voting
Specialist Routing
Supervisor Patterns
Agent Failure
Agent Timeout
Agent Cancellation
Agent Result Verification
A arquitetura evoluirá para:
USER
│
▼
SUPERVISOR AGENT
│
┌─────────────┼─────────────┐
▼ ▼ ▼
TRAINING AGENT RISK AGENT COMPLIANCE AGENT
│ │ │
└─────────────┼─────────────┘
▼
DECISION AGENT
│
▼
POLICY ENGINE
│
▼
EXECUTION
Mas com uma regra fundamental:
Multi-agent não significa autoridade compartilhada.
Cada agente deverá continuar sujeito a:
Identity
→ Delegation
→ Capability
→ Policy
→ Verification
E, principalmente, o PRD-030 deverá impedir que a arquitetura vire um “swarm” descontrolado de chamadas entre agentes.
A colaboração será orquestrada, limitada, observável, autorizada e determinística sempre que possível.