PRD-032 — Agentic Planning Intelligence & Dynamic Plan Optimization

1. Objetivo

O PRD-032 define a camada responsável por construir, avaliar, otimizar e adaptar planos de execução do Agentic Work.

Até aqui, a arquitetura já possui:

Intent Engine;
Capability Registry;
Planner;
Policy Engine;
Knowledge Fabric;
Trust;
Workflow;
Event Fabric;
Multi-Agent Collaboration;
Communication Fabric;
Exception Management;
Observability;
Audit.

O Planner atual consegue transformar um Intent em um plano.

O PRD-032 evolui essa capacidade para:

determinar a melhor maneira de alcançar um objetivo, considerando dependências, tempo, custo, risco, confiança, recursos disponíveis, capacidades dos agentes e restrições de negócio.

2. Problema

Um plano simples pode ser:

Intent
 ↓
Capability A
 ↓
Capability B
 ↓
Capability C

Mas frequentemente existem alternativas:

                ┌── Capability A ──┐
Intent ─────────┼── Capability B ──┼── Result
                └── Capability C ──┘

Ou:

A ──► B ──► D
     │
     └──► C ──► D

Nesse cenário, o sistema precisa decidir:

quais capacidades utilizar;
quais agentes utilizar;
quais operações podem ocorrer em paralelo;
qual sequência minimiza latência;
qual alternativa apresenta menor risco;
qual fonte possui maior confiança;
quando fazer fallback;
quando replanejar;
quando parar e pedir intervenção humana.

3. Objetivo arquitetural

A arquitetura passa de:

Intent
 ↓
Plan
 ↓
Execute

para:

Intent
 ↓
Understand
 ↓
Discover
 ↓
Generate Alternatives
 ↓
Evaluate
 ↓
Optimize
 ↓
Policy
 ↓
Approve
 ↓
Execute
 ↓
Monitor
 ↓
Replan when necessary

4. Princípio fundamental

O Planning Intelligence poderá otimizar o caminho até o objetivo.

Não poderá alterar:

permissões;
políticas;
regras legais;
segregação de funções;
limites de segurança;
requisitos obrigatórios;
autoridade do usuário;
escopo da delegação.

Portanto:

Optimization
     ↓
Policy constraints
     ↓
Allowed Plan Space

e nunca:

Optimization
     ↓
Change Policy

5. Planning vs Execution

É fundamental separar:

Planning

Decide:

O que devemos fazer e em qual ordem?

Execution

Realiza:

Execute a capacidade X.

Policy

Determina:

É permitido executar X?

Verification

Determina:

O resultado esperado realmente aconteceu?

6. Arquitetura

                       INTENT
                          │
                          ▼
                  ┌───────────────┐
                  │ Plan Context  │
                  └───────┬───────┘
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
      Knowledge       Capability        Workflow
       Fabric           Registry         State
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                  Constraint Engine
                          │
                          ▼
                  Plan Generator
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
          Plan A        Plan B        Plan C
             │            │            │
             └────────────┼────────────┘
                          ▼
                    Plan Evaluator
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
       Risk             Cost             Latency
        │                 │                 │
        └─────────────────┼─────────────────┘
                          ▼
                   Plan Optimizer
                          │
                          ▼
                    Policy Engine
                          │
                          ▼
                    Approved Plan
                          │
                          ▼
                  Execution Engine

7. Plan Context

O planejamento deverá trabalhar sobre um snapshot contextual.

interface PlanContext {
  tenantId: string;
  userId: string;
  conversationId?: string;

  intentId: string;

  uiContext?: SemanticUIContext;

  workflowContext?: WorkflowContext;

  knowledgeVersion: string;

  capabilityVersion: string;

  policyVersion: string;

  availableAgents: string[];

  constraints: PlanningConstraint[];

  deadline?: string;

  objective: PlanningObjective;
}

8. Planning Objective

O objetivo deverá ser explícito.

interface PlanningObjective {
  type:
    | "COMPLETE_TASK"
    | "MINIMIZE_LATENCY"
    | "MINIMIZE_COST"
    | "MINIMIZE_RISK"
    | "MAXIMIZE_CONFIDENCE"
    | "BALANCED";

  weights?: {
    latency?: number;
    cost?: number;
    risk?: number;
    confidence?: number;
  };
}

9. Default Objective

Quando o usuário não especificar preferência, a ordem padrão será:

Segurança
Policy compliance
Correção
Verificação
Confiabilidade
Latência
Custo

Nunca:

custo > segurança

10. Planning Constraints

As restrições podem ser:

SECURITY
AUTHORIZATION
BUSINESS_RULE
TEMPORAL
RESOURCE
DEPENDENCY
COST
LATENCY
DATA
TENANT
WORKFLOW
HUMAN_APPROVAL

11. Hard Constraints

Uma hard constraint não pode ser violada.

Exemplo:

workPermit must be APPROVED
before RELEASE

O planner não poderá produzir:

RELEASE
 ↓
APPROVE

12. Soft Constraints

Uma soft constraint pode influenciar o ranking.

Exemplo:

prefer lower latency

Se impossível, outro plano ainda poderá ser escolhido.

13. Constraint Model

interface PlanningConstraint {
  id: string;

  type: string;

  hard: boolean;

  expression: string;

  sourceRef?: string;

  priority: number;
}

14. Capability Discovery

O planner não deverá considerar todas as capabilities existentes.

Deverá primeiro filtrar:

Intent
 ↓
Domain
 ↓
Entity
 ↓
Action
 ↓
Policy scope
 ↓
Candidate capabilities

15. Candidate Capability

Cada candidato deverá informar:

interface CandidateCapability {
  capabilityId: string;

  version: string;

  agentId?: string;

  estimatedLatencyMs?: number;

  estimatedCost?: number;

  riskLevel: string;

  confidence: number;

  prerequisites: string[];

  guarantees: string[];
}

16. Capability Equivalence

Duas capabilities poderão realizar a mesma finalidade:

training.getStatus.v1
training.getStatus.cached.v1
training.getStatus.external.v1

O planner poderá escolher entre elas.

17. Não Confundir Equivalência com Substituição

Uma capability só poderá substituir outra se:

o output for compatível;
as pré-condições forem compatíveis;
a política permitir;
o nível de confiança for suficiente;
o resultado puder ser verificado.

18. Plan Representation

interface ExecutionPlan {
  planId: string;

  intentId: string;

  version: string;

  objective: PlanningObjective;

  steps: ExecutionStep[];

  dependencies: PlanDependency[];

  score: PlanScore;

  riskLevel: string;

  requiresConfirmation: boolean;

  status:
    | "DRAFT"
    | "EVALUATED"
    | "APPROVED"
    | "EXECUTING"
    | "COMPLETED"
    | "INVALIDATED";
}

19. Plan as DAG

O plano deverá ser representado como um DAG:

A
├──► B
└──► C
      │
      ▼
      D

Isso permite paralelismo.

20. Sequential Plan

A → B → C → D

deverá ser usado quando dependências realmente exigirem ordem.

21. Parallel Plan

Se:

B não depende de C
C não depende de B

o planner poderá produzir:

       ┌── B ──┐
A ─────┤       ├── D
       └── C ──┘

22. Critical Path

O planner deverá identificar:

criticalPath

para estimar a latência mínima do plano.

Exemplo:

A 100ms
B 500ms
C 100ms
D 100ms

Se B e C forem paralelos:

100 + max(500,100) + 100
= 700ms

e não:

100 + 500 + 100 + 100
= 800ms

23. Parallelism Safety

Paralelismo somente será permitido quando:

não houver dependência;
não houver conflito de recursos;
não houver conflito de escrita;
não houver restrição de ordem;
policy permitir;
APIs suportarem concorrência.

24. Resource Conflict

Exemplo:

A → update employee
B → delete employee

não deverão executar paralelamente.

25. Optimistic Concurrency

Quando duas operações alterarem o mesmo recurso:

resourceVersion
etag
revision

deverá ser utilizado.

26. Plan Alternatives

O planner deverá gerar alternativas quando houver mais de uma solução válida.

Exemplo:

Plan A
Risk = LOW
Latency = 800ms
Cost = 1

Plan B
Risk = LOW
Latency = 400ms
Cost = 2

Plan C
Risk = MEDIUM
Latency = 200ms
Cost = 1

27. Plan Score

interface PlanScore {
  correctness: number;

  safety: number;

  confidence: number;

  risk: number;

  latency: number;

  cost: number;

  overall: number;
}

28. Score não substitui Policy

Um plano com:

overall = 0.99

mas:

policy = DENY

será descartado.

29. Plan Filtering

A ordem correta será:

Generate
 ↓
Hard Constraints
 ↓
Authorization
 ↓
Policy
 ↓
Safety
 ↓
Evaluation
 ↓
Optimization

30. LLM no Planning

O LLM poderá ajudar quando o problema for:

semanticamente complexo;
pouco estruturado;
com alternativas difíceis de descobrir;
dependente de linguagem natural.

Mas o LLM não deverá receber liberdade para criar capabilities inexistentes.

31. Structured Planner Output

Quando LLM for usado:

{
  "objective": "COMPLETE_TASK",
  "steps": [
    {
      "capabilityId": "training.getStatus",
      "input": {
        "employeeId": "EMP-104"
      }
    }
  ]
}

Depois:

JSON Schema
 ↓
Capability Registry
 ↓
Policy

32. Deterministic First

Para tarefas conhecidas:

Intent
 ↓
Template / deterministic planner

antes de:

LLM planner

Isso reduz:

latência;
custo;
variabilidade;
risco.

33. Plan Templates

Processos recorrentes poderão possuir templates.

Exemplo:

workPermit.release

template:

verify employee
verify training
evaluate risk
evaluate compliance
release
verify release

34. Template Adaptation

O template poderá ser adaptado.

Exemplo:

training already verified

Então:

skip training verification

desde que a evidência ainda seja válida.

35. Plan Cache

Planos determinísticos poderão ser cacheados.

A chave deverá considerar:

intent
entity
workflow state
capability version
policy version
knowledge version
tenant

36. Never Reuse Stale Plan

Um plano armazenado não deverá ser reutilizado quando:

policy changed
capability changed
resource changed
workflow changed
knowledge became stale
authorization changed

37. Plan Fingerprint

Cada plano deverá possuir fingerprint:

planFingerprint =
hash(
  intent +
  steps +
  dependencies +
  capabilityVersion +
  policyVersion +
  knowledgeVersion
)

38. Dynamic Replanning

Durante a execução:

Plan
 ↓
Step A
 ↓
unexpected state
 ↓
Replanner

O sistema poderá recalcular apenas a parte afetada.

39. Partial Replanning

Preferir:

A → B → [C → D → E]

Se C falhar, recalcular:

[C → D → E]

em vez de reconstruir tudo.

40. Replanning Triggers

Replanning poderá ocorrer quando:

RESOURCE_STATE_CHANGED
CAPABILITY_UNAVAILABLE
POLICY_CHANGED
KNOWLEDGE_CHANGED
TIMEOUT
EXTERNAL_FAILURE
NEW_EVIDENCE
USER_CORRECTION
WORKFLOW_CHANGED

41. Replanning Safety

Replanning não poderá:

remover uma etapa obrigatória;
ignorar policy;
reduzir requisitos de segurança;
reutilizar autorização expirada;
ignorar confirmação necessária.

42. Plan Invalidation

Um plano deverá ser invalidado quando uma condição essencial mudar.

interface PlanInvalidation {
  reason:
    | "POLICY_CHANGED"
    | "RESOURCE_CHANGED"
    | "CONTEXT_STALE"
    | "CAPABILITY_CHANGED"
    | "KNOWLEDGE_CHANGED"
    | "AUTHORITY_CHANGED";
}

43. User Confirmation

Se o plano mudar significativamente após confirmação:

old plan
 ↓
replanning
 ↓
materially different plan

a confirmação deverá ser invalidada.

44. Material Change

Exemplo:

Usuário autorizou:

alterar validade de WP-1001

O novo plano tenta:

alterar validade de 100 work permits

Isso exige nova autorização/confirmação.

45. Blast Radius

O planner deverá calcular:

affectedEntities
affectedRecords
affectedTenants
affectedSystems

46. Batch Optimization

Para:

1000 records

o planner poderá escolher:

batch size = 50

em vez de:

1000 individual requests

desde que a capability permita.

47. Batch Safety

O tamanho do batch deverá estar subordinado a:

policy
capability limits
transaction limits
blast radius

48. Cost Optimization

O planner poderá considerar:

API calls
LLM calls
Vector queries
external calls
compute
storage

49. LLM Cost

Se dois planos forem equivalentes:

Plan A = 0 LLM
Plan B = 2 LLM

o sistema deverá preferir A, salvo justificativa funcional.

50. Latency Optimization

O planner deverá considerar:

estimatedLatency
queueLatency
networkLatency
externalLatency
LLMLatency

51. External Service Penalty

Serviços externos poderão possuir:

reliability
latency
cost
availability

e isso poderá influenciar o ranking.

52. Trust Optimization

Quando houver múltiplas fontes:

Internal DB
LMS
Document
External API

o planner deverá considerar o Trust Score definido no PRD-029.

53. Confidence Threshold

Uma tarefa crítica poderá exigir:

confidence >= 0.95

Se não atingir:

REQUIRES_REVIEW

54. Unknown State

O planner não deverá transformar:

UNKNOWN

em:

FALSE

nem:

TRUE

sem regra explícita.

55. Temporal Planning

O planner deverá considerar:

deadline
validFrom
validUntil
business hours
workflow timers
external availability

56. Deadline

Se:

deadline = 10:00

e o plano estimado terminar às:

10:05

deverá ser considerado inviável.

57. Alternative Under Deadline

O planner poderá buscar:

Plan A = 8 min
Plan B = 3 min
Plan C = 12 min

e escolher B se cumprir as demais constraints.

58. Human Availability

Alguns planos dependerão de:

human approval

O planner poderá estimar:

WAITING_HUMAN

mas não deverá fingir que essa etapa foi concluída.

59. Human-in-the-Loop Planning

Exemplo:

Prepare recommendation
 ↓
Human review
 ↓
Capability execution

pode ser preferível a:

automatic execution

quando o risco exigir.

60. Agent Selection

Quando vários agentes puderem executar uma tarefa:

agent.training.fast
agent.training.standard
agent.training.external

o planner poderá selecionar o melhor.

Critérios:

capability
authorization
trust
health
latency
cost
tenant
version

61. Agent Affinity

Alguns workflows poderão possuir afinidade:

workflow X
 → agent A

para preservar:

contexto;
cache;
continuidade;
especialização.

62. Agent Fallback

Se:

Agent A unavailable

o planner poderá usar:

Agent B

somente se B for uma alternativa registrada e autorizada.

63. No Arbitrary Fallback

O LLM não poderá decidir:

“O serviço falhou, vou chamar outra API qualquer.”

Fallback deverá existir no Registry.

64. Planning Under Failure

O planner deverá considerar falhas previstas:

primary capability
 ↓ failure
fallback capability

65. Plan Robustness

Um plano poderá receber score de robustez baseado em:

dependency count
single points of failure
external dependencies
retryability
verification availability

66. Single Point of Failure

Um plano que depende de:

external API X

poderá ser menos robusto que:

internal source
+
cached verified evidence

quando permitido.

67. Plan Simulation

Antes de executar operações críticas:

Plan
 ↓
Simulation
 ↓
Impact
 ↓
Policy
 ↓
Approval

68. What-If Planning

O sistema poderá responder:

“O que aconteceria se eu liberasse esta Work Permit?”

sem executar.

Resultado:

SIMULATION

deverá ser claramente identificado como não executado.

69. Dry Run

Cada capability que suportar dry-run deverá informar isso no Registry.

interface CapabilityExecutionMode {
  supportsDryRun: boolean;
}

70. Plan Explainability

O sistema deverá conseguir explicar:

Plano escolhido
Alternativas descartadas
Principais restrições
Risco
Confiança
Custo estimado
Latência estimada

Não deverá expor chain-of-thought.

71. Example Explanation

Escolhi o Plano A porque:

• atende todas as regras obrigatórias;
• utiliza uma fonte de alta confiança;
• não requer aprovação adicional;
• possui menor risco;
• pode executar duas verificações em paralelo.

Plano B foi descartado porque depende de uma integração externa indisponível.

72. Plan Comparison

O sistema deverá suportar:

Plan A
Plan B
Plan C

com comparação estruturada:

Critério	Plano A	Plano B	Plano C
Segurança	Alta	Alta	Média
Confiança	0,98	0,96	0,89
Latência	800 ms	450 ms	300 ms
Custo	Baixo	Médio	Baixo
Risco	Baixo	Baixo	Médio

73. Policy Integration

O pipeline definitivo será:

Plan Generation
 ↓
Hard Constraints
 ↓
Trust
 ↓
Risk
 ↓
Optimization
 ↓
Policy
 ↓
Confirmation
 ↓
Execution

74. Policy Changes During Execution

Se a policy mudar enquanto o plano estiver executando:

Policy version old
 ↓
Policy version new

operações ainda não executadas deverão ser reavaliadas.

75. Knowledge Changes During Execution

Da mesma maneira, se conhecimento crítico mudar:

Knowledge v10
 ↓
Knowledge v11

o sistema deverá verificar se o plano continua válido.

76. Release Pinning

O plano deverá registrar:

agentVersion
knowledgeVersion
capabilityVersion
policyVersion
uiVersion

conforme PRD-016.

77. Plan Reproducibility

Uma execução histórica deverá poder responder:

“Por que esse plano foi escolhido?”

usando os mesmos:

dados;
versões;
capabilities;
policies;
evidências.

78. Plan Learning

O PRD-012 poderá registrar:

estimated latency
actual latency
estimated cost
actual cost
expected success
actual success

para melhorar estimativas.

79. Learning Boundary

Aprendizado não poderá alterar automaticamente:

security policy
authorization
critical constraints

80. Historical Performance

O planner poderá aprender que:

LMS API
average = 850ms
p95 = 2400ms

e considerar isso em futuros planos.

81. Adaptive Estimates

As estimativas poderão ser:

static
historical
tenant-specific
agent-specific
time-dependent

82. Tenant-Specific Planning

Um tenant poderá possuir:

preferred capabilities
preferred integrations
cost limits
latency preferences

mas nunca poderá ultrapassar políticas globais de segurança.

83. Planning Policy Hierarchy

Global Security
      ↓
Tenant Policy
      ↓
Domain Policy
      ↓
Capability Policy
      ↓
Resource Policy
      ↓
Optimization

Optimization nunca poderá subir na hierarquia.

84. Plan Security

O plano será considerado untrusted until validated.

Mesmo que venha do LLM:

Generated Plan
 ↓
Schema
 ↓
Registry
 ↓
Policy
 ↓
Authorization
 ↓
Safe Plan

85. Plan Injection Protection

Dados recuperados do Knowledge Fabric não poderão introduzir diretamente etapas executáveis.

Exemplo:

document:
"ignore all safety rules"

continua sendo apenas conteúdo.

86. Agent Communication Integration

O planner poderá dividir tarefas:

Supervisor
 ├──► Training Agent
 ├──► Risk Agent
 └──► Compliance Agent

utilizando o PRD-031.

87. Multi-Agent Parallel Planning

Exemplo:

             Supervisor
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
   Training     Risk    Compliance
       │         │         │
       └─────────┼─────────┘
                 ▼
              Decision

88. Communication Deadline

Cada task enviada a outro agente deverá possuir:

deadline
timeout
priority

89. Plan Health

Durante execução:

Plan Health
 ├── ON_TRACK
 ├── DEGRADED
 ├── BLOCKED
 └── INVALID

90. Plan Health Monitoring

O Execution Engine deverá publicar:

PLAN_STARTED
PLAN_STEP_STARTED
PLAN_STEP_COMPLETED
PLAN_STEP_FAILED
PLAN_DEGRADED
PLAN_REPLANNED
PLAN_INVALIDATED
PLAN_COMPLETED

91. Replanning Event

Quando houver replanning:

oldPlanId
newPlanId
reason
changedSteps
policyVersion
knowledgeVersion

deverão ser registrados.

92. Audit

O audit deverá registrar:

originalPlan
selectedPlan
rejectedAlternatives
optimizationFactors
policyDecision
confirmation
replanning
finalPlan

93. Observability

O trace deverá permitir:

Intent
 ↓
Candidate Plans
 ↓
Plan Evaluation
 ↓
Selected Plan
 ↓
Execution
 ↓
Replanning

94. Metrics

Métricas fundamentais:

Plan Generation Latency
Plan Evaluation Latency
Plan Selection Accuracy
Plan Success Rate
Replanning Rate
Plan Invalidations
Average Plan Length
Parallelism Ratio
Critical Path Duration
Estimated vs Actual Latency
Estimated vs Actual Cost
Fallback Rate

95. Optimization Metrics

Também:

LLM Avoidance
Average LLM Calls/Plan
Cost Saved
Latency Saved
Failed Executions Avoided

96. Safety Metrics

Obrigatoriamente:

Policy Bypass = 0
Unauthorized Plan = 0
Unsafe Plan Execution = 0
Cross-Tenant Plan = 0
Unverified Critical Execution = 0

97. Testing

O framework do PRD-014 deverá testar:

Planning correctness

Intent → expected plan

Constraint correctness

forbidden plan → rejected

Optimization

A faster valid plan → selected

Safety

unsafe plan → blocked

98. Adversarial Planning Tests

Testar:

prompt injection
capability hallucination
policy bypass
unauthorized resource
cross-tenant reference
invalid fallback
excessive batch
infinite replanning
cyclic dependencies

99. Infinite Replanning Protection

O sistema deverá limitar:

interface ReplanningPolicy {
  maxReplansPerExecution: number;

  maxReplansPerStep: number;

  maxPlanningTimeMs: number;
}

Ao exceder:

HUMAN_REVIEW

100. Planning Timeout

O planner não poderá gastar:

30 segundos

para decidir uma operação que poderia ser resolvida deterministicamente em:

50 ms

Deverá existir budget.

101. Planning Budget

interface PlanningBudget {
  maxDurationMs: number;

  maxCandidates: number;

  maxPlanAlternatives: number;

  maxLLMCalls: number;

  maxTokens?: number;
}

102. Fast Path

Para comandos simples:

“abra a Work Permit WP-1001”

deverá ser:

Intent
 ↓
Capability
 ↓
Policy
 ↓
Execute

sem geração de múltiplos planos.

103. Intelligent Path

Para:

“Analise se a Work Permit pode ser liberada considerando treinamentos, riscos e requisitos legais.”

poderá ocorrer:

Intent
 ↓
Evidence
 ↓
Multi-Agent Plan
 ↓
Trust
 ↓
Decision

104. Complex Path

Para:

“Analise todas as permissões abertas, identifique aquelas que podem ser liberadas automaticamente e prepare as demais para revisão.”

o planner deverá produzir:

Discovery
 ↓
Segmentation
 ↓
Parallel Analysis
 ↓
Policy
 ↓
Batch Preparation
 ↓
Human Review

105. Plan Complexity

Classificar:

SIMPLE
MODERATE
COMPLEX
CRITICAL

106. Planning Strategy

Complexidade	Estratégia
SIMPLE	Determinística
MODERATE	Template + regras
COMPLEX	Search/optimization
CRITICAL	Determinística + human review

LLM será auxiliar, não requisito.

107. Plan Registry

Deverá existir um registro de planos reutilizáveis:

interface PlanTemplate {
  id: string;

  version: string;

  domain: string;

  trigger: string;

  steps: PlanTemplateStep[];

  constraints: PlanningConstraint[];

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

108. Plan Template Governance

Templates críticos deverão passar por:

Development
 ↓
Evaluation
 ↓
Security Review
 ↓
Approval
 ↓
Release

109. Plan Composition

Templates poderão ser compostos:

workPermit.validation
+
risk.assessment
+
compliance.check

produzindo:

workPermit.release-readiness

110. Composite Plan ≠ Composite Capability

Um plano pode combinar capabilities existentes sem criar uma nova capability.

Isso reduz complexidade do Registry.

111. Composite Capability

Somente quando uma composição for estável, reutilizada e possuir contrato próprio deverá ser promovida a Capability.

Fluxo:

Observed Plan
 ↓
Validated
 ↓
Evaluated
 ↓
Composite Capability Proposal
 ↓
Review
 ↓
Registry

112. Dynamic Plan Optimization

O planner poderá otimizar:

before execution

during execution

mas nunca:

after irreversible operation

para desfazer a realidade sem capability de compensação.

113. Compensation

Se o plano tiver:

A
B
C

e C falhar, poderá existir:

Compensation C'

somente se registrada.

114. Transaction Boundary

O planner deverá conhecer:

transactional
non-transactional
irreversible
compensatable

115. Irreversible Operation

Operações irreversíveis deverão:

possuir risco elevado;
exigir policy explícita;
possuir confirmação quando aplicável;
possuir audit;
possuir verification.

116. Result

O resultado do planner será:

interface PlanningResult {
  planId: string;

  selectedPlan: ExecutionPlan;

  alternatives?: ExecutionPlan[];

  score: PlanScore;

  rejectedReasons?: string[];

  constraintsSatisfied: string[];

  warnings: string[];

  requiresConfirmation: boolean;

  planningVersion: string;
}

117. Primeiro Vertical Slice — Work Permit Release

Objetivo:

Determinar automaticamente o melhor plano para avaliar se uma Work Permit pode ser liberada.

Entrada:

WP-1001

118. Candidate Plan A

Get Work Permit
Get Training
Get Risks
Check Compliance
Decision
Release
Verify

119. Candidate Plan B

Get Work Permit
Get Training + Risks + Compliance
   em paralelo
Decision
Release
Verify

Se não houver dependência entre as três consultas:

Plan B

deverá possuir menor critical path.

120. Candidate Plan C

Se já existirem evidências válidas:

Get Work Permit
Reuse verified evidence
Decision
Release
Verify

Poderá ser ainda mais rápido.

121. Trust Constraint

Porém:

evidence stale

deverá invalidar a reutilização.

122. Policy Constraint

Se a policy exigir nova verificação:

cached evidence

não poderá substituir:

fresh verification

123. Final Plan Selection

Exemplo:

Plan A
Risk: LOW
Latency: 1400ms

Plan B
Risk: LOW
Latency: 800ms

Plan C
Risk: MEDIUM
Latency: 300ms

O sistema escolherá:

Plan B

se C não cumprir o threshold de confiança exigido.

124. Replanning Example

Durante o Plan B:

Compliance API
 ↓
TIMEOUT

O planner poderá:

replan
 ↓
use verified internal compliance source

se houver capability alternativa registrada.

125. Final Acceptance Criteria

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

O planejamento usa pins de policy, trust, knowledge e release, fingerprint/idempotência e limites de replanejamento. O runtime adaptativo persiste observações, checkpoints, decisões, leases e eventos; watchdog/deadline pausam ou terminam com liberação de recursos e pedido de replanejamento. O controlador é não-autoritativo: alterações que afetam risco, escopo ou aprovação invalidam a confirmação e requerem nova revisão, sem alterar capability ou policy pinadas.

Em 2026-09-05, os contratos de Planning Intelligence passaram com 34 testes em 6 arquivos. O canário remoto comprovou em tenant isolado candidato paralelo selecionado, caminho crítico de 800ms, razão de paralelismo 1.6667, cache hit e replay idempotente, confirmação final na versão 8/revisão 2, replanejamento parcial que preservou permit, risk e training, fallback capability/agent, rejeição de confirmação stale, invalidação do cache e nove eventos auditáveis; nenhum input bruto de Work Permit foi persistido e authorizesExecution:false. A recertificação focada passou com 15 testes em 3 arquivos e typecheck limpo, cobrindo simulação What-if sem escrita, dry-run sob restrições de risco/custo e candidatos LLM_STRUCTURED rejeitados quando alucinam capability ou ciclo. Prompt injection permanece aberto para prova dedicada.

Em 2026-09-06, a regressão atual de planejamento, plan dispatch, adaptadores, cleanup, replanejamento e rotas passou com 58 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; prompt injection ainda requer prova dedicada.

126. Resultado Arquitetural

Com este PRD, o Agentic Work deixa de ter apenas um Planner e passa a possuir uma verdadeira camada de Planning Intelligence:

                         USER
                           │
                           ▼
                        INTENT
                           │
                           ▼
                    CONTEXT + KNOWLEDGE
                           │
                           ▼
                   CAPABILITY DISCOVERY
                           │
                           ▼
                  CONSTRAINT EVALUATION
                           │
                           ▼
                   PLAN GENERATION
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
           PLAN A        PLAN B        PLAN C
              │            │            │
              └────────────┼────────────┘
                           ▼
                    PLAN EVALUATION
                           │
                ┌──────────┼──────────┐
                ▼          ▼          ▼
               RISK       COST      LATENCY
                │          │          │
                └──────────┼──────────┘
                           ▼
                     PLAN OPTIMIZER
                           │
                           ▼
                        POLICY
                           │
                           ▼
                     CONFIRMATION
                           │
                           ▼
                       EXECUTION
                           │
                    ┌──────┴──────┐
                    ▼             ▼
                 VERIFY        REPLAN
                    │             │
                    └──────┬──────┘
                           ▼
                         RESULT

A partir daqui, o sistema não apenas sabe o que fazer, mas também pode determinar qual caminho válido é melhor para fazê-lo, adaptar esse caminho diante de mudanças e justificar a escolha com evidências, custo, risco e restrições verificáveis.

PRD-033 — Agentic Resource & Capacity Orchestration

O próximo PRD deverá tratar de uma consequência direta do Planning Intelligence: o plano precisa considerar recursos reais disponíveis.

Até agora falamos principalmente de capabilities e agentes. O próximo nível é considerar:

Agents
Workers
Queues
API quotas
External services
Database capacity
Concurrency
Human reviewers
SLA
Compute
LLM capacity
Budget

O sistema deverá passar de:

"Qual é o melhor plano?"

para:

"Qual é o melhor plano que pode ser executado com os recursos disponíveis neste momento?"

O PRD-033 deverá definir:

Resource Registry
Capacity Model
Resource Pools
Agent Capacity
Concurrency Limits
Queue Capacity
API Quotas
Human Capacity
Budget Constraints
Reservation
Leasing
Resource Allocation
Admission Control
Priority Scheduling
Fairness
Tenant Quotas
Burst Handling
Backpressure
Load Shedding
Capacity Prediction
Resource-Aware Planning
Resource-Aware Replanning
SLA Protection
Cost Budgets
LLM Budgets
External API Limits
Circuit Breakers
Resource Contention
Deadlock Prevention
Starvation Prevention

A arquitetura evoluirá para:

                 INTENT
                    │
                    ▼
               PLAN ENGINE
                    │
                    ▼
             RESOURCE CHECK
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       CAPACITY   QUOTA      BUDGET
          │         │         │
          └─────────┼─────────┘
                    ▼
             ADMISSION CONTROL
                    │
                    ▼
               EXECUTION
                    │
                    ▼
             RESOURCE MONITOR
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       CONTINUE             REPLAN

Isso será particularmente importante para o objetivo maior do projeto: permitir que o Agentic Work escale de poucos usuários e poucos agentes para centenas ou milhares de usuários, tenants, operações e agentes sem perder previsibilidade, segurança ou velocidade.

1. Objetivo​

2. Problema

3. Objetivo arquitetural

4. Princípio fundamental

5. Planning vs Execution

Planning​

Execution​

Policy​

Verification​

6. Arquitetura

7. Plan Context

8. Planning Objective

9. Default Objective

10. Planning Constraints

11. Hard Constraints

12. Soft Constraints

13. Constraint Model

14. Capability Discovery

15. Candidate Capability

16. Capability Equivalence

17. Não Confundir Equivalência com Substituição

18. Plan Representation

19. Plan as DAG

20. Sequential Plan

21. Parallel Plan

22. Critical Path

23. Parallelism Safety

24. Resource Conflict

25. Optimistic Concurrency

26. Plan Alternatives

27. Plan Score

28. Score não substitui Policy

29. Plan Filtering

30. LLM no Planning

31. Structured Planner Output

32. Deterministic First

33. Plan Templates

34. Template Adaptation

35. Plan Cache

36. Never Reuse Stale Plan

37. Plan Fingerprint

38. Dynamic Replanning

39. Partial Replanning

40. Replanning Triggers

41. Replanning Safety

42. Plan Invalidation

43. User Confirmation

44. Material Change

45. Blast Radius

46. Batch Optimization

47. Batch Safety

48. Cost Optimization

49. LLM Cost

50. Latency Optimization

51. External Service Penalty

52. Trust Optimization

53. Confidence Threshold

54. Unknown State

55. Temporal Planning

56. Deadline

57. Alternative Under Deadline

58. Human Availability

59. Human-in-the-Loop Planning

60. Agent Selection

61. Agent Affinity

62. Agent Fallback

63. No Arbitrary Fallback

64. Planning Under Failure

65. Plan Robustness

66. Single Point of Failure

67. Plan Simulation

68. What-If Planning

69. Dry Run

70. Plan Explainability

71. Example Explanation

72. Plan Comparison

73. Policy Integration

74. Policy Changes During Execution

75. Knowledge Changes During Execution

76. Release Pinning

1. Objetivo

Planning

Execution

Policy

Verification

Planning correctness

Constraint correctness

Optimization

Safety

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