PRD-026 — Agentic Multi-Agent Orchestration & Specialist Agents

1. Objetivo

O PRD-026 define a arquitetura para evoluir o Agentic Work de um único agente operacional para um sistema multi-agent especializado, no qual diferentes agentes podem colaborar para executar tarefas complexas.

A arquitetura deverá permitir, por exemplo:

“Analise esta permissão de trabalho e diga se podemos liberá-la.”

Essa solicitação poderá envolver:

Supervisor Agent
    │
    ├── Work Permit Agent
    ├── Training Agent
    ├── Risk Agent
    ├── Compliance Agent
    └── Document Agent

Porém, esses agentes não terão autoridade independente.

Todos continuarão submetidos a:

Identity
    ↓
Tenant Isolation
    ↓
Policy Engine
    ↓
Capability Registry
    ↓
Audit
    ↓
Verification

2. Princípio Fundamental

O sistema deverá separar:

Especialização

“Qual agente possui conhecimento/capacidade adequada para resolver esta parte?”

de:

Autoridade

“Quem está autorizado a realizar esta operação?”

Especialização pertence ao Agent Orchestrator.

Autoridade continua pertencendo ao Policy Engine.

Agent Selection ≠ Authorization

Um agente especialista nunca poderá dizer:

“Eu sou o Training Agent, portanto posso alterar treinamentos.”

A alteração só ocorrerá se:

User
 ↓
Agent
 ↓
Capability
 ↓
Policy
 ↓
Authorization
 ↓
Execution

permitir.

3. Objetivos

O sistema deverá permitir:

decomposição de tarefas;
seleção dinâmica de especialistas;
execução paralela;
handoff entre agentes;
compartilhamento controlado de contexto;
isolamento de contexto sensível;
delegação de subtarefas;
agregação de resultados;
resolução de conflitos;
supervisão;
retry;
compensação;
cancelamento;
timeout;
prevenção de loops;
controle de custo;
auditoria completa.

4. Não Objetivos

O sistema não deverá permitir:

agentes criando agentes arbitrariamente;
agentes concedendo privilégios;
agentes modificando suas próprias policies;
agentes registrando capabilities sem aprovação;
agentes acessando APIs diretamente;
agentes compartilhando credenciais;
agentes ignorando o Policy Engine;
agentes alterando o próprio código em produção;
comunicação livre e ilimitada entre agentes.

5. Arquitetura

                         USER
                           │
                           ▼
                  Conversation Runtime
                           │
                           ▼
                    Intent Engine
                           │
                           ▼
                  Agent Supervisor
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
         Specialist A Specialist B Specialist C
              │            │            │
              └────────────┼────────────┘
                           ▼
                    Shared Task Graph
                           │
                           ▼
                 Capability Registry
                           │
                           ▼
                     Policy Engine
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
      Internal Runtime           External Gateway
             │                           │
             └─────────────┬─────────────┘
                           ▼
                       Verification
                           │
                           ▼
                       Event Fabric

6. Supervisor Agent

O Supervisor Agent será responsável por:

compreender a tarefa;
determinar se precisa de especialistas;
decompor a tarefa;
selecionar especialistas;
construir o plano;
distribuir subtarefas;
acompanhar resultados;
detectar conflitos;
solicitar revisão;
consolidar a resposta.

Ele não executará operações de negócio diretamente.

7. Specialist Agent

Um Specialist Agent representa uma especialização.

Exemplos:

work-permit-agent
training-agent
risk-agent
compliance-agent
document-agent
employee-agent
workflow-agent

Cada um possuirá:

interface AgentDefinition {
  agentId: string;
  version: string;

  name: string;

  description: string;

  domains: string[];

  capabilities: string[];

  knowledgeScopes: string[];

  inputSchema: JSONSchema;

  outputSchema: JSONSchema;

  allowedDelegations: string[];

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

8. Agent Registry

Assim como existe:

Capability Registry
Integration Registry
UI Registry

deverá existir:

Agent Registry

Ele será a fonte oficial dos agentes disponíveis.

Agent Registry
     │
     ├── Supervisor
     ├── Training Agent
     ├── Risk Agent
     ├── Compliance Agent
     └── Document Agent

9. Agent Discovery

O Supervisor não deverá enviar todos os agentes ao LLM.

Primeiro será realizado um filtro determinístico.

Intent
 ↓
Domain
 ↓
Required capabilities
 ↓
Knowledge scope
 ↓
Agent Registry
 ↓
Candidate Agents

Somente os candidatos relevantes serão apresentados ao modelo.

10. Agent Selection

A seleção poderá utilizar:

domain match
capability match
knowledge match
task type
historical success
latency
cost
availability
tenant configuration

Exemplo:

Task:
"Verifique treinamento NR-10"

Candidates:

Training Agent     0.98
Compliance Agent   0.72
Document Agent     0.31

O Training Agent será selecionado.

11. Agent Score

O score deverá ser explicável.

interface AgentSelectionScore {
  agentId: string;

  domainScore: number;
  capabilityScore: number;
  knowledgeScore: number;
  availabilityScore: number;
  costScore: number;

  finalScore: number;
}

O score não substitui autorização.

12. Agent Task

Toda delegação deverá gerar uma tarefa formal.

interface AgentTask {
  taskId: string;

  parentTaskId?: string;

  executionId: string;

  sourceAgentId: string;

  targetAgentId: string;

  tenantId: string;

  userId: string;

  objective: string;

  input: unknown;

  requiredCapabilities: string[];

  deadline?: string;

  priority: "LOW" | "NORMAL" | "HIGH" | "CRITICAL";

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

13. Agent Contract

A comunicação entre agentes deverá obedecer a um contrato.

Agent A
   │
   │ AgentTask
   ▼
Agent B
   │
   │ AgentResult
   ▼
Agent A

Nunca deverá ocorrer:

Agent A → Agent B → acesso arbitrário a banco/API

14. Agent Result

interface AgentResult {
  taskId: string;

  agentId: string;

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

  result: unknown;

  evidence: EvidenceReference[];

  confidence?: number;

  recommendations?: Recommendation[];

  requestedActions?: RequestedAction[];

  completedAt: string;
}

15. Evidence First

Agentes deverão retornar evidências sempre que possível.

Exemplo:

{
  "result": {
    "trainingValid": false
  },
  "evidence": [
    {
      "source": "lms",
      "trainingId": "NR10",
      "validUntil": "2026-08-15"
    }
  ]
}

Isso alimentará diretamente o PRD-023.

16. Fact ≠ Opinion

O Agent Result deverá distinguir:

FACT
INFERENCE
RECOMMENDATION
UNCERTAINTY

Exemplo:

FACT:
Treinamento expirou em 15/08.

INFERENCE:
Trabalhador não atende ao requisito atual.

RECOMMENDATION:
Não liberar a permissão.

UNCERTAINTY:
Não foi encontrado certificado atualizado no LMS.

17. Delegation Model

O Supervisor poderá criar:

Sequencial

A → B → C

Paralelo

       ┌→ A ─┐
Task ──┼→ B ─┼→ Aggregate
       └→ C ─┘

Condicional

A
 ↓
IF
 ├── true  → B
 └── false → C

18. Parallel Execution

Quando tarefas forem independentes:

Training Agent
Risk Agent
Document Agent

poderão executar simultaneamente.

Isso reduz:

latência total

de:

A + B + C

para aproximadamente:

max(A, B, C)

mais overhead de orquestração.

19. Dependency Graph

A execução deverá ser representada como DAG.

interface AgentTaskGraph {
  graphId: string;

  nodes: AgentTask[];

  edges: {
    from: string;
    to: string;
    condition?: string;
  }[];
}

Ciclos deverão ser rejeitados, salvo mecanismos explícitos de loop controlado.

20. Agent Handoff

Um agente poderá solicitar outro especialista.

Exemplo:

Work Permit Agent
       ↓
"Preciso verificar treinamento"
       ↓
Training Agent
       ↓
resultado
       ↓
Work Permit Agent

Mas o handoff deverá passar pelo Supervisor/Orchestrator.

O agente não deverá abrir uma cadeia arbitrária de chamadas.

21. Handoff Limit

Deverá existir:

maxDepth
maxTasks
maxHandoffs
maxExecutionTime
maxCost

Exemplo:

orchestration:
  maxDepth: 5
  maxTasks: 30
  maxHandoffs: 10

22. Loop Prevention

O sistema deverá detectar:

A → B → C → A

A → B → A → B

através de:

task lineage
agent history
capability history
correlationId
depth

23. Context Isolation

Nem todo contexto deverá ser compartilhado.

Exemplo:

User Context
        │
        ├── Work Permit Agent
        │
        ├── Training Agent
        │
        └── Medical Agent

O Medical Agent poderá receber apenas:

workerId
permitId
medical eligibility status

e não:

medical diagnosis
clinical notes

24. Context Projection

O Supervisor deverá criar uma projeção mínima do contexto.

interface AgentContextProjection {
  sourceContextId: string;

  targetAgentId: string;

  allowedFields: string[];

  redactedFields: string[];

  purpose: string;

  expiresAt?: string;
}

25. Least Context Principle

A regra será:

Um agente recebe apenas o contexto necessário para executar sua tarefa.

Isso reduz:

risco de vazamento;
tokens;
confusão;
prompt injection;
exposição de dados.

26. Tenant Isolation

Toda AgentTask deverá possuir:

tenantId
userId
sessionId
conversationId

Um agente não poderá:

Agent Tenant A
      ↓
query
      ↓
Tenant B

Mesmo se possuir capability tecnicamente compatível.

27. User Delegation

Uma tarefa iniciada pelo usuário deverá preservar a autoridade original.

User
 ↓
Supervisor
 ↓
Training Agent
 ↓
Capability
 ↓
Policy

O Training Agent não poderá receber mais privilégios que o usuário.

28. Service Delegation

Algumas tarefas poderão ser iniciadas pelo sistema.

Nesse caso:

Actor = SYSTEM

e deverão possuir uma policy explícita.

Exemplo:

TrainingExpirationScanner

poderá detectar vencimentos, mas não necessariamente alterar registros.

29. Agent Identity

Cada agente deverá possuir identidade técnica.

interface AgentPrincipal {
  agentId: string;
  agentVersion: string;

  executionId: string;

  parentAgentId?: string;

  delegationChain: string[];
}

A cadeia completa deverá estar disponível para auditoria.

30. Capability Boundary

Agente não possui “poderes implícitos”.

Exemplo:

Training Agent

poderá ter:

training.search
training.getStatus
training.getCertificate

Mas não:

workPermit.approve

a menos que isso seja explicitamente registrado e autorizado.

31. Agent Knowledge Scope

Cada agente também poderá possuir um escopo de conhecimento.

agentId: training-agent

knowledgeScopes:
  - training
  - certification
  - employee.training

Isso evita enviar todo o HAG para cada agente.

32. HAG Integration

O Agent Registry deverá estar conectado ao Knowledge Graph existente.

Agent
 ↓
Semantic IDs
 ↓
Knowledge Graph
 ↓
Documentation
 ↓
Capabilities

Exemplo:

training-agent
      │
      ├── training
      ├── employee.training
      └── certification

33. Dynamic Knowledge Retrieval

Quando o agente receber uma tarefa:

Task
 ↓
Knowledge Scope
 ↓
HAG
 ↓
Keyword/BM25
 ↓
Wikilinks
 ↓
Vectorize

seguindo o PRD-003.

Não deverá carregar uma base inteira de conhecimento no prompt.

34. Specialist Prompt

Cada agente poderá possuir instruções específicas:

Training Agent:
- interpretar validade de treinamentos;
- verificar requisitos;
- utilizar training capabilities;
- nunca aprovar Work Permit;
- nunca alterar policy.

Essas instruções serão complementares às policies, nunca superiores a elas.

35. Prompt Injection Protection

Dados provenientes de:

LMS;
documentos;
e-mails;
APIs;
usuários;
páginas externas;

serão tratados como dados, não instruções.

External Data
 ≠
Agent Instructions

36. Conflict Resolution

Dois agentes poderão discordar.

Exemplo:

Training Agent:
PASS

Compliance Agent:
FAIL

O Supervisor não deverá escolher arbitrariamente.

Deverá criar:

Decision
 ↓
Conflict
 ↓
Evidence comparison
 ↓
Policy / Rule evaluation
 ↓
Resolution

37. Authority of Evidence

As evidências deverão possuir autoridade.

Exemplo:

Government source
   >
Official SST record
   >
Verified external integration
   >
Unverified document
   >
LLM inference

A hierarquia deverá ser configurável por domínio.

38. Consensus

Consensus poderá ser utilizado somente quando fizer sentido.

Exemplo:

Risk Agent → HIGH
Compliance Agent → HIGH
Training Agent → PASS

O resultado poderá ser:

Training requirement = PASS
Overall release risk = HIGH

Não se deverá reduzir múltiplos fatos a uma votação simplista.

39. Decision Agent

Um agente especializado em decisão poderá consumir:

Facts
Rules
Risks
Constraints
Evidence

e produzir:

DecisionResult

seguindo o PRD-023.

40. Human Escalation

Se houver conflito material:

Agent A → PASS
Agent B → FAIL

e não existir regra determinística para resolver:

Decision Center

deverá receber uma solicitação.

41. Human-in-the-Loop

O sistema deverá suportar:

APPROVE
REJECT
REQUEST_INFORMATION
OVERRIDE
ASSIGN

Porém OVERRIDE deverá ser extremamente controlado.

Um humano também não deverá conseguir ultrapassar políticas técnicas críticas sem um mecanismo administrativo explicitamente autorizado.

42. Agent Approval ≠ User Approval

Um agente dizendo:

"approved"

não equivale a:

Human Approval

nem a:

Policy Authorization

São estados distintos.

43. Agentic Workflow Integration

O multi-agent deverá integrar-se ao PRD-019.

Exemplo:

Workflow
   │
   ▼
Supervisor
   │
   ├── Training Agent
   ├── Risk Agent
   └── Compliance Agent
   │
   ▼
Decision
   │
   ▼
Workflow Transition

44. Event Integration

O PRD-020 poderá disparar tarefas multi-agent.

Exemplo:

TrainingExpired
      ↓
Event Fabric
      ↓
Proactive Intelligence
      ↓
Supervisor
      ↓
Training Agent
      ↓
Risk Agent
      ↓
Work Permit Agent

45. Exception Handling

O PRD-024 continuará sendo responsável pelos erros.

Exemplo:

Training Agent
 ↓
External LMS
 ↓
TIMEOUT

O sistema poderá:

retry
wait
fallback
escalate

mas o agente não deverá inventar um resultado.

46. Partial Success

Exemplo:

Training Agent → SUCCESS
Risk Agent → SUCCESS
Document Agent → FAILED

O Supervisor deverá retornar:

PARTIAL

e indicar exatamente o que faltou.

47. Agent Fallback

Um agente poderá possuir fallback.

Training Agent A
       ↓
 unavailable
       ↓
Training Agent B

Porém o fallback deverá ser registrado e autorizado.

Não poderá simplesmente escolher qualquer LLM ou serviço.

48. Model Routing

Agentes diferentes poderão utilizar modelos diferentes.

Por exemplo:

Simple extraction
 → small/fast model

Complex decision support
 → stronger model

A seleção deverá ser governada por:

task complexity
risk
latency
cost
availability

49. Deterministic First

Mesmo no ambiente multi-agent:

Deterministic
    ↓
Structured retrieval
    ↓
Rules
    ↓
Existing capabilities
    ↓
LLM

O simples não deverá ser transformado em uma colaboração multi-agent desnecessária.

50. Agent Escalation

Um agente poderá solicitar escalonamento quando:

confidence < threshold
required capability unavailable
conflicting evidence
policy ambiguity
critical risk
external dependency unavailable

51. Cost Control

Cada task deverá possuir orçamento.

interface AgentBudget {
  maxTokens?: number;

  maxModelCalls?: number;

  maxExecutionTimeMs?: number;

  maxCost?: number;

  maxDelegations?: number;
}

Quando excedido:

STOP

ou:

HUMAN_REVIEW

conforme policy.

52. Agent Performance

O sistema deverá medir:

task latency
selection accuracy
success rate
handoff count
failure rate
cost
token usage
LLM calls
clarification rate

53. Agent Quality Metrics

Além das métricas gerais do PRD-014:

Agent Selection Accuracy
Agent Task Success Rate
Handoff Success Rate
Agent Conflict Rate
Agent Escalation Rate
Agent Fallback Rate
Agent Loop Rate

54. Observability

Cada task deverá gerar spans:

Supervisor
 ├── AgentSelection
 ├── AgentTask
 │    ├── Knowledge
 │    ├── Capability
 │    ├── Policy
 │    └── Execution
 └── Aggregation

Tudo deverá compartilhar:

traceId
correlationId
executionId

55. Audit

A auditoria deverá responder:

Qual agente pediu determinada operação?

Exemplo:

User
 ↓
Supervisor
 ↓
Compliance Agent
 ↓
Work Permit Agent
 ↓
workPermit.release
 ↓
Policy
 ↓
Human Approval
 ↓
Execution

A cadeia completa deverá ser registrada.

56. No Chain-of-Thought Logging

O sistema deverá registrar:

decision
evidence
confidence
reason codes
selected capability
policy result

mas não deverá armazenar raciocínio interno privado do modelo.

57. Agent Lifecycle

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

O lifecycle deverá integrar-se ao PRD-016.

58. Agent Versioning

Toda execução deverá registrar:

agentVersion
capabilityVersion
policyVersion
knowledgeVersion
uiManifestVersion
runtimeVersion
modelVersion

Isso permite reproduzir posteriormente o comportamento operacional.

59. Compatibility

Um agente poderá declarar dependências:

dependencies:
  capabilities:
    - training.getStatus@^2.0

  knowledge:
    - training@^4.0

  policies:
    - training-policy@^3.0

Uma release incompatível deverá ser bloqueada pelo Release Manager.

60. Agent Sandbox

Novos agentes deverão ser testados em sandbox:

Agent
 ↓
Simulation
 ↓
Mock Capabilities
 ↓
Mock External Systems

antes de acessar produção.

61. Evaluation Dataset

Cada agente deverá possuir casos de avaliação.

Exemplo para Training Agent:

valid training
expired training
missing training
duplicate training
future training
conflicting certificates
unknown employee

62. Security Evaluation

Deverão existir testes para:

cross-tenant request
privilege escalation
prompt injection
malicious external data
credential leakage
unauthorized capability
agent loop
delegation abuse
context leakage

63. Agent Kill Switch

O sistema deverá permitir desabilitar um agente individualmente:

training-agent
STATUS = DISABLED

Sem necessariamente desligar todo o Agentic Work.

64. Capability Kill Switch

Também deverá ser possível desligar uma capability:

training.external.update

sem desligar:

training.external.getStatus

65. Blast Radius

Cada agente deverá declarar seu potencial de impacto.

riskProfile:
  maxRisk: HIGH
  canMutate: true
  canExternalWrite: true
  canBulkOperate: false

Isso será usado pelo Policy Engine.

66. Multi-Agent Approval

Uma operação de alto risco poderá exigir:

Supervisor
 ↓
Specialist
 ↓
Decision
 ↓
Human
 ↓
Capability

Nunca:

Supervisor
 ↓
Specialist
 ↓
Specialist approves itself

67. Example — Work Permit Release

Usuário:

“Analise a permissão WP-10231 e libere se estiver tudo correto.”

O Supervisor cria:

Task 1:
Work Permit Agent

paralelamente:

Task 2:
Training Agent

Task 3:
Risk Agent

Task 4:
Compliance Agent

Resultados:

Training → PASS
Risk → PASS
Compliance → PASS
Work Permit → READY

O Decision Engine consolida:

Decision:
RECOMMENDED_FOR_RELEASE

Policy:

ALLOW

Caso a capability exija confirmação:

CONFIRMATION_REQUIRED

Usuário:

“Sim.”

Então:

workPermit.release
 ↓
verification
 ↓
SUCCESS

68. Exemplo de Conflito

Training Agent
→ PASS

Compliance Agent
→ FAIL

O Supervisor não executará:

release

automaticamente.

Ele produzirá:

Decision:
REQUIRES_REVIEW

com:

Evidence A
Evidence B
Conflict
Applicable rules
Recommended resolution

e enviará ao Decision Center.

69. Agent-to-Agent Security Model

Toda mensagem entre agentes deverá ser:

authenticated
authorized
tenant-bound
schema-validated
correlated
audited
time-bounded

70. Architecture Rule

Uma regra arquitetural deverá ser aplicada em todo o sistema:

Agent-to-agent communication is orchestration, not authorization.

Ou seja:

Agent A
 ↓
Agent B

não concede autorização.

Somente:

Policy Engine

pode autorizar a operação.

71. Primeiro Vertical Slice

A primeira implementação deverá utilizar o domínio Work Permit.

Supervisor

work-permit-supervisor

Specialists

work-permit-agent
training-agent
risk-agent
compliance-agent

Capabilities

Reutilizar as capabilities existentes:

workPermit.get
workPermit.search
workPermit.updateValidity
training.getStatus
risk.evaluate
workPermit.release

72. Primeiro Caso de Uso

Comando:

“Analise esta permissão e me diga se ela pode ser liberada.”

Fluxo:

Conversation
 ↓
Intent
 ↓
Supervisor
 ↓
┌─────────────────────┐
│ Training Agent      │
│ Risk Agent          │
│ Compliance Agent    │
└─────────────────────┘
 ↓
Evidence Aggregation
 ↓
Decision Engine
 ↓
Recommendation

Não haverá execução automática na primeira versão.

O objetivo inicial é validar:

delegation
context isolation
evidence
aggregation
conflict resolution
latency
audit

73. Segunda Fase

Adicionar:

“Se estiver tudo correto, libere.”

Agora:

Analysis
 ↓
Decision
 ↓
Policy
 ↓
Confirmation
 ↓
workPermit.release
 ↓
Verification

74. Critérios de Aceitação

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

O modelo de agentes declara identidade, versão, domínios, capabilities, escopos de conhecimento, delegações permitidas e lifecycle. O registry de capabilities bloqueia lifecycle DISABLED; controles de emergência persistentes por tenant, capability ou plataforma são reavaliados antes de uma mutação de workflow. A Policy Engine exige escalonamento para ações que ultrapassam blast radius, e o dispatcher falha fechado antes de executar a chamada interna.

Em 2026-09-05, os contratos de orquestração e capability passaram com 39 testes em 8 arquivos. O canário de swarm confirmou duas tarefas, conflito sob revisão, dois handoffs, validador independente, contexto apenas por hash, cancelamento/timeout persistentes, isolamento e cleanup remainingRows:0, sempre sem autoridade de execução. O AgentRegistry.discover foi também revalidado isoladamente (6 testes e typecheck): retorna somente especialistas ACTIVE que atendem simultaneamente a domínio e capability solicitados, preservando os escopos declarados de contexto. A seleção explícita também foi implementada: filtra especialistas ativos por domínio, capability e escopo de conhecimento, calcula scores explicáveis de domínio, capability, conhecimento, disponibilidade e custo, e retorna uma escolha determinística sem autoridade de execução. O workflow durável de análise de Work Permit também foi revalidado (9 testes e typecheck): dispara em paralelo os quatro especialistas independentes, persiste seus resultados e somente então agrega a evidência, sem conceder autoridade de execução. O AgentSandbox executa somente respostas mockadas clonadas, sem binding de produção, sem persistência e sem autoridade; capabilities não registradas falham fechadas. O adaptador de avaliação conecta cada caso versionado de agente ao evaluateSuite do PRD-014, executando a capability mockada e preservando gates de regressão e segurança. O canário de LMS em produção confirmou o slice inicial completo: análise de Work Permit com quatro especialistas e recomendação, rota de revisão por evidência insuficiente, isolamento de contexto, integração verificada e cleanup remainingRows:0; a primeira fase não executa a liberação automaticamente.

Em 2026-09-06, a regressão atual do workflow, análise de Work Permit, rota de análises e delegações passou com 14 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 já registrado; esta validação atual confirmou os contratos unitários mais próximos.

75. Resultado Arquitetural

Com o PRD-026, o Agentic Work deixa de ser conceitualmente:

"um chatbot que executa ações"

e passa a ser:

             AGENTIC WORKFORCE
                     │
             ┌───────┴───────┐
             │   SUPERVISOR │
             └───────┬───────┘
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
   Specialist    Specialist    Specialist
       │             │             │
       └─────────────┼─────────────┘
                     ▼
               DECISION ENGINE
                     │
               POLICY ENGINE
                     │
             CAPABILITY RUNTIME
                     │
        ┌────────────┴────────────┐
        ▼                         ▼
    INTERNAL                  EXTERNAL
    SYSTEMS                   SYSTEMS

A consequência mais importante é que podemos agora construir agentes especialistas por domínio sem fragmentar segurança, identidade, auditoria e governança.

PRD-027 — Agentic Identity, Delegation & Credentialed Agency

O próximo PRD deverá resolver uma questão que agora se torna fundamental:

Quem é o agente quando ele age em nome de alguém?

Precisaremos formalizar a diferença entre:

Human Identity
       ↓
User Session
       ↓
Agent Identity
       ↓
Delegated Authority
       ↓
Capability
       ↓
External Credential

O PRD-027 deverá definir identidade de agentes, workload identity, delegação de autoridade, OAuth/OIDC, service-to-service authorization, tokens de curta duração, credential vaulting, credential rotation, user delegation, tenant delegation, scopes, audience, consentimento, step-up authentication, impersonation control, service accounts, mTLS, external identity mapping, revogação e a cadeia criptograficamente verificável de “quem autorizou o quê”.

Isso será especialmente importante agora que o PRD-025 permite ao Agentic Work atuar em sistemas externos e o PRD-026 permite que múltiplos agentes colaborem.

1. Objetivo​

2. Princípio Fundamental

Especialização​

Autoridade​

3. Objetivos

4. Não Objetivos

5. Arquitetura

6. Supervisor Agent

7. Specialist Agent

8. Agent Registry

9. Agent Discovery

10. Agent Selection

11. Agent Score

12. Agent Task

13. Agent Contract

14. Agent Result

15. Evidence First

16. Fact ≠ Opinion

17. Delegation Model

Sequencial​

Paralelo​

Condicional​

18. Parallel Execution

19. Dependency Graph

20. Agent Handoff

21. Handoff Limit

22. Loop Prevention

23. Context Isolation

24. Context Projection

25. Least Context Principle

26. Tenant Isolation

27. User Delegation

28. Service Delegation

29. Agent Identity

30. Capability Boundary

31. Agent Knowledge Scope

32. HAG Integration

33. Dynamic Knowledge Retrieval

34. Specialist Prompt

35. Prompt Injection Protection

36. Conflict Resolution

37. Authority of Evidence

38. Consensus

39. Decision Agent

40. Human Escalation

41. Human-in-the-Loop

42. Agent Approval ≠ User Approval

43. Agentic Workflow Integration

44. Event Integration

45. Exception Handling

46. Partial Success

47. Agent Fallback

48. Model Routing

49. Deterministic First

50. Agent Escalation

51. Cost Control

52. Agent Performance

53. Agent Quality Metrics

54. Observability

55. Audit

56. No Chain-of-Thought Logging

57. Agent Lifecycle

58. Agent Versioning

59. Compatibility

60. Agent Sandbox

61. Evaluation Dataset

62. Security Evaluation

63. Agent Kill Switch

64. Capability Kill Switch

65. Blast Radius

66. Multi-Agent Approval

67. Example — Work Permit Release

68. Exemplo de Conflito

69. Agent-to-Agent Security Model

70. Architecture Rule

71. Primeiro Vertical Slice

Supervisor​

Specialists​

Capabilities​

72. Primeiro Caso de Uso

1. Objetivo

Especialização

Autoridade

Sequencial

Paralelo

Condicional

Supervisor

Specialists

Capabilities

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