PRD-034 — Agentic Adaptive Execution & Runtime Control

1. Objetivo

O PRD-034 define a camada responsável por controlar e adaptar uma execução enquanto ela está acontecendo.

Os PRDs anteriores estabelecem:

o que o usuário quer — Intent;
o que o sistema pode fazer — Capability Registry;
se pode fazer — Policy;
qual plano utilizar — Planning Intelligence;
quais recursos estão disponíveis — Resource & Capacity;
como reagir a eventos e falhas — Event Fabric + Exception Management.

Agora precisamos responder:

O que o sistema deve fazer quando as condições mudam durante a execução?

O Runtime deverá ser capaz de:

controlar concorrência;
ajustar batches;
trocar recursos;
aplicar backpressure;
adaptar retries;
pausar;
retomar;
degradar funcionalidades;
detectar anomalias;
acionar fallback;
solicitar replanning;
interromper execuções perigosas;
preservar consistência e segurança.

2. Princípio fundamental

O Runtime poderá adaptar:

HOW

mas não poderá alterar:

WHETHER

a operação é permitida.

Em outras palavras:

Adaptive Runtime
       │
       ▼
"Como executar melhor?"

mas:

Policy Engine
       │
       ▼
"É permitido executar?"

A segunda pergunta sempre pertence à Policy.

3. Arquitetura

                    APPROVED PLAN
                          │
                          ▼
                 ADAPTIVE EXECUTOR
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       Scheduler       Controller       Watchdog
          │               │                │
          ▼               ▼                ▼
       Resources       Runtime State     Anomaly
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                    EXECUTION STEP
                          │
                          ▼
                       RESULT
                          │
                ┌─────────┴─────────┐
                ▼                   ▼
             Verify              Monitor
                │                   │
                └─────────┬─────────┘
                          ▼
                  Continue / Adapt
                          │
                    ┌─────┴─────┐
                    ▼           ▼
                 Replan        Stop

4. Runtime Control Loop

A execução deverá funcionar como um control loop:

OBSERVE
   ↓
EVALUATE
   ↓
DECIDE
   ↓
ACT
   ↓
VERIFY
   ↓
OBSERVE

Esse ciclo continuará enquanto a execução estiver ativa.

5. Runtime State

interface RuntimeExecutionState {
  executionId: string;

  planId: string;

  status:
    | "RUNNING"
    | "DEGRADED"
    | "PAUSED"
    | "WAITING"
    | "REPLANNING"
    | "STOPPING"
    | "COMPLETED"
    | "FAILED"
    | "TERMINATED";

  activeSteps: string[];

  completedSteps: string[];

  failedSteps: string[];

  resourceStateVersion: string;

  policyVersion: string;

  startedAt: string;

  updatedAt: string;
}

6. Runtime Controller

O Runtime Controller será responsável por:

iniciar steps;
controlar dependências;
solicitar recursos;
monitorar execução;
interromper operações;
adaptar parâmetros permitidos;
solicitar fallback;
solicitar replanning;
acionar watchdog;
emitir eventos.

Não deverá executar APIs diretamente fora do Execution Engine.

7. Runtime vs Planner

Planner

Decide:

“Qual plano é melhor?”

Runtime

Decide:

“O plano continua executável nas condições atuais?”

Replanner

Decide:

“O plano precisa ser alterado?”

8. Runtime Adaptation

Exemplo:

Plan
 ↓
Batch 50
 ↓
API latency increases
 ↓
Runtime detects degradation
 ↓
Batch 25

Isso poderá acontecer sem reconstruir todo o plano, se a alteração estiver dentro dos limites definidos.

9. Adaptation Envelope

Cada plan step poderá declarar o que pode ser adaptado.

interface AdaptationEnvelope {
  allowBatchAdjustment: boolean;

  allowConcurrencyAdjustment: boolean;

  allowTimeoutAdjustment: boolean;

  allowRetryAdjustment: boolean;

  allowResourceSwitch: boolean;

  allowPriorityAdjustment: boolean;
}

10. Immutable Parameters

Alguns parâmetros nunca poderão ser alterados durante runtime.

Por exemplo:

authorization
tenant
target resource
business constraints
required verification
maximum blast radius

11. Runtime Mutable Parameters

Alguns parâmetros poderão ser adaptados:

batch size
concurrency
queue priority
retry delay
timeout
resource pool member

desde que o Registry permita.

12. Runtime Policy Boundary

O Runtime deverá consultar:

Policy Engine

quando uma adaptação puder alterar materialmente o risco.

13. Example

Original:

batch = 50

Runtime deseja:

batch = 100

Se:

Capability maxBatch = 50

a alteração será:

DENY

14. Adaptive Concurrency

O Runtime poderá ajustar concorrência dentro dos limites:

minConcurrency
maxConcurrency

Exemplo:

10 → 8 → 5

quando:

latência aumenta;
erro aumenta;
rate limit aparece.

15. Concurrency Controller

interface ConcurrencyPolicy {
  min: number;

  max: number;

  initial: number;

  scaleUpStep: number;

  scaleDownStep: number;

  cooldownMs: number;
}

16. AIMD

Uma estratégia simples poderá ser:

success
 ↓
increase slowly

failure
 ↓
decrease quickly

Isso reduz risco de congestionamento.

17. Hard Maximum

Mesmo que o sistema detecte alta capacidade:

observed capacity = 100

não poderá ultrapassar:

configured max = 20

18. Dynamic Batching

O Runtime poderá alterar:

batch size

de acordo com:

latência;
tamanho do payload;
erro;
quota;
memória;
capacidade externa.

19. Example

initial batch = 50

latency high
↓
25

latency normal
↓
30

rate-limit
↓
10

20. Batch Adaptation Boundary

O batch máximo continuará vindo de:

Capability Registry
+
Policy Engine
+
Resource Registry

21. Runtime Routing

Um recurso poderá ficar degradado:

Primary API
     ↓
high latency

O Runtime poderá selecionar:

Secondary API

se isso estiver previsto no Capability/Resource Registry.

22. No Arbitrary Routing

O Runtime não poderá decidir:

“Vou chamar outro serviço qualquer.”

Somente recursos previamente registrados poderão ser utilizados.

23. Runtime Health

O controlador deverá observar:

latency
error rate
timeouts
queue depth
throughput
resource pressure
quota
budget

24. Runtime Health State

HEALTHY
DEGRADED
CRITICAL
UNKNOWN

25. Graceful Degradation

Quando um recurso secundário falhar:

full functionality
       ↓
degraded functionality

quando permitido.

Exemplo:

LLM unavailable

e a tarefa puder continuar deterministicamente.

26. LLM Degradation

Se a tarefa exigir apenas:

exact lookup

não deverá falhar simplesmente porque o LLM está indisponível.

27. Critical LLM Dependency

Por outro lado, se a operação realmente exigir interpretação semântica:

LLM unavailable

o sistema deverá:

WAIT
RETRY
FALLBACK
HUMAN_REVIEW

conforme policy.

Nunca inventar resposta.

28. Retry Adaptation

O Runtime deverá adaptar retries de acordo com o tipo de erro.

Retryável

429
502
503
504
timeout
network transient

Normalmente não retryável

400
401
403
404
business rule violation
validation error

29. Retry Policy

interface RuntimeRetryPolicy {
  maxAttempts: number;

  initialDelayMs: number;

  maxDelayMs: number;

  backoff:
    | "FIXED"
    | "LINEAR"
    | "EXPONENTIAL";

  jitter: boolean;
}

30. Retry Budget

Retries deverão consumir um budget.

Execution Budget
 ├── API calls
 ├── retries
 ├── LLM calls
 └── elapsed time

31. Retry Storm Prevention

Se centenas de operações falharem simultaneamente:

100 failures

não deverão produzir:

100 × 5 retries

sem controle.

32. Coordinated Retry

O Runtime deverá aplicar:

backoff
jitter
concurrency limit
circuit breaker
queue

33. Timeout Adaptation

Timeout poderá ser adaptado dentro de limites registrados.

initial = 2s
max = 5s

O Runtime não poderá simplesmente:

timeout = 10min

para mascarar um serviço problemático.

34. Deadline Awareness

Timeout deverá considerar o deadline do workflow.

Se:

deadline = 10:00

remaining = 500ms

não faz sentido executar uma tentativa de:

timeout = 5s

35. Deadline Controller

O Runtime deverá conhecer:

startedAt
deadline
elapsed
remaining

36. Speculative Execution

Em casos específicos, poderá executar duas alternativas simultaneamente:

Primary
   │
   ├──► Result A
   │
Secondary
   │
   └──► Result B

e usar a primeira resposta válida.

37. Speculative Execution Restrictions

Só poderá ser utilizada quando:

operação for read-only ou idempotente;
custo estiver autorizado;
blast radius estiver controlado;
policy permitir;
não houver efeito duplicado.

38. Hedged Requests

Para operações read-only:

request A
   ↓
latency threshold exceeded
   ↓
request B

poderá ser utilizado.

39. No Hedging for Dangerous Writes

Não aplicar automaticamente a:

delete
approve
release
financial transaction
irreversible operation

40. Runtime Priority

Durante execução, a prioridade poderá mudar somente quando permitido.

Exemplo:

deadline approaching

pode elevar:

NORMAL → HIGH

41. Priority Abuse Prevention

O usuário não poderá simplesmente declarar:

CRITICAL

para contornar filas.

Prioridade crítica deverá possuir regra autorizada.

42. Queue Migration

Se uma fila estiver saturada:

Queue A
 ↓
saturated

poderá mover para:

Queue B

somente se os recursos forem equivalentes e registrados.

43. Backpressure

O Runtime deverá desacelerar produtores quando consumidores estiverem saturados.

Producer
   ↓
Backpressure
   ↓
Queue
   ↓
Consumer

44. Execution Flow Control

Estados possíveis:

RUN
THROTTLE
PAUSE
QUEUE
RESUME
REPLAN
STOP

45. Watchdog

Toda execução longa deverá possuir watchdog.

interface ExecutionWatchdog {
  executionId: string;

  heartbeatIntervalMs: number;

  timeoutMs: number;

  lastHeartbeatAt: string;
}

46. Heartbeat

Workers/agentes poderão enviar:

HEARTBEAT

durante operações longas.

47. Stalled Execution

Se:

now - lastHeartbeat > timeout

o Runtime deverá marcar:

STALLED

e iniciar recuperação.

48. Recovery

Dependendo do tipo:

resume
retry
reassign
replan
human review
terminate

49. Checkpoints

Execuções longas deverão criar checkpoints.

interface ExecutionCheckpoint {
  executionId: string;

  stepId: string;

  stateVersion: string;

  completedSteps: string[];

  contextRef: string;

  createdAt: string;
}

50. Resume

Após falha:

checkpoint
 ↓
validate
 ↓
resume

em vez de reiniciar tudo.

51. Checkpoint Validation

Antes de retomar:

authorization;
policy;
resource state;
workflow state;
capability version;
idempotency;
context freshness.

deverão ser reavaliados.

52. Context Drift

Se o contexto mudou:

old UI context
old selected entity

o Runtime deverá impedir execução baseada em contexto inválido.

53. Stale UI Context

Exemplo:

Usuário selecionou:

WP-1001

e a tela mudou para:

WP-1002

Uma operação pendente destinada a WP-1001 não deverá ser redirecionada para WP-1002 por acidente.

54. Execution Context Pinning

Cada execução deverá manter:

entityId
tenantId
userId
intent
plan

explicitamente vinculados.

55. Runtime Replanning

Quando adaptação local não for suficiente:

Runtime
 ↓
Replan Request
 ↓
Planning Intelligence
 ↓
new plan

56. Replan Trigger

Exemplos:

RESOURCE_UNAVAILABLE
NEW_EVIDENCE
POLICY_CHANGE
WORKFLOW_CHANGE
DEADLINE_RISK
CAPABILITY_FAILURE
CONTEXT_INVALID

57. Runtime vs Replanning

Use Runtime adaptation quando:

small safe change

Use Replanning quando:

material change

58. Example

Runtime adaptation

batch 50 → 25

Replanning

Compliance API
 ↓
unavailable

Use completely different verification strategy

59. Material Change Detection

interface PlanChangeImpact {
  changedSteps: string[];

  changedResources: string[];

  riskDelta: number;

  scopeDelta: number;

  authorizationImpact: boolean;

  requiresReapproval: boolean;
}

60. Reapproval

Se:

riskDelta > threshold

ou:

scopeDelta > threshold

será necessário:

new policy evaluation
+
new confirmation

61. Runtime Kill Switch

Deverá existir capacidade de:

STOP EXECUTION

em situações críticas.

62. Kill Switch Levels

GLOBAL
TENANT
AGENT
CAPABILITY
RESOURCE
EXECUTION

63. Emergency Stop

Uma execução crítica poderá ser encerrada por:

Policy;
Security;
Incident Manager;
authorized administrator;
emergency control.

64. Kill Switch Security

Não poderá ser acionado por uma mensagem comum do LLM.

Deverá exigir autoridade específica.

65. Runaway Agent Protection

O Runtime deverá detectar:

too many calls
too many retries
too many replans
too much cost
too much elapsed time
unexpected recursion

66. Execution Budget

interface ExecutionBudget {
  maxDurationMs: number;

  maxSteps: number;

  maxApiCalls: number;

  maxRetries: number;

  maxLLMCalls: number;

  maxCost: number;
}

67. Budget Exhaustion

Quando o budget for excedido:

STOP

ou:

HUMAN_REVIEW

conforme policy.

Nunca simplesmente continuar indefinidamente.

68. Recursive Agent Protection

Agentes não poderão produzir:

Agent A
 ↓
Agent B
 ↓
Agent C
 ↓
Agent A

sem limite explícito.

69. Execution Depth

interface AgentExecutionLimits {
  maxDelegationDepth: number;

  maxReactionDepth: number;

  maxWorkflowDepth: number;

  maxReplanCount: number;
}

70. Adaptive Streaming

Durante execução longa, o usuário poderá receber:

Planejando...
Verificando treinamento...
Verificando riscos...
Analisando conformidade...
Aguardando resultado...

Mas o streaming não deverá expor:

secrets;
internal prompts;
chain-of-thought;
informações de outros tenants.

71. Runtime Events

O Runtime deverá publicar:

EXECUTION_STARTED
STEP_STARTED
STEP_COMPLETED
STEP_FAILED
EXECUTION_THROTTLED
EXECUTION_PAUSED
EXECUTION_RESUMED
RESOURCE_SWITCHED
BATCH_ADJUSTED
RETRY_SCHEDULED
CIRCUIT_OPENED
REPLAN_REQUESTED
EXECUTION_TERMINATED

72. Event Fabric Integration

Esses eventos alimentarão:

Observability;
Audit;
Exception Management;
Proactive Intelligence;
Operational Learning.

73. Exception Integration

Exceções detectadas pelo Runtime deverão ser classificadas pelo PRD-024.

Runtime
 ↓
Exception Detector
 ↓
Classification
 ↓
Recovery

74. Resource Integration

O Runtime consultará o PRD-033 para:

capacity
reservation
health
quota
budget
resource pressure

75. Planning Integration

O Runtime consultará o PRD-032 quando precisar de:

alternative plan
new resource strategy
different execution topology

76. Workflow Integration

O Workflow Engine determinará:

business state

enquanto o Runtime determinará:

execution state

Esses estados não devem ser confundidos.

77. Example

Workflow:
WAITING_APPROVAL

Runtime:
PAUSED

A operação não está necessariamente com erro.

78. Communication Fabric

Quando uma tarefa estiver delegada:

Supervisor
 ↓
Training Agent

o Runtime deverá acompanhar:

message
ack
task
progress
result
timeout

79. Agent Handoff

Se um agente ficar indisponível:

Agent A
 ↓ unavailable
Agent B

o handoff deverá:

preservar taskId;
preservar tenant;
preservar delegation;
validar autorização;
evitar execução duplicada.

80. Duplicate Execution Protection

Uma mesma operação deverá possuir:

executionId
operationId
idempotencyKey

81. Exactly-Once Illusion

O sistema deverá assumir:

at-least-once delivery + idempotent operations

em vez de depender de uma garantia global de exactly-once.

82. Verification

Depois de qualquer adaptação importante:

Execute
 ↓
Verify

deverá continuar obrigatório.

83. Runtime Verification

Exemplo:

API returned 200

não significa necessariamente:

business operation completed

A verificação poderá consultar o estado real.

84. Unknown Outcome

Se o resultado for:

UNKNOWN

o Runtime não deverá repetir automaticamente uma operação potencialmente não idempotente.

85. Runtime Anomaly Detection

O sistema deverá identificar:

latency anomaly
error anomaly
cost anomaly
call volume anomaly
retry anomaly
replan anomaly

86. Deterministic First

Anomalias simples deverão usar thresholds:

errorRate > 20%

antes de usar modelos mais complexos.

87. Statistical Detection

Opcionalmente:

baseline
+
moving average
+
percentile
+
historical pattern

poderão identificar degradações.

88. LLM in Runtime Control

O LLM não deverá controlar diretamente o Runtime.

Poderá:

resumir incidentes;
sugerir hipóteses;
interpretar mensagens não estruturadas;
auxiliar análise.

Mas a decisão de:

stop
retry
switch resource
increase concurrency

deverá ser determinística/policy-controlled.

89. Runtime Safety Matrix

Ação	Automática
reduzir concorrência	Sim
reduzir batch	Sim
retry transitório	Sim
abrir circuit breaker	Sim
pausar operação	Sim
usar fallback registrado	Sim
aumentar concorrência	Condicional
mudar prioridade	Condicional
trocar plano	Replanejamento
executar capability nova	Não
alterar policy	Nunca
ignorar autorização	Nunca

90. Runtime Configuration

runtime:
  watchdog:
    heartbeatIntervalMs: 5000
    timeoutMs: 30000

  execution:
    maxDurationMs: 300000
    maxRetries: 3
    maxReplans: 2

  adaptation:
    batchAdjustment: true
    concurrencyAdjustment: true
    resourceSwitch: true

  safety:
    failClosed: true

91. Fail Closed

Para decisões de segurança:

UNKNOWN

deverá resultar em:

STOP / WAIT / REVIEW

e não em execução permissiva.

92. Performance

O Runtime Controller precisa ser extremamente leve.

Operações simples não poderão passar por uma cadeia pesada de LLMs.

Meta inicial:

runtime control overhead P50 < 5ms
runtime control overhead P95 < 20ms

para decisões locais/cacheadas.

93. Hot Path

O hot path deverá ser:

Execution
 ↓
Runtime State
 ↓
Resource Check
 ↓
Policy Check if required
 ↓
Execute

94. Cold Path

Análises mais pesadas poderão ocorrer fora do hot path:

historical analysis
capacity prediction
optimization learning
anomaly analysis

95. State Storage

Como o ambiente é serverless, o Runtime não poderá depender de memória local.

Deverá existir uma abstração:

interface RuntimeStateStore {
  get(executionId: string): Promise<RuntimeExecutionState>;

  save(state: RuntimeExecutionState): Promise<void>;

  compareAndSet(
    executionId: string,
    expectedVersion: string,
    state: RuntimeExecutionState
  ): Promise<boolean>;
}

96. Concurrency

Duas instâncias não poderão controlar simultaneamente a mesma execução sem coordenação.

Deverá existir:

execution lock
+
version

97. Optimistic Concurrency

Preferir:

version
compare-and-set

para reduzir locks prolongados.

98. Runtime Snapshot

Cada adaptação importante deverá gerar snapshot:

Execution v1
 ↓
Execution v2
 ↓
Execution v3

Isso facilita:

auditoria;
replay;
debugging;
recuperação.

99. Audit

Registrar:

original runtime state
adaptation
reason
metrics
policy
resource state
new state

100. Explainability

Exemplo:

A concorrência foi reduzida de 20 para 8 porque a API de conformidade apresentou aumento de latência e taxa de timeout. O limite permanece dentro da política configurada.

101. No Hidden Reasoning

Explicação deverá conter:

fatos;
métricas;
regras;
decisão.

Não chain-of-thought.

102. Operational Learning

PRD-012 poderá aprender:

batch 50 → timeout 12%
batch 25 → timeout 1%

e sugerir:

default batch = 25

A mudança passará pelo processo de governança antes de alterar comportamento oficial.

103. Runtime Learning

O Runtime poderá produzir:

RuntimeOptimizationSuggestion

interface RuntimeOptimizationSuggestion {
  resourceId: string;

  currentConfiguration: unknown;

  proposedConfiguration: unknown;

  evidenceRefs: string[];

  confidence: number;

  expectedImprovement: number;
}

104. Governance

Nenhuma sugestão de learning deverá automaticamente:

alterar policy;
alterar segurança;
aumentar blast radius;
criar capability;
conceder autoridade.

105. Testing

O PRD-014 deverá adicionar testes de runtime:

Saturation

resource → 100%

Latency spike

50ms → 2s

Retry storm

many failures

Agent crash

worker disappears

Network partition

unknown result

Runtime replanning

resource unavailable

106. Security Tests

Testar:

runtime attempts unauthorized capability
runtime changes tenant
runtime exceeds batch limit
runtime bypasses confirmation
runtime changes protected field
runtime uses unauthorized fallback

Todos deverão ser bloqueados.

107. Long-Running Test

Simular execução:

30 minutes

com:

checkpoints;
heartbeat;
pause;
resume;
resource changes;
replan.

108. Kill Switch Test

Durante execução:

RUNNING
 ↓
GLOBAL STOP
 ↓
TERMINATED

Nenhuma nova operação deverá ser iniciada.

109. Recovery Test

Step A ✓
Step B ✓
Step C → worker crash

Depois:

checkpoint
 ↓
new worker
 ↓
resume

sem duplicar A/B.

110. First Vertical Slice — Work Permit Batch

Cenário:

100 Work Permits

Plano:

Training
Risk
Compliance
Decision

111. Initial Runtime

Training concurrency = 20
Risk concurrency = 10
Compliance concurrency = 5

112. Runtime Degradation

Compliance apresenta:

latency ↑
timeout ↑

O Runtime detecta:

DEGRADED

113. Adaptive Response

Executa:

concurrency 5 → 3
batch 25 → 10

se permitido pelo envelope de adaptação.

114. Continued Failure

Se continuar:

circuit breaker OPEN

115. Replanning

Então:

Runtime
 ↓
Replan
 ↓
Alternative compliance source

116. No Alternative

Se não houver:

WAITING_RESOURCE

ou:

HUMAN_REVIEW

conforme a regra.

117. Verification

Quando o recurso voltar:

resume
 ↓
verify previous state
 ↓
continue

118. Acceptance Criteria

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

O controle adaptativo persiste observações, estado, decisões, snapshots, heartbeats e checkpoints tenant-bound. Orçamento, deadline, retry, pressão e saúde de recurso determinam continuar, pausar, replanejar, revisão humana ou encerrar; o watchdog libera leases e invalida confirmações em execução estagnada. Resume revalida os pins de checkpoint, e qualquer mudança material gera replanejamento com reaprovação, sem transformar a adaptação em autoridade de execução.

Em 2026-09-05, a criação de projeções do State Fabric passou a vincular o assinante à identidade autenticada: usuário não-governor só pode criar projeção UI para si; consumidores internos ou outro assinante exigem governor. Isso impede forjar o consumidor ou o escopo declarado de uma projeção. Worker 7b7dc456-df94-4885-ae80-63e9a394f948 publicado com health público saudável.

Em 2026-09-05, a suíte Adaptive Runtime passou com 16 testes em 3 arquivos. O canário remoto executou o batch Work Permit em tenant isolado: concluiu permit, training e risk; degradou para concorrência 3 e batch 10 por anomalias de latência, erro, timeout e profundidade de fila; usou recurso fallback, heartbeat, checkpoint, resume, replanejamento com reaprovação e terminação controlada na versão 14. A execução manteve authorizesExecution:false e o cleanup confirmou remainingRows:0.

Em 2026-09-06, a regressão atual do runtime adaptativo e de sua rota passou com 10 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.

119. Resultado Arquitetural

Com o PRD-034, o Agentic Work deixa de ser apenas um sistema que:

planeja → executa

e passa a funcionar como um sistema adaptativo de controle de execução:

                     APPROVED PLAN
                           │
                           ▼
                    ADAPTIVE RUNTIME
                           │
               ┌───────────┼───────────┐
               ▼           ▼           ▼
            CONTROL      MONITOR      WATCHDOG
               │           │           │
               └───────────┼───────────┘
                           ▼
                       EXECUTE
                           │
                           ▼
                       OBSERVE
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
           ADAPT         REPLAN        STOP
              │            │            │
              └────────────┼────────────┘
                           ▼
                        VERIFY
                           │
                           ▼
                         RESULT

A separação arquitetural passa a ser muito clara:

PRD-032
Planning Intelligence
        ↓
"Qual plano?"

PRD-033
Resource & Capacity
        ↓
"Há recursos para executar?"

PRD-034
Adaptive Runtime
        ↓
"Como manter a execução saudável enquanto ela acontece?"

Isso cria uma camada essencial para escala e confiabilidade, sem transformar o LLM em um controlador de infraestrutura.

PRD-035 — Agentic State & Context Synchronization Fabric

O próximo problema que emerge é ainda mais fundamental.

Temos agora:

Conversation State;
UI State;
Workflow State;
Execution State;
Resource State;
Knowledge State;
Agent State;
Business State;
Event State.

O risco passa a ser inconsistência entre esses estados.

Por exemplo:

UI:
WP-1001 selected

Business API:
WP-1001 = APPROVED

Workflow:
WAITING_APPROVAL

Agent:
plan says RELEASE

Knowledge:
old state = SUBMITTED

Se o sistema não possuir uma camada formal de sincronização e consistência, agentes poderão tomar decisões baseadas em estados diferentes.

O PRD-035 deverá portanto definir um:

Agentic State & Context Synchronization Fabric

com foco em:

Canonical State
State Ownership
State Versioning
State Snapshots
Context Versioning
Optimistic Concurrency
State Reconciliation
Eventual Consistency
Strong Consistency Boundaries
State Conflicts
State Drift
State Subscriptions
Context Deltas
UI ↔ Agent Synchronization
Workflow ↔ Execution Synchronization
Knowledge ↔ Business State Synchronization
Agent ↔ Agent State Synchronization
Stale Context Detection
State Locks
Entity Versioning
State Projection
Materialized Views
Conflict Resolution
State Recovery
Historical State
Temporal State
Cross-System Synchronization

A arquitetura começará a assumir a seguinte forma:

                 BUSINESS SYSTEMS
                       │
                       ▼
                 CANONICAL STATE
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
             UI     WORKFLOW  KNOWLEDGE
              │        │        │
              └────────┼────────┘
                       ▼
                 STATE FABRIC
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       AGENTS       EXECUTION     CONTEXT
          │            │            │
          └────────────┼────────────┘
                       ▼
                  SYNCHRONIZATION
                       │
                       ▼
                   CONSISTENT
                     STATE

Esse será o próximo passo para transformar o conjunto de componentes anteriores em um sistema agentic realmente coerente, no qual todos os agentes e interfaces trabalham sobre uma visão consistente e versionada da realidade.

1. Objetivo​

2. Princípio fundamental

3. Arquitetura

4. Runtime Control Loop

5. Runtime State

6. Runtime Controller

7. Runtime vs Planner

Planner​

Runtime​

Replanner​

8. Runtime Adaptation

9. Adaptation Envelope

10. Immutable Parameters

11. Runtime Mutable Parameters

12. Runtime Policy Boundary

13. Example

14. Adaptive Concurrency

15. Concurrency Controller

16. AIMD

17. Hard Maximum

18. Dynamic Batching

19. Example

20. Batch Adaptation Boundary

21. Runtime Routing

22. No Arbitrary Routing

23. Runtime Health

24. Runtime Health State

25. Graceful Degradation

26. LLM Degradation

27. Critical LLM Dependency

28. Retry Adaptation

Retryável​

Normalmente não retryável​

29. Retry Policy

30. Retry Budget

31. Retry Storm Prevention

32. Coordinated Retry

33. Timeout Adaptation

34. Deadline Awareness

35. Deadline Controller

36. Speculative Execution

37. Speculative Execution Restrictions

38. Hedged Requests

39. No Hedging for Dangerous Writes

40. Runtime Priority

41. Priority Abuse Prevention

42. Queue Migration

43. Backpressure

44. Execution Flow Control

45. Watchdog

46. Heartbeat

47. Stalled Execution

48. Recovery

49. Checkpoints

50. Resume

51. Checkpoint Validation

52. Context Drift

53. Stale UI Context

54. Execution Context Pinning

55. Runtime Replanning

56. Replan Trigger

57. Runtime vs Replanning

58. Example

Runtime adaptation​

Replanning​

59. Material Change Detection

60. Reapproval

61. Runtime Kill Switch

62. Kill Switch Levels

63. Emergency Stop

64. Kill Switch Security

65. Runaway Agent Protection

66. Execution Budget

67. Budget Exhaustion

68. Recursive Agent Protection

69. Execution Depth

70. Adaptive Streaming

71. Runtime Events

72. Event Fabric Integration

73. Exception Integration

1. Objetivo

Planner

Runtime

Replanner

Retryável

Normalmente não retryável

Runtime adaptation

Replanning

Saturation

Latency spike

Retry storm

Agent crash

Network partition

Runtime replanning

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