PRD-039 — Agentic Resource & Workforce Coordination Fabric

1. Objetivo

O PRD-039 cria a camada responsável por determinar quem ou qual recurso pode realizar uma tarefa, considerando capacidade, disponibilidade, competências, qualificações, carga, localização, prioridade, custo, SLA e regras organizacionais.

A partir deste PRD, o Agentic Work deixa de apenas decidir:

“O que precisa ser feito?”

e passa a responder também:

“Quem ou o que deve fazer isso?”

2. Contexto Arquitetural

Até aqui temos:

GOAL
 ↓
TASK
 ↓
PLAN
 ↓
CAPABILITY
 ↓
POLICY
 ↓
EXECUTION

O PRD-039 introduz:

TASK
 ↓
RESOURCE REQUIREMENTS
 ↓
RESOURCE DISCOVERY
 ↓
QUALIFICATION
 ↓
AVAILABILITY
 ↓
CAPACITY
 ↓
ALLOCATION
 ↓
ASSIGNMENT
 ↓
EXECUTION

3. Princípio Fundamental

O Agent não poderá escolher um recurso apenas porque:

“parece ser a melhor pessoa”.

A seleção deverá ser baseada em dados verificáveis.

Candidate
 ↓
Qualification
 ↓
Authorization
 ↓
Availability
 ↓
Capacity
 ↓
Policy
 ↓
Allocation

4. Resource

Um Resource é qualquer entidade capaz de participar de uma operação.

HUMAN
TEAM
AGENT
SERVICE
API
MACHINE
DEVICE
FACILITY
VEHICLE
EXTERNAL_PROVIDER

5. Resource Registry

O sistema deverá possuir um catálogo lógico:

interface Resource {
  resourceId: string;

  tenantId: string;

  type: ResourceType;

  name: string;

  status: ResourceStatus;

  capabilities: string[];

  skills: string[];

  qualifications: string[];

  availability?: AvailabilityRef;

  capacity?: CapacityModel;

  location?: LocationRef;

  metadata?: Record<string, unknown>;
}

6. Resource Types

type ResourceType =
  | "HUMAN"
  | "TEAM"
  | "AGENT"
  | "SERVICE"
  | "API"
  | "MACHINE"
  | "DEVICE"
  | "FACILITY"
  | "VEHICLE"
  | "EXTERNAL_PROVIDER";

7. Resource Status

AVAILABLE
BUSY
UNAVAILABLE
OFFLINE
SUSPENDED
MAINTENANCE
EXPIRED
UNKNOWN

UNKNOWN deverá ser tratado explicitamente.

O sistema não deverá interpretar:

UNKNOWN = AVAILABLE

8. Resource Capability

Um recurso pode possuir:

capabilities:
  - workPermit.review
  - workPermit.approve
  - training.review

Mas possuir uma Capability registrada não significa automaticamente possuir autorização.

A Policy continua sendo a autoridade.

9. Skill

Skill representa uma competência operacional.

Exemplos:

industrial-risk
electrical-safety
confined-space
work-permit-review
training-management

10. Qualification

Qualification representa uma comprovação formal.

Exemplo:

Skill:
industrial-risk

Qualification:
NR-10

Valid until:
2027-05-12

11. Skill ≠ Qualification

Uma pessoa pode ter:

skill = electrical-safety

mas não possuir uma certificação válida necessária para determinada operação.

Portanto:

Skill
≠
Qualification

12. Qualification Validation

Antes da atribuição:

Resource
 ↓
Qualification
 ↓
valid?
 ├── YES
 └── NO

Qualificações expiradas não poderão satisfazer requisitos obrigatórios.

13. Qualification Temporal Awareness

A validade deverá considerar:

validFrom
validUntil
currentDate
businessCalendar
timezone

Integrando diretamente com PRD-037.

14. Workforce Resource

Para humanos:

interface HumanResource extends Resource {
  type: "HUMAN";

  userId: string;

  organizationalUnitId?: string;

  roles: string[];

  skills: string[];

  qualifications: string[];

  supervisorId?: string;

  shiftId?: string;
}

15. Organizational Structure

O Resource Fabric deverá compreender:

Organization
 └── Division
      └── Department
           └── Team
                └── Employee

Isso permitirá routing baseado em estrutura organizacional.

16. Team Resource

Um Team também será um recurso:

interface TeamResource {
  teamId: string;

  tenantId: string;

  name: string;

  members: string[];

  skills: string[];

  capacity: CapacityModel;
}

17. Team vs Individual Assignment

Uma tarefa poderá ser direcionada para:

TEAM

e posteriormente distribuída para:

USER

ou diretamente:

USER

18. Agent Resource

Agents também podem ser recursos.

Exemplo:

training-agent
risk-agent
decision-agent
notification-agent

Cada agente terá:

capabilities
skills
limits
availability
cost
trust level

19. Human + Agent Workforce

A arquitetura deverá permitir:

Human
   +
Agent
   +
System

trabalhando no mesmo processo.

Exemplo:

Agent:
analisa 1.000 Work Permits

Human:
revisa os 12 casos críticos

20. Resource Requirements

Cada Task poderá declarar requisitos:

interface ResourceRequirement {
  requirementId: string;

  skills?: SkillRequirement[];

  qualifications?: QualificationRequirement[];

  capabilities?: string[];

  resourceTypes?: ResourceType[];

  minimumCapacity?: number;

  location?: LocationConstraint;

  availability?: TemporalConstraint;

  authorization?: string;

  maxCost?: number;
}

21. Mandatory vs Preferred

Requisitos poderão ser:

MANDATORY
PREFERRED
OPTIONAL

Exemplo:

NR-10 = MANDATORY
5 years experience = PREFERRED
same location = OPTIONAL

22. Candidate Discovery

O sistema deverá primeiro encontrar candidatos compatíveis.

Task
 ↓
Requirements
 ↓
Resource Registry
 ↓
Candidate Set

Não utilizar LLM para pesquisar todos os recursos.

23. Candidate Filtering

Filtros determinísticos:

tenant
status
authorization
qualification
skill
availability
capacity
location

24. Candidate Ranking

Depois do filtro:

Candidate A
Candidate B
Candidate C

poderão ser classificados.

25. Resource Score

Exemplo conceitual:

score =
skillMatch
+ qualificationMatch
+ availability
+ capacity
+ workload
+ proximity
+ SLAFit
+ cost

Os pesos deverão ser configuráveis por domínio/policy.

26. Hard Constraints

Nunca poderão ser compensadas por score.

Exemplo:

NR-10 expired

não poderá ser compensado por:

"excellent experience"

27. Soft Constraints

Podem influenciar ranking:

proximity
preferred team
historical workload
preferred channel
estimated cost

28. Policy Boundary

O Resource Fabric poderá dizer:

“João é o melhor candidato.”

Mas somente Policy poderá dizer:

“João está autorizado.”

29. Availability

Disponibilidade deverá ser temporal.

interface AvailabilityWindow {
  resourceId: string;

  startAt: string;

  endAt: string;

  status: "AVAILABLE" | "UNAVAILABLE" | "RESERVED";
}

30. Shift

Para trabalhadores:

Shift
 ├── timezone
 ├── start
 ├── end
 ├── workingDays
 └── exceptions

deverá utilizar o calendário do PRD-037.

31. Capacity

Disponibilidade não significa capacidade.

Exemplo:

João:
AVAILABLE

Current workload:
95%

Ele pode estar disponível, mas sem capacidade suficiente.

32. Capacity Model

interface CapacityModel {
  unit: string;

  total: number;

  allocated: number;

  reserved: number;

  available: number;
}

33. Human Capacity

Para humanos:

capacityUnit = HOURS

Exemplo:

8h/day
allocated = 6h
available = 2h

34. Agent Capacity

Para Agents:

requests/minute
concurrentTasks
tokenBudget
computeBudget

35. Machine Capacity

Para máquinas:

cycles
hours
throughput
maintenance windows

36. Resource Reservation

Antes de uma operação importante, o sistema poderá reservar capacidade.

DISCOVER
 ↓
RESERVE
 ↓
ASSIGN
 ↓
EXECUTE
 ↓
RELEASE

37. Reservation Model

interface ResourceReservation {
  reservationId: string;

  resourceId: string;

  tenantId: string;

  operationId: string;

  startAt: string;

  endAt: string;

  capacity: number;

  status: ReservationStatus;
}

38. Reservation Lifecycle

REQUESTED
 ↓
RESERVED
 ↓
ACTIVE
 ↓
CONSUMED
 ↓
RELEASED

Alternativas:

EXPIRED
CANCELLED
FAILED

39. Double Booking Protection

Duas operações não deverão reservar a mesma capacidade.

Deverá existir:

optimistic concurrency
+
reservation version

40. Resource Lock

Para recursos exclusivos:

Machine X
 ↓
LOCKED by operation-123

Outro processo deverá receber:

RESOURCE_CONFLICT

41. Partial Capacity

Para recursos divisíveis:

capacity = 100
allocated = 40

poderão existir múltiplas alocações.

42. Allocation

Allocation representa a distribuição efetiva de capacidade.

interface ResourceAllocation {
  allocationId: string;

  resourceId: string;

  operationId: string;

  amount: number;

  unit: string;

  startAt: string;

  endAt?: string;

  status: string;
}

43. Assignment

Assignment liga a tarefa ao recurso.

Task
 ↓
Assignment
 ↓
Resource

44. Assignment Lifecycle

PROPOSED
 ↓
PENDING_ACCEPTANCE
 ↓
ACCEPTED
 ↓
ACTIVE
 ↓
COMPLETED

Alternativas:

REJECTED
EXPIRED
REASSIGNED
CANCELLED

45. Human Acceptance

Determinadas tarefas poderão exigir que o humano aceite.

Exemplo:

“Você foi designado para revisar 20 Work Permits.”

O usuário poderá:

ACEITAR
RECUSAR
DELEGAR

46. Automatic Assignment

Para tarefas de baixo risco:

Task
 ↓
Resource Matching
 ↓
Policy
 ↓
Auto Assignment

47. Assignment Policy

interface AssignmentPolicy {
  policyId: string;

  allowedResourceTypes: ResourceType[];

  autoAssign: boolean;

  requireAcceptance: boolean;

  maxWorkload: number;

  escalationPolicy?: string;
}

48. Reassignment

Se:

resource unavailable

o sistema poderá procurar:

alternative candidate

sem alterar a autorização da tarefa.

49. Dynamic Reassignment

Durante execução:

Resource A
 ↓
UNAVAILABLE
 ↓
Resource B

Essa alteração deverá passar pelo PRD-034 Adaptive Execution.

50. Material Reassignment

Se a troca alterar:

autoridade;
responsabilidade;
risco;
qualificação;
escopo;

deverá ocorrer nova avaliação de Policy.

51. Delegation

Uma pessoa poderá delegar:

Task A
 ↓
João
 ↓
Maria

mas apenas se PRD-027 permitir.

52. Delegation ≠ Reassignment

Delegação significa:

autoridade operacional temporariamente delegada.

Reassignment significa:

tarefa transferida para outro recurso.

São conceitos distintos.

53. Workload

O sistema deverá acompanhar:

activeTasks
pendingTasks
estimatedHours
overdueTasks
capacityUtilization

54. Workload Score

utilization =
allocatedCapacity / totalCapacity

Exemplo:

80%

55. Overload

Se:

utilization > threshold

o sistema poderá:

route elsewhere
queue
escalate
request additional resources

56. Fairness

Quando vários recursos são equivalentes, o sistema poderá distribuir tarefas de forma equilibrada.

Exemplo:

João 20 tarefas
Maria 5 tarefas

Uma nova tarefa poderá preferir Maria.

57. Fairness ≠ Absolute Equality

A distribuição deverá respeitar:

capacidade;
competências;
jornada;
SLA;
prioridade;
responsabilidade.

58. Skill Matching

Exemplo:

Task:
Review electrical Work Permit

Required:
skill = electrical-safety
qualification = NR-10

Candidate:

João
✓ skill
✓ qualification
✓ available
✓ authorized

→ candidato válido.

59. Qualification Expiration

Se:

NR-10 expires tomorrow

e a tarefa dura:

3 days

a alocação deverá ser rejeitada ou marcada como risco, conforme Policy.

60. Temporal Resource Fit

A seleção deverá considerar o período inteiro da tarefa.

Task:
10/09 08:00 → 10/09 17:00

Resource:
available 08:00 → 12:00

não é full match.

61. Location

Quando relevante:

resource.location
task.location

poderão ser comparados.

62. Remote vs Physical

Uma tarefa poderá exigir:

REMOTE
ONSITE
HYBRID

63. Geographic Constraints

Para tarefas físicas:

distance
travelTime
location
facility
region

poderão ser considerados.

64. Resource Dependencies

Um recurso poderá depender de outro:

Inspector
 ↓
requires
 ↓
Equipment

A tarefa só poderá começar quando ambos estiverem disponíveis.

65. Composite Resource

Uma operação poderá exigir:

1 inspector
+
1 equipment
+
1 facility

66. Resource Bundle

interface ResourceBundle {
  bundleId: string;

  requirements: ResourceRequirement[];

  resources: string[];

  validFrom: string;

  validUntil?: string;
}

67. Planning Integration

PRD-032 poderá solicitar:

Qual combinação de recursos produz o menor custo respeitando SLA?

O Resource Fabric fornecerá:

candidate resources
capacity
availability
cost
constraints

68. Runtime Integration

PRD-034 poderá informar:

resource degraded

e solicitar:

alternative resource

69. Attention Integration

PRD-038 poderá produzir:

Attention
 ↓
required skill
 ↓
Resource Fabric
 ↓
assignment

70. Goal Integration

Um Goal poderá exigir:

maintain compliance

e o Resource Fabric determinar:

who can perform remediation

71. Workflow Integration

Workflow:

WAITING_REVIEW

poderá procurar automaticamente:

qualified reviewer

72. Event Integration

Eventos como:

TrainingExpired
EmployeeUnavailable
ResourceOffline
QualificationExpired

poderão disparar reavaliação de assignments.

73. State Integration

Qualquer mudança importante deverá refletir no State Fabric.

Exemplo:

Employee
qualification expired
 ↓
State Fabric
 ↓
assignment invalidated

74. Knowledge Integration

Knowledge Fabric poderá fornecer:

organizational relationships
skills
qualifications
dependencies

mas o estado operacional deverá continuar vindo das fontes autoritativas.

75. External Resource

Recursos externos poderão ser consultados através do PRD-025.

Exemplo:

External Inspector
 ↓
External Provider API

76. External Availability

O sistema poderá consultar:

availability
qualification
booking
status

sem expor credenciais ao Agent.

77. Cost

Recursos poderão ter custo:

interface ResourceCost {
  resourceId: string;

  unit: string;

  amount: number;

  currency: string;

  effectiveFrom: string;

  effectiveUntil?: string;
}

78. Cost-Aware Assignment

Quando dois recursos são equivalentes:

Resource A = $100
Resource B = $70

poderá ser escolhido B.

Mas custo nunca poderá violar:

qualification
authorization
safety
SLA
policy

79. Priority-Aware Allocation

Uma tarefa crítica poderá receber prioridade sobre tarefas normais.

CRITICAL
 ↓
HIGH
 ↓
NORMAL
 ↓
LOW

80. Preemption

Em determinadas operações poderá existir preempção:

Task normal
 ↓
pause
 ↓
Task critical

Isso deverá ser explicitamente permitido pela Policy.

81. No Arbitrary Preemption

O Agent não poderá interromper trabalho humano ou físico simplesmente para “otimizar”.

82. Queueing

Quando não houver capacidade:

Task
 ↓
QUEUE
 ↓
WAIT
 ↓
RESOURCE AVAILABLE
 ↓
ASSIGN

83. Queue Priority

A fila deverá considerar:

priority
deadline
SLA
risk
goal importance

84. SLA Risk

Uma tarefa próxima de violar SLA poderá receber prioridade maior.

Integração com PRD-037:

SLA
 ↓
remaining time
 ↓
resource allocation

85. Capacity Forecasting

O sistema poderá prever:

tomorrow:
capacity shortage

next week:
40% overload

Isso alimentará o PRD-021 Proactive Intelligence.

86. Predictive Capacity

Modelos estatísticos poderão auxiliar:

expected workload
expected availability
expected demand

O LLM não deverá ser a fonte primária dessa previsão.

87. Workforce Risk

Exemplo:

Only one qualified person
for critical capability

→ risco organizacional.

88. Single Point of Failure

O sistema deverá detectar:

Capability:
workPermit.approve

Qualified resources:
1

e gerar:

WORKFORCE_SINGLE_POINT_OF_FAILURE

89. Qualification Gap

Exemplo:

Required:
10 qualified inspectors

Available:
6

→:

CAPACITY_GAP

90. Proactive Action

O sistema poderá gerar:

Attention:
qualification capacity insufficient

Goal:
increase qualified workforce

91. Human Development

O Resource Fabric poderá identificar:

skill gap
qualification gap
training gap

mas não poderá automaticamente alterar dados de RH sem Capability e Policy.

92. Resource Health

Recursos sistêmicos poderão ter:

HEALTHY
DEGRADED
CRITICAL
UNKNOWN

93. Agent Health

Exemplo:

training-agent
 ↓
HEALTHY

risk-agent
 ↓
DEGRADED

O Planner poderá procurar alternativa.

94. Service Health

APIs externas também serão tratadas como recursos:

LMS API
 ↓
DEGRADED

95. Resource Discovery API

A camada deverá oferecer operações como:

resource.search
resource.get
resource.checkAvailability
resource.checkQualification
resource.reserve
resource.release
resource.assign
resource.reassign

Todas registradas no Capability Registry.

96. Resource Registry ≠ Capability Registry

Capability Registry responde:

“O que o Agent pode fazer?”

Resource Registry responde:

“Quem ou o que pode realizar isso?”

97. Assignment Engine

Componente principal:

Assignment Engine
 ├── Requirement Resolver
 ├── Candidate Finder
 ├── Qualification Validator
 ├── Availability Checker
 ├── Capacity Checker
 ├── Policy Evaluator
 ├── Candidate Ranker
 ├── Reservation Manager
 └── Assignment Manager

98. Deterministic First

Fluxo:

requirements
 ↓
indexes
 ↓
filters
 ↓
policy
 ↓
ranking

LLM somente quando houver necessidade semântica.

99. LLM-Assisted Matching

Pode ser usado para interpretar:

“Preciso de alguém que tenha experiência com espaços confinados e conheça esse tipo de operação.”

O LLM transforma isso em requisitos estruturados:

{
  "skills": [
    "confined-space",
    "industrial-operation"
  ]
}

Depois disso:

Registry
+
Policy

fazem a seleção real.

100. No LLM Authority

O LLM jamais poderá dizer:

"João está autorizado."

sem validação do Policy Engine.

101. Assignment Decision

interface AssignmentDecision {
  decisionId: string;

  taskId: string;

  selectedResourceId?: string;

  alternatives: string[];

  requirementsSatisfied: boolean;

  policyResult: string;

  confidence?: number;

  reasonCodes: string[];
}

102. Explainability

O sistema deverá conseguir explicar:

João foi selecionado porque possui a qualificação exigida, está disponível no período, possui capacidade e está autorizado pela política aplicável.

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

103. Assignment Conflict

Se dois processos tentarem atribuir:

sameResource
sameExclusiveCapacity

o segundo deverá receber:

RESOURCE_ALLOCATION_CONFLICT

104. Recovery

Após conflito:

retry
 ↓
rediscover candidates
 ↓
reallocate

ou:

WAIT

ou:

HUMAN_REVIEW

105. Resource Versioning

Todo recurso relevante deverá possuir:

resourceVersion

Exemplo:

qualification changed
version 12 → 13

106. Stale Assignment

Se o assignment foi criado com:

resourceVersion = 12

e agora:

resourceVersion = 13

o sistema deverá verificar se a mudança impacta a operação.

107. Impact Levels

NO_IMPACT
LOW
MATERIAL
CRITICAL

108. Security

Todo acesso deverá ser tenant-aware.

tenant A
 ≠
tenant B

109. Resource Privacy

Nem todos os atributos de um funcionário poderão ser expostos ao Agent.

Por exemplo:

salary
personalAddress
privateHRData

não são necessários para assignment normal.

110. Minimum Necessary Data

O Assignment Engine deverá receber apenas:

skills
qualifications
availability
capacity
authorization
organizational context

quando isso for suficiente.

111. Audit

Registrar:

resource discovered
candidate rejected
qualification checked
policy evaluated
resource selected
reservation created
assignment created
assignment accepted
assignment rejected
resource reassigned
reservation released

112. Assignment Reason Codes

Exemplos:

QUALIFICATION_MATCH
SKILL_MATCH
CAPACITY_AVAILABLE
SLA_OPTIMIZATION
LOWEST_COST
NEAREST_RESOURCE
WORKLOAD_BALANCING
POLICY_REQUIRED

113. Rejection Reasons

QUALIFICATION_MISSING
QUALIFICATION_EXPIRED
SKILL_MISSING
UNAVAILABLE
CAPACITY_EXCEEDED
UNAUTHORIZED
TENANT_MISMATCH
LOCATION_MISMATCH
SHIFT_CONFLICT
RESOURCE_SUSPENDED
POLICY_DENIED

114. Observability

Métricas:

candidate_search_latency
assignment_latency
assignment_success_rate
assignment_conflict_rate
resource_utilization
capacity_gap
qualification_gap
reassignment_rate
queue_wait_time
SLA_assignment_failure

115. Performance

O caminho normal deverá evitar LLM.

Metas iniciais:

Resource lookup:
< 20ms ideal

Candidate filtering:
< 50ms ideal

Assignment decision:
< 100ms ideal

Simple assignment:
< 250ms target

Operações externas deverão ser assíncronas quando necessário.

116. Caching

Poderão ser cacheados:

skills
qualification metadata
organizational structure
resource capabilities

Nunca cachear autorização de forma que permita ultrapassar mudanças de Policy.

117. Invalidation

Mudanças em:

qualification
availability
status
authorization
tenant

deverão invalidar caches relevantes.

118. Multi-Tenant

Todos os índices deverão incluir:

tenantId

quando o dado for tenant-scoped.

Não utilizar:

global resource cache

sem isolamento explícito.

119. Resource Federation

Para organizações grandes:

Global Registry
 +
Tenant Registry
 +
External Registry

poderão ser combinados através de referências.

120. First Vertical Slice

O primeiro caso será:

Distribuição automática de revisão de Work Permits considerando competência, qualificação, disponibilidade e carga de trabalho.

121. Scenario

Existem:

100 Work Permits

que precisam de revisão.

Requisitos:

skill = work-permit-review
qualification = required certification

122. Candidate Discovery

Sistema encontra:

João
Maria
Carlos
Ana

123. Qualification

João ✓
Maria ✓
Carlos ✗ expired
Ana ✓

Carlos é eliminado.

124. Availability

João   ✓
Maria  ✓
Ana    ✗

Ana é eliminada.

125. Capacity

João:
90%

Maria:
30%

Maria será preferida para tarefas equivalentes.

126. Assignment

100 Work Permits
 ↓
Assignment Engine
 ↓
Maria 40
João 60

respeitando os limites configurados.

127. Attention

Se a capacidade disponível for insuficiente:

100 permits
required capacity = 100h
available = 65h

o sistema cria:

Attention:
Work Permit Review Capacity Gap

128. Proactive Intelligence

PRD-021 poderá detectar:

capacity shortage expected next week

e criar uma recomendação.

129. Goal

PRD-036 poderá acompanhar:

Goal:
Review all pending Work Permits within SLA

130. Temporal Intelligence

PRD-037 fornece:

deadline
SLA
working hours
shift
holiday

131. Adaptive Runtime

PRD-034 poderá alterar:

batch size
parallelism
resource assignment

quando permitido.

132. State Fabric

PRD-035 garante:

assignment
resource
task
workflow
business state

permaneçam sincronizados.

133. Exception Management

Se um recurso falhar:

ResourceUnavailable
 ↓
PRD-024
 ↓
Rediscovery
 ↓
Reassignment

134. Event Fabric

Eventos:

ResourceAssigned
ResourceUnavailable
AssignmentAccepted
AssignmentRejected
ResourceCapacityChanged
QualificationExpired
AssignmentReassigned

135. Human Collaboration

Quando nenhum recurso adequado existir:

NO_QUALIFIED_RESOURCE

o sistema não deverá improvisar.

Deverá:

Attention
 ↓
Human Review
 ↓
Decision

136. Safety Principle

Em SST:

Ausência de recurso qualificado não pode ser tratada como autorização para utilizar um recurso não qualificado.

Esse princípio deverá ser uma regra global de segurança.

137. Acceptance Criteria

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

O núcleo determinístico workforce-coordination separa hard constraints de score configurável, exige decisão Policy ALLOW por capability e valida tenant, status, qualificação durante a janela inteira, disponibilidade, shift IANA, exceções, capacidade, workload, localização, modo, SLA, custo, health e trust.
A migration D1 0113_workforce_coordination.sql versiona policies, decisões de autorização, shifts, dependências, bundles, decisões explicáveis, reservations, allocations, delegações, queues, forecasts, health e reconciliações; históricos críticos são append-only e o banco rejeita conflito de capacidade/exclusividade.
O fluxo persistente implementa DISCOVER → REQUESTED → RESERVED → ASSIGN → ACCEPT → ACTIVE → COMPLETE → CONSUMED → RELEASED, mantém delegation PRD-027 distinta de reassignment e encaminha mudança material de State para reevaluation e Adaptive Runtime.
Replay limpo aplicou 113/113 migrations; 28 testes focados, 297 testes predeploy e 206 testes de exceções passaram, além dos typechecks.
D1 remoto aplicou 89 comandos; Worker bf937931-0292-4b6f-b928-72b889790103 e canário tenant 4089e296-728c-422c-bef6-a3a4e1883ef6 provaram 2 humanos + Agent + Machine, ranking custo/fairness, shift recorrente, bundle dependente, conflito de double booking com Exception, lifecycles completos, delegação humana, State→Adaptive, health recovery, queue/SLA, forecast 6/10 com gap 4 e SPOF, preemption protegida, timeline, métricas, isolamento e acesso anônimo negado.
Tamper remoto de policy foi rejeitado com WORKFORCE_POLICY_IMMUTABLE; todas as respostas de coordenação mantiveram authorizesExecution=false e o cleanup PostgreSQL terminou com zero linhas.
Em 2026-09-05, saúde UNKNOWN passou a ser fail-closed: tanto o evento de saúde quanto a reconciliação com State Fabric exigem reatribuição e reavaliação de política. Assim, ausência ou divergência de sinal não mantém recurso ativo como se estivesse disponível. Worker dddeb95f-7495-42b2-905a-c47a94b15791 publicado com health público saudável.
Em 2026-09-06, a regressão atual de recursos operacionais, Workforce Coordination e Workforce Registry passou com 17 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.

138. Resultado Arquitetural

Com o PRD-039, o Agentic Work passa a possuir uma visão completa de trabalho + recursos:

                         GOAL
                          │
                          ▼
                         TASK
                          │
                          ▼
                  RESOURCE REQUIREMENTS
                          │
                          ▼
                   RESOURCE REGISTRY
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
       SKILLS       QUALIFICATIONS      CAPACITY
          │               │                │
          └───────────────┼────────────────┘
                          ▼
                     AVAILABILITY
                          │
                          ▼
                       POLICY
                          │
                          ▼
                  ASSIGNMENT ENGINE
                          │
                          ▼
                  RESERVATION / ALLOCATION
                          │
                          ▼
                       RESOURCE
                          │
                          ▼
                      EXECUTION
                          │
                          ▼
                    VERIFICATION

O sistema agora consegue raciocinar sobre:

objetivo → tarefa → requisitos → recursos → competência → disponibilidade → capacidade → autorização → atribuição → execução → resultado.

Isso transforma o Agentic Work em uma arquitetura capaz de coordenar humanos, agentes e sistemas como uma força de trabalho digital integrada, sem permitir que otimização de recursos ultrapasse limites de segurança ou autorização.

PRD-040 — Agentic Collaboration, Handoff & Approval Workspace

A próxima camada será construída sobre PRD-039.

Até aqui sabemos quem pode executar o trabalho. O próximo problema é coordenar o trabalho entre pessoas, agentes e equipes.

O PRD-040 deverá formalizar:

TASK
 ↓
ASSIGNMENT
 ↓
COLLABORATION
 ↓
HANDOFF
 ↓
REVIEW
 ↓
APPROVAL
 ↓
EXECUTION
 ↓
VERIFICATION

Ele deverá tratar, entre outros:

Collaboration Workspace;
Human ↔ Human collaboration;
Human ↔ Agent collaboration;
Agent ↔ Agent handoff;
Task ownership;
Co-ownership;
Handoff contracts;
Evidence transfer;
Context transfer;
Approval workspace;
Review queues;
Comments;
Annotations;
Mentions;
Decision requests;
Request for information;
Acceptance/rejection;
Multi-step approval;
Quorum;
Two-person rule;
Segregation of duties;
Approval delegation;
Approval expiration;
Approval escalation;
Collaborative decision making;
Shared operational context;
Conflict resolution;
Concurrent editing;
Optimistic locking;
Presence;
Activity timeline;
Human takeover;
Agent pause;
Agent resume;
Human override;
Agent recommendation vs human decision;
Evidence provenance;
Audit;
Security;
Tenant isolation;
Notifications;
Attention Center;
Identity and Delegation;
Workflow;
Decision Intelligence;
Resource Coordination;
State Synchronization;
Event Fabric;
Temporal Intelligence.

O objetivo será fechar uma lacuna importante:

o Agentic Work não deve apenas executar tarefas; ele deve saber transferir responsabilidade, solicitar participação humana, conduzir aprovações e trabalhar colaborativamente com pessoas e outros agentes.

1. Objetivo​

2. Contexto Arquitetural

3. Princípio Fundamental

4. Resource

5. Resource Registry

6. Resource Types

7. Resource Status

8. Resource Capability

9. Skill

10. Qualification

11. Skill ≠ Qualification

12. Qualification Validation

13. Qualification Temporal Awareness

14. Workforce Resource

15. Organizational Structure

16. Team Resource

17. Team vs Individual Assignment

18. Agent Resource

19. Human + Agent Workforce

20. Resource Requirements

21. Mandatory vs Preferred

22. Candidate Discovery

23. Candidate Filtering

24. Candidate Ranking

25. Resource Score

26. Hard Constraints

27. Soft Constraints

28. Policy Boundary

29. Availability

30. Shift

31. Capacity

32. Capacity Model

33. Human Capacity

34. Agent Capacity

35. Machine Capacity

36. Resource Reservation

37. Reservation Model

38. Reservation Lifecycle

39. Double Booking Protection

40. Resource Lock

41. Partial Capacity

42. Allocation

43. Assignment

44. Assignment Lifecycle

45. Human Acceptance

46. Automatic Assignment

47. Assignment Policy

48. Reassignment

49. Dynamic Reassignment

50. Material Reassignment

51. Delegation

52. Delegation ≠ Reassignment

53. Workload

54. Workload Score

55. Overload

56. Fairness

57. Fairness ≠ Absolute Equality

58. Skill Matching

59. Qualification Expiration

60. Temporal Resource Fit

61. Location

62. Remote vs Physical

63. Geographic Constraints

64. Resource Dependencies

65. Composite Resource

66. Resource Bundle

67. Planning Integration

68. Runtime Integration

69. Attention Integration

70. Goal Integration

71. Workflow Integration

72. Event Integration

73. State Integration

74. Knowledge Integration

75. External Resource

76. External Availability

77. Cost

78. Cost-Aware Assignment

79. Priority-Aware Allocation

80. Preemption

1. Objetivo

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