PRD-033 — Agentic Resource & Capacity Orchestration

1. Objetivo

O PRD-033 define a camada responsável por gerenciar os recursos necessários para executar planos agentic em escala, evitando que o Agentic Work produza planos teoricamente válidos, mas impossíveis ou inadequados de executar devido à falta de capacidade.

O sistema deverá responder não apenas:

“Qual é o melhor plano?”

mas:

“Qual é o melhor plano que pode ser executado agora, dentro da capacidade, orçamento, concorrência, SLA e limites de todos os recursos envolvidos?”

2. Problema

Um Agentic Work pode depender simultaneamente de:

agentes;
Workers;
APIs internas;
APIs externas;
banco de dados;
filas;
Vectorize;
LLMs;
integrações;
recursos computacionais;
limites de rate;
operadores humanos;
aprovações;
orçamento;
SLA.

Por exemplo:

1000 Work Permits
       │
       ├──► Training API
       ├──► Risk API
       ├──► Compliance API
       ├──► LLM
       └──► Human Review

O problema não é somente planejar essas operações.

É necessário saber:

Training API
  capacity = 100 req/s

Risk API
  capacity = 50 req/s

LLM
  budget = 10,000 calls/day

Human Review
  capacity = 200 items/day

3. Princípio fundamental

Planejamento deve ser resource-aware.

Um plano só poderá ser admitido se os recursos necessários forem compatíveis com:

capacidade atual;
capacidade prevista;
quotas;
orçamento;
prioridade;
SLA;
tenant;
política;
concorrência.

4. Arquitetura

                         INTENT
                            │
                            ▼
                     PLANNING ENGINE
                            │
                            ▼
                    CANDIDATE PLANS
                            │
                            ▼
                 RESOURCE REQUIREMENT
                            │
                            ▼
                 CAPACITY EVALUATOR
                            │
          ┌─────────────────┼─────────────────┐
          ▼                 ▼                 ▼
       Capacity            Quota            Budget
          │                 │                 │
          └─────────────────┼─────────────────┘
                            ▼
                    ADMISSION CONTROL
                            │
                  ┌─────────┴─────────┐
                  ▼                   ▼
               EXECUTE               QUEUE
                  │                   │
                  ▼                   ▼
              MONITOR             SCHEDULE
                  │                   │
                  └─────────┬─────────┘
                            ▼
                         REPLAN

5. Resource Model

Todo recurso relevante deverá possuir uma representação formal.

interface AgenticResource {
  resourceId: string;

  type:
    | "AGENT"
    | "WORKER"
    | "API"
    | "DATABASE"
    | "QUEUE"
    | "LLM"
    | "VECTOR_STORE"
    | "HUMAN"
    | "EXTERNAL_SERVICE"
    | "COMPUTE"
    | "BUDGET";

  tenantScope:
    | "GLOBAL"
    | "TENANT"
    | "USER";

  status:
    | "AVAILABLE"
    | "DEGRADED"
    | "SATURATED"
    | "UNAVAILABLE";

  capacity: ResourceCapacity;

  constraints: ResourceConstraint[];
}

6. Resource Capacity

interface ResourceCapacity {
  maxConcurrency?: number;

  requestsPerSecond?: number;

  requestsPerMinute?: number;

  dailyLimit?: number;

  monthlyLimit?: number;

  computeUnits?: number;

  memoryMb?: number;

  estimatedLatencyMs?: number;
}

7. Capacity Types

O sistema deverá suportar:

Concurrency

max 20 concurrent operations

Rate

100 requests / second

Quota

10,000 requests / day

Budget

$100 / day

Human capacity

200 reviews / day

8. Resource Registry

Deverá existir um registro centralizado de recursos.

interface ResourceRegistry {
  get(resourceId: string): Promise<AgenticResource>;

  listByType(type: string): Promise<AgenticResource[]>;

  getCapacity(resourceId: string): Promise<ResourceCapacity>;

  reserve(request: ResourceReservation): Promise<Reservation>;

  release(reservationId: string): Promise<void>;
}

9. Resource Registry ≠ Capability Registry

Essa distinção é importante.

Capability Registry

Responde:

O que o sistema pode fazer?

Resource Registry

Responde:

Com quais recursos isso pode ser feito agora?

Exemplo:

Capability:
training.getStatus

Resources:
training-api-primary
training-api-secondary

10. Resource Pools

Recursos equivalentes poderão formar pools.

Training API Pool
 ├── LMS Primary
 ├── LMS Secondary
 └── LMS Cache

O planner poderá selecionar o recurso adequado.

11. Resource Pool

interface ResourcePool {
  poolId: string;

  resources: string[];

  strategy:
    | "ROUND_ROBIN"
    | "LEAST_LOADED"
    | "LOWEST_LATENCY"
    | "WEIGHTED"
    | "PRIMARY_FIRST";

  healthPolicy: string;
}

12. Agent Capacity

Cada agente poderá possuir capacidade própria.

training-agent
 ├── maxConcurrency = 20
 ├── queue = 500
 └── priority = normal

13. Agent Health

O Resource Layer deverá acompanhar:

HEALTHY
DEGRADED
SATURATED
UNAVAILABLE

14. Agent Selection

O PRD-032 poderá consultar:

Agent Registry
+
Resource Registry

para selecionar:

agent.training.fast

em vez de:

agent.training.standard

se houver vantagem mensurável e a policy permitir.

15. Resource Requirement

Cada step deverá declarar recursos necessários.

interface ResourceRequirement {
  resourceType: string;

  resourceId?: string;

  poolId?: string;

  quantity: number;

  concurrency?: number;

  estimatedDurationMs?: number;

  required: boolean;
}

16. Example

Uma capability:

training.getStatus

poderá declarar:

{
  "resources": [
    {
      "resourceType": "EXTERNAL_SERVICE",
      "poolId": "lms-primary-pool",
      "quantity": 1,
      "estimatedDurationMs": 400,
      "required": true
    }
  ]
}

17. Resource-Aware Planning

O fluxo será:

Plan
 ↓
Resource Requirements
 ↓
Capacity Evaluation
 ↓
Resource Feasible?
 ├── YES → Execute
 └── NO  → Replan / Queue

18. Admission Control

Antes de executar um plano, o sistema deverá decidir:

ADMIT
QUEUE
DEFER
REJECT

19. Admission Control

Exemplo:

type AdmissionDecision =
  | "ADMIT"
  | "QUEUE"
  | "DEFER"
  | "REJECT";

20. Admission ≠ Authorization

Um usuário pode estar autorizado:

Policy = ALLOW

mas o sistema pode estar sem capacidade:

Capacity = SATURATED

Resultado:

ALLOW + QUEUE

e não:

DENY

21. Resource Reservation

Para operações críticas, o sistema poderá reservar capacidade antes da execução.

interface ResourceReservation {
  reservationId: string;

  resourceId: string;

  quantity: number;

  executionId: string;

  expiresAt: string;
}

22. Reservation TTL

Toda reserva deverá possuir TTL.

Isso evita:

reservation leak

quando uma execução desaparece.

23. Lease

Para operações longas:

reserve
 ↓
lease
 ↓
renew
 ↓
release

24. Lease Expiration

Se o agente não renovar:

LEASE_EXPIRED

e o recurso poderá voltar ao pool.

25. Concurrency Control

Cada recurso poderá possuir:

maxConcurrency

Exemplo:

LMS API
maxConcurrency = 10

O décimo primeiro request deverá:

QUEUE

ou usar outro recurso disponível.

26. Rate Limiting

O sistema deverá respeitar:

requestsPerSecond
requestsPerMinute
requestsPerHour

27. Quotas

Quotas poderão existir por:

global
tenant
user
agent
capability
external integration

28. Tenant Quota

Exemplo:

Tenant A
10,000 operations/day

Tenant B
2,000 operations/day

Uma operação de A não poderá consumir silenciosamente a quota de B.

29. Fairness

Um tenant que produz carga elevada não deverá monopolizar recursos compartilhados.

Deverá existir:

fair scheduling

30. Scheduling

A fila poderá considerar:

priority
tenant
SLA
deadline
resource availability
operation age
risk

31. Priority Levels

type Priority =
  | "CRITICAL"
  | "HIGH"
  | "NORMAL"
  | "LOW"
  | "BACKGROUND";

32. Priority não pode ignorar Security

Uma operação:

CRITICAL

não poderá ultrapassar:

autorização;
confirmação;
policy;
segregação de funções.

Prioridade somente controla quando executar, não se é permitido.

33. SLA-Aware Scheduling

Cada operação poderá possuir:

interface SLARequirement {
  deadline?: string;

  maxLatencyMs?: number;

  priority: Priority;
}

34. Deadline Scheduling

Se houver:

Task A deadline = 5 min
Task B deadline = 2 hours

A deverá possuir maior urgência.

35. Human Capacity

Human-in-the-loop também é um recurso.

Exemplo:

Safety Reviewer
capacity = 50 reviews/day

O planner deverá considerar essa capacidade.

36. Human Queue

Agent
 ↓
Human Review Queue
 ↓
Reviewer
 ↓
Decision

37. Human Bottleneck

Se houver:

1000 reviews

capacity = 100/day

o sistema não deverá prometer conclusão imediata.

Deverá estimar:

estimated completion

38. Budget Resource

Orçamento também será tratado como recurso.

interface BudgetResource {
  budgetId: string;

  scope: "GLOBAL" | "TENANT" | "USER" | "AGENT";

  currency: string;

  limit: number;

  consumed: number;

  reserved: number;
}

39. LLM Budget

Poderá existir:

Tenant AI Budget

com:

daily token budget
monthly token budget
daily request budget

40. LLM Admission

Antes de chamar o LLM:

Need LLM?
 ↓
Budget available?
 ↓
Policy allows?
 ↓
Call

41. LLM Avoidance

Se uma operação puder ser resolvida por:

exact lookup
BM25
graph
deterministic rule
cached result

não deverá consumir LLM budget.

42. External API Budget

Integrações externas poderão possuir:

rate
quota
cost per request
daily budget

43. Cost-Aware Routing

Se existirem dois serviços equivalentes:

Provider A
$0.01/request

Provider B
$0.003/request

o planner poderá preferir B se:

funcionalmente equivalente;
autorizado;
suficientemente confiável;
dentro do SLA.

44. Primary/Secondary

Para serviços críticos:

PRIMARY
   ↓ failure
SECONDARY

deverá ser definido no Registry.

45. Circuit Breaker

Quando um recurso apresentar falhas repetidas:

CLOSED
 ↓
OPEN
 ↓
HALF_OPEN
 ↓
CLOSED

46. Circuit Breaker

O Resource Layer não deverá continuar enviando operações para um recurso claramente indisponível.

Isso evita:

failure storm

47. Backpressure

Quando a capacidade estiver saturada:

Producer
 ↓
Queue
 ↓
Consumer

em vez de permitir crescimento ilimitado de concorrência.

48. Queue Limits

Toda fila deverá possuir limite.

interface QueuePolicy {
  maxDepth: number;

  maxWaitMs: number;

  overflowStrategy:
    | "REJECT"
    | "DEFER"
    | "LOWER_PRIORITY"
    | "ESCALATE";
}

49. Load Shedding

Em condições extremas:

CRITICAL
HIGH
NORMAL
LOW
BACKGROUND

o sistema poderá descartar ou adiar:

BACKGROUND
LOW

antes de comprometer operações críticas.

50. Never Shed Critical Security

Nunca aplicar load shedding que prejudique:

auditoria obrigatória;
segurança;
autorização;
isolamento de tenant;
registros regulatórios críticos.

51. Resource Contention

Exemplo:

100 Work Permit tasks
       │
       ▼
Compliance API
       │
       ▼
capacity = 20

O sistema deverá:

batch
queue
parallelize within limit

em vez de simplesmente disparar 100 requests.

52. Adaptive Concurrency

O limite poderá adaptar-se conforme:

latency
error rate
queue depth
resource health
rate limit responses

53. Adaptive Concurrency Safety

O limite nunca poderá exceder:

hard configured maximum

54. Resource Health Metrics

Deverão ser coletados:

latency
error rate
timeout rate
concurrency
queue depth
throughput
rate-limit responses
availability

55. Capacity Forecast

O sistema poderá estimar:

current capacity
projected capacity

Exemplo:

Current:
70% utilization

Projected:
95% in 20 minutes

Isso poderá disparar:

PROACTIVE_REPLAN

56. Proactive Capacity

Integração com PRD-021:

Capacity trend
 ↓
Risk prediction
 ↓
Recommendation
 ↓
Resource adjustment

57. Resource Events

O Event Fabric poderá receber:

RESOURCE_AVAILABLE
RESOURCE_DEGRADED
RESOURCE_SATURATED
RESOURCE_UNAVAILABLE
QUOTA_WARNING
QUOTA_EXCEEDED
BUDGET_WARNING
CIRCUIT_OPENED
CIRCUIT_CLOSED
QUEUE_THRESHOLD_EXCEEDED

58. Event-Driven Replanning

Exemplo:

LMS_UNAVAILABLE
       ↓
Event Fabric
       ↓
Planning Engine
       ↓
Alternative resource
       ↓
Replan

59. Resource-Aware Replanning

O planner deverá receber:

oldPlan
resourceState
failedStep
availableAlternatives

e produzir:

newPlan

60. Resource Failure During Execution

Exemplo:

Step 1 ✓
Step 2 ✓
Step 3 → LMS timeout
Step 4 pending

O sistema deverá:

pause
 ↓
evaluate resource
 ↓
fallback/replan

61. Unknown Resource Outcome

Se a API responder:

timeout

sem sabermos se processou:

UNKNOWN

deverá ser mantido.

Nunca executar cegamente novamente se isso puder duplicar uma operação.

62. Idempotency

Toda operação potencialmente repetível deverá possuir:

idempotencyKey

63. Retry Budget

Cada operação poderá possuir:

interface RetryBudget {
  maxAttempts: number;

  maxDurationMs: number;

  maxCost?: number;
}

64. Retry Storm Protection

O sistema deverá limitar retries simultâneos.

100 failures

não deverão gerar:

500 retries

65. Resource Dependency Graph

Recursos poderão depender de outros:

Agent
 ↓
API
 ↓
Database

Se Database estiver indisponível:

Agent capacity = effectively unavailable

66. Dependency-Aware Capacity

A capacidade efetiva deverá considerar o gargalo:

Agent = 100 req/s
API = 50 req/s
DB = 20 req/s

Capacidade efetiva:

20 req/s

67. Bottleneck Detection

O sistema deverá identificar:

BOTTLENECK

e informar qual recurso limita o plano.

68. Example

Work Permit Release
 ↓
Training = 100/s
Risk = 100/s
Compliance = 20/s

Resultado:

Primary bottleneck:
Compliance API

69. Plan Optimization Integration

O PRD-032 poderá utilizar:

Resource Cost
Resource Latency
Resource Reliability
Resource Capacity

para escolher entre planos.

70. Example

Plan A
Compliance API
capacity available: 5%

Plan B
Verified internal source
capacity available: 70%

Mesmo que A seja normalmente preferido, B poderá ser escolhido se continuar atendendo todas as constraints.

71. Resource Reservation for Critical Plans

Para operações com SLA rígido:

Plan
 ↓
Reserve
 ↓
Execute

72. Reservation Failure

Se a reserva falhar:

Plan cannot be admitted

O sistema deverá:

queue
replan
defer

conforme policy.

73. Deadlock Prevention

O sistema deverá impedir:

Task A holds Resource 1
Task B holds Resource 2

A waits for Resource 2
B waits for Resource 1

74. Resource Acquisition Order

Recursos poderão possuir uma ordem canônica:

R1 → R2 → R3

para reduzir deadlocks.

75. Reservation Timeout

Reservas que não forem utilizadas deverão expirar automaticamente.

76. Starvation Prevention

Uma tarefa de baixa prioridade não poderá permanecer indefinidamente sem execução.

Deverá existir:

aging

de prioridade.

77. Tenant Isolation

Resource accounting deverá manter:

tenantId

em todas as operações.

Nunca:

Tenant A usage

ser confundido com:

Tenant B usage

78. Shared Resources

Quando um recurso for compartilhado:

Global API

deverá existir accounting separado:

global capacity
tenant allocation
tenant usage

79. Tenant Quota Hierarchy

Global Limit
 ↓
Tenant Limit
 ↓
User Limit
 ↓
Operation Limit

O menor limite efetivo deverá prevalecer.

80. Resource Policy

A Policy Engine deverá poder declarar:

tenant X
max concurrent = 10

ou:

capability Y
max batch = 100

81. Resource Policy ≠ Resource State

Policy:

maximum = 100

State:

available = 30

O planner deverá considerar ambos.

82. Resource State Snapshot

Antes da execução:

interface ResourceSnapshot {
  timestamp: string;

  resources: ResourceState[];

  version: string;
}

83. Stale Resource Snapshot

Como capacidade muda rapidamente, snapshots terão TTL.

snapshot age > TTL

→ revalidar.

84. Admission Revalidation

Mesmo que o planner tenha visto:

capacity = 20

antes de executar deverá verificar se:

capacity > 0

continua verdadeiro.

85. Resource Version

Cada recurso poderá possuir:

resourceVersion

para detectar mudanças.

86. Execution Context

O Execution Engine receberá:

interface ResourceExecutionContext {
  executionId: string;

  tenantId: string;

  resourceSnapshotVersion: string;

  reservations: string[];

  priority: Priority;

  deadline?: string;
}

87. Resource Lifecycle

DISCOVERED
 ↓
REGISTERED
 ↓
HEALTHY
 ↓
DEGRADED
 ↓
SATURATED
 ↓
UNAVAILABLE
 ↓
RECOVERING
 ↓
HEALTHY

88. Resource Discovery

Recursos poderão ser descobertos a partir de:

Capability Registry;
Agent Registry;
External Gateway;
Infrastructure configuration;
integrations;
human review queues.

89. Resource Registration

Nenhum recurso externo deverá ser automaticamente utilizado pelo LLM.

Ele deverá estar registrado.

90. Security Boundary

O Resource Registry nunca deverá expor ao LLM:

credentials;
tokens;
secrets;
internal network details desnecessários;
infraestrutura sensível.

O LLM poderá receber apenas abstrações como:

resource available
latency estimate
capacity class

91. Credential Separation

Conforme PRD-027:

Resource
 ↓
Credential Reference
 ↓
Credential Resolver

O planner nunca recebe o segredo.

92. External Gateway

Conforme PRD-025:

Planner
 ↓
Capability
 ↓
Resource Selection
 ↓
External Gateway
 ↓
Credential Resolver
 ↓
External Service

93. Communication Fabric

Conforme PRD-031:

Agent A
 ↓
Task
 ↓
Agent B

também deverá respeitar:

Agent B capacity
queue
priority
deadline
tenant quota

94. Workflow Integration

Workflows poderão declarar:

resource requirements

para determinadas etapas.

Exemplo:

WAITING_APPROVAL

depende de:

human reviewer capacity

95. Event Fabric Integration

Mudanças de capacidade deverão produzir eventos.

Isso permitirá que outros componentes reajam sem polling excessivo.

96. Exception Management

Resource failures deverão gerar exceções classificadas:

RESOURCE_UNAVAILABLE
RESOURCE_SATURATED
QUOTA_EXCEEDED
BUDGET_EXCEEDED
DEADLINE_EXCEEDED
RESERVATION_FAILED

97. Attention Center

Quando não houver capacidade suficiente:

Resource problem
 ↓
Attention Item

poderá ser criado quando intervenção humana for necessária.

98. Proactive Intelligence

Se o sistema detectar:

capacity projected to fail tomorrow

poderá produzir:

Recommendation:
increase capacity / change scheduling / adjust plan

99. Capacity Optimization

O sistema poderá otimizar:

parallelism
batch size
queue priority
resource selection
execution timing

100. Batch Size Optimization

Exemplo:

batch = 100

gera timeout.

Sistema aprende:

optimal batch = 25

Mas o limite máximo continuará sendo determinado por policy/capability.

101. Adaptive Batch

interface BatchPolicy {
  minSize: number;

  maxSize: number;

  initialSize: number;

  adaptationEnabled: boolean;
}

102. Burst Handling

Em situações de pico:

normal capacity
 ↓
burst
 ↓
queue
 ↓
adaptive execution

103. Burst Limits

Burst não poderá ultrapassar:

hard capacity
provider quota
tenant quota
security policy

104. Cost vs Capacity

Às vezes:

cheap resource
= saturated

expensive resource
= available

O planner poderá escolher o segundo se:

orçamento permitir;
SLA justificar;
policy permitir.

105. Capacity-Aware Cost Function

O score do PRD-032 poderá incluir:

cost
+
latency
+
risk
+
capacity pressure

106. Resource Pressure

Cada recurso poderá possuir:

pressure = 0..1

Exemplo:

20 = low
60 = moderate
90 = high

107. Pressure-Based Planning

O planner poderá evitar recursos com:

pressure > threshold

quando existir alternativa válida.

108. Resource Health Scoring

interface ResourceHealth {
  availability: number;

  latencyScore: number;

  errorScore: number;

  capacityScore: number;

  overall: number;
}

109. Health ≠ Trust

Um serviço pode estar:

healthy

mas possuir:

low trust

Esses conceitos permanecem separados.

110. Health ≠ Authorization

Um recurso disponível não significa que o usuário possa utilizá-lo.

111. Capacity-Aware Agent Communication

Antes de delegar:

Supervisor
 ↓
Agent Registry
 ↓
Resource Registry
 ↓
Capacity check
 ↓
Task

112. Queue-Based Delegation

Quando o agente estiver ocupado:

Task
 ↓
Agent Queue

em vez de criar outro agente arbitrariamente.

113. Agent Spawn

Se futuramente houver agentes dinamicamente provisionáveis, o spawn deverá ser controlado por:

policy
budget
capacity
release
tenant limits

O LLM não poderá simplesmente criar agentes ilimitadamente.

114. Resource Scaling

O PRD-033 poderá emitir:

SCALE_RECOMMENDATION

mas o mecanismo de infraestrutura deverá continuar separado.

115. No Infrastructure Bypass

Agentic Work não deverá executar arbitrariamente:

docker
kubectl
shell
cloud admin

para aumentar capacidade.

Qualquer operação desse tipo deverá ser uma capability registrada e fortemente protegida.

116. Observability

Cada execução deverá registrar:

resourceId
reservationId
queueTime
executionTime
capacityAtAdmission
capacityAtExecution
resourcePressure

117. Metrics

Métricas mínimas:

Resource Utilization
Queue Depth
Queue Wait Time
Admission Rate
Admission Rejection Rate
Reservation Failure Rate
Resource Saturation
Resource Availability
Resource Error Rate
Resource Timeout Rate
Quota Utilization
Budget Utilization

118. Planning Metrics

Também:

Resource-Aware Plan Selection
Capacity-Induced Replans
Resource-Induced Failures
Resource-Induced Latency

119. Cost Metrics

Por:

tenant
user
agent
capability
resource
workflow
execution

120. Alerting

Alertas deverão ocorrer quando:

quota > 80%
budget > 80%
capacity > 90%
queue > threshold
error rate > threshold
SLA breach predicted

121. Predictive Capacity

Com PRD-012/021, o sistema poderá aprender padrões:

Monday 08:00
↑ workload

e antecipar capacidade.

122. Resource Forecast

Exemplo:

Expected workload:
8,000 operations

Current capacity:
5,000

Predicted shortage:
3,000

Resultado:

PROACTIVE_CAPACITY_WARNING

123. Testing

O PRD-014 deverá incorporar testes de:

Saturation

resource = 100%

Queue overflow

queue > maxDepth

Quota

quota exceeded

Budget

budget exhausted

Failover

primary unavailable
secondary available

Deadlock

conflicting reservations

124. Chaos Testing

Simular:

API latency spike
API outage
agent outage
database slowdown
queue failure
rate limit
budget exhaustion
resource disappearance

125. Multi-Tenant Testing

Testar:

Tenant A overload

não poderá provocar:

Tenant B starvation

quando isolamento e fairness estiverem configurados.

126. Security Testing

Testar tentativas de:

bypass quota
cross-tenant resource
unauthorized reservation
resource enumeration
credential access
priority abuse
budget manipulation

127. Resource Audit

Toda decisão importante deverá registrar:

resource selected
resources rejected
reason
capacity
quota
budget
reservation

128. Resource Governance

Recursos críticos deverão possuir:

owner
classification
tenant scope
security level
SLA
limits
fallback
lifecycle

129. Resource Versioning

Mudanças relevantes deverão possuir:

resourceVersion
configurationVersion
policyVersion

130. Configuration Lifecycle

DRAFT
 ↓
VALIDATED
 ↓
ACTIVE
 ↓
DEPRECATED
 ↓
RETIRED

131. Resource Configuration Example

resource:
  id: compliance-api-primary
  type: API

  capacity:
    requestsPerSecond: 20
    maxConcurrency: 10

  health:
    timeoutMs: 3000

  fallback:
    pool: compliance-api-secondary

  limits:
    maxBatchSize: 50

132. Resource Admission Algorithm

Fluxo recomendado:

Validate authorization
Validate capability
Validate resource
Read resource snapshot
Evaluate quota
Evaluate budget
Evaluate concurrency
Evaluate deadline
Evaluate SLA
Reserve if required
Admit

133. Admission Result

interface AdmissionResult {
  decision:
    | "ADMIT"
    | "QUEUE"
    | "DEFER"
    | "REJECT";

  reason?: string;

  reservations: string[];

  estimatedStartAt?: string;

  estimatedCompletionAt?: string;
}

134. Example

{
  "decision": "QUEUE",
  "reason": "RESOURCE_SATURATED",
  "reservations": [],
  "estimatedStartAt": "2026-09-01T16:20:00Z"
}

135. First Vertical Slice — Work Permit Batch

Cenário:

100 Work Permits

Cada uma precisa:

Training
Risk
Compliance
Decision

136. Resource Constraints

Exemplo:

Training API:
20 concurrent

Risk:
10 concurrent

Compliance:
5 concurrent

137. Optimal Execution

O planner deverá evitar:

100 × 3 = 300 concurrent requests

e produzir algo semelhante a:

Training:
20 concurrent

Risk:
10 concurrent

Compliance:
5 concurrent

138. Queue

As operações excedentes deverão entrar em filas controladas.

100 permits
 ↓
Admission Controller
 ↓
bounded queues
 ↓
workers

139. Failure

Se Compliance ficar indisponível:

Training ✓
Risk ✓
Compliance ✗

o sistema deverá:

pause affected steps
 ↓
circuit breaker
 ↓
fallback/replan

sem bloquear desnecessariamente as operações que não dependem do serviço indisponível.

140. Tenant Isolation

Se:

Tenant A = 100 permits
Tenant B = 10 permits

A não poderá consumir toda a capacidade de Compliance.

141. Priority

Se Tenant B tiver uma operação:

deadline = 5 minutes

ela poderá receber prioridade sobre tarefas background de A, respeitando todas as demais regras.

142. Resource-Aware Replanning

Se:

Compliance capacity = 0

e existir:

verified internal compliance source

o sistema poderá mudar o plano.

143. If No Alternative

Se não houver alternativa:

WAITING_RESOURCE

e não:

FAILED

quando a operação ainda puder ser retomada.

144. Resource State Machine

AVAILABLE
    │
    ▼
BUSY
    │
    ▼
SATURATED
    │
    ▼
UNAVAILABLE
    │
    ▼
RECOVERING
    │
    ▼
AVAILABLE

145. Acceptance Criteria

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

O registry/pool de recursos é tenant-bound e suporta requisitos, reservas com lease, quotas por tenant/usuário/capability, orçamento, prioridade, deadline e admission idempotente. A manutenção assíncrona expira leases e a transição de health aplica circuit breaker, pressão e concorrência adaptativa. A decisão de admission carrega referências de workflow, comunicação, gateway externo e delegação, mas não concede autoridade de execução.

Em 2026-09-05, a suíte Resource Capacity passou com 19 testes em 4 arquivos. O canário remoto confirmou batch Work Permit tenant-isolado com concorrências selecionadas 5/10/20, bottleneck, previsão de término e custo, replay, circuit OPEN, admission afetada WAITING_RESOURCE, três leases liberados, plano DEGRADED, confirmação invalidada, recurso de failover, queue decision, load shedding seguro sem eliminar prioridade crítica, scheduler claim e decisões de orçamento/quota. A execução não concedeu autoridade e o cleanup confirmou remainingRows:0.

Em 2026-09-06, a regressão atual de runtime de capacidade, orquestração e admission passou com 12 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.

146. Resultado Arquitetural

Com o PRD-033, o Agentic Work passa a ter consciência dos recursos reais necessários para executar suas decisões.

A arquitetura passa a ser:

                         USER
                          │
                          ▼
                       INTENT
                          │
                          ▼
                    KNOWLEDGE
                          │
                          ▼
                       PLAN
                          │
                          ▼
                 RESOURCE ANALYSIS
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       CAPACITY          QUOTA            BUDGET
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                   ADMISSION CONTROL
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
           EXECUTE                   QUEUE
              │                       │
              ▼                       ▼
          MONITOR                 SCHEDULE
              │                       │
              └───────────┬───────────┘
                          ▼
                       REPLAN
                          │
                          ▼
                       VERIFY
                          │
                          ▼
                        RESULT

O resultado é uma arquitetura na qual Planning, Policy e Resource Management são independentes, mas trabalham conjuntamente:

Planning
"o que fazer?"

Policy
"podemos fazer?"

Resources
"podemos fazer agora?"

Execution
"faça."

Verification
"aconteceu corretamente?"

Essa separação será fundamental para permitir que o Agentic Work cresça para milhares de operações simultâneas sem transformar o sistema em um conjunto imprevisível de agentes disparando APIs indiscriminadamente.

PRD-034 — Agentic Adaptive Execution & Runtime Control

O próximo passo natural é sair do planejamento e do provisionamento de capacidade e tratar do comportamento do sistema durante a execução.

O PRD-034 deverá definir uma camada de Adaptive Execution, capaz de observar uma execução em andamento e ajustar seu comportamento em tempo real, sem violar o plano, a policy ou os limites de segurança.

A arquitetura evoluirá para:

                    APPROVED PLAN
                          │
                          ▼
                 ADAPTIVE EXECUTION
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       Execute          Monitor          Control
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                  Runtime State
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       Continue         Adapt            Replan
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
          Retry       Parallelism    Routing
             │            │            │
             └────────────┼────────────┘
                          ▼
                       Verify

Entre os temas desse próximo PRD estarão:

runtime control loop;
adaptive concurrency;
dynamic batching;
runtime routing;
speculative execution;
hedged requests;
retry adaptation;
timeout adaptation;
priority changes;
queue migration;
execution throttling;
graceful degradation;
partial execution;
runtime circuit breakers;
execution budgets;
adaptive model routing;
fallback;
runtime anomaly detection;
execution pause/resume;
safe runtime adaptation;
live replanning;
runtime policy enforcement;
protection contra runaway agents;
execution watchdog;
kill switch;
adaptive streaming;
runtime state machine;
execution checkpoints;
long-running execution control;
eBPF/infrastructure observability somente se necessário e sem acoplar o domínio ao ambiente de infraestrutura;
e integração profunda com PRD-024, PRD-032 e PRD-033.

O princípio central será:

O Runtime poderá adaptar a forma de executar um plano, mas nunca poderá transformar uma execução não autorizada em autorizada.

1. Objetivo​

2. Problema

3. Princípio fundamental

4. Arquitetura

5. Resource Model

6. Resource Capacity

7. Capacity Types

Concurrency​

Rate​

Quota​

Budget​

Human capacity​

8. Resource Registry

9. Resource Registry ≠ Capability Registry

Capability Registry​

Resource Registry​

10. Resource Pools

11. Resource Pool

12. Agent Capacity

13. Agent Health

14. Agent Selection

15. Resource Requirement

16. Example

17. Resource-Aware Planning

18. Admission Control

19. Admission Control

20. Admission ≠ Authorization

21. Resource Reservation

22. Reservation TTL

23. Lease

24. Lease Expiration

25. Concurrency Control

26. Rate Limiting

27. Quotas

28. Tenant Quota

29. Fairness

30. Scheduling

31. Priority Levels

32. Priority não pode ignorar Security

33. SLA-Aware Scheduling

34. Deadline Scheduling

35. Human Capacity

36. Human Queue

37. Human Bottleneck

38. Budget Resource

39. LLM Budget

40. LLM Admission

41. LLM Avoidance

42. External API Budget

43. Cost-Aware Routing

44. Primary/Secondary

45. Circuit Breaker

46. Circuit Breaker

47. Backpressure

48. Queue Limits

49. Load Shedding

50. Never Shed Critical Security

51. Resource Contention

52. Adaptive Concurrency

53. Adaptive Concurrency Safety

54. Resource Health Metrics

55. Capacity Forecast

56. Proactive Capacity

57. Resource Events

58. Event-Driven Replanning

59. Resource-Aware Replanning

60. Resource Failure During Execution

61. Unknown Resource Outcome

62. Idempotency

63. Retry Budget

64. Retry Storm Protection

65. Resource Dependency Graph

66. Dependency-Aware Capacity

67. Bottleneck Detection

68. Example

69. Plan Optimization Integration

70. Example

71. Resource Reservation for Critical Plans

72. Reservation Failure

73. Deadlock Prevention

1. Objetivo

Concurrency

Rate

Quota

Budget

Human capacity

Capability Registry

Resource Registry

Saturation

Queue overflow

Quota

Budget

Failover

Deadlock