PRD-036 — Agentic Goal Management & Continuous Task Pursuit

1. Objetivo

O PRD-036 introduz a capacidade de o Agentic Work trabalhar com objetivos persistentes, e não apenas com comandos, intenções ou execuções individuais.

Até aqui, a arquitetura evoluiu aproximadamente assim:

Intent
  ↓
Plan
  ↓
Execution
  ↓
Adaptive Runtime
  ↓
State Synchronization

Agora acrescentamos:

Goal
  ↓
Objectives
  ↓
Tasks
  ↓
Plans
  ↓
Executions
  ↓
Outcomes
  ↓
Re-evaluation
  ↓
Goal Progress
  ↓
Next Tasks

O objetivo é permitir que o sistema mantenha uma finalidade operacional durante horas, dias ou meses, sem transformar o LLM em um agente com autonomia irrestrita.

2. Problema

Uma instrução tradicional é pontual:

“Atualize este Work Permit.”

Um objetivo é persistente:

“Mantenha todos os Work Permits em conformidade.”

Outro exemplo:

“Garanta que nenhum funcionário trabalhando em atividades críticas esteja com treinamento vencido.”

Isso exige:

monitoramento;
detecção de desvios;
criação de tarefas;
planejamento;
execução;
acompanhamento;
reavaliação;
encerramento.

O sistema precisa responder continuamente:

O objetivo ainda está sendo atingido?

3. Princípio Fundamental

Um Goal não autoriza nenhuma ação por si só.

A cadeia continua obrigatória:

GOAL
 ↓
TASK
 ↓
INTENT
 ↓
PLAN
 ↓
POLICY
 ↓
CAPABILITY
 ↓
EXECUTION
 ↓
VERIFICATION

Portanto:

Goal define o que deve ser alcançado. Policy continua definindo o que pode ser feito.

4. Goal ≠ Workflow

Essa distinção é essencial.

Goal

Define um resultado desejado.

"Manter conformidade de todos os Work Permits."

Workflow

Define um processo estruturado.

SUBMITTED
→ APPROVAL
→ RELEASE
→ COMPLETED

Execution

Executa uma operação específica.

updateValidity(WP-1001)

Assim:

Goal
 ├── Task
 │    └── Workflow
 │         └── Execution
 └── Task
      └── Execution

5. Goal Lifecycle

Estados:

DRAFT
PENDING_APPROVAL
ACTIVE
PAUSED
AT_RISK
BLOCKED
ACHIEVED
FAILED
EXPIRED
CANCELLED
ARCHIVED

6. Goal State Machine

DRAFT
  ↓
PENDING_APPROVAL
  ↓
ACTIVE
  ├──→ AT_RISK
  │      ↓
  │   ACTIVE
  │
  ├──→ BLOCKED
  │      ↓
  │   ACTIVE
  │
  └──→ ACHIEVED

ACTIVE → PAUSED → ACTIVE

ACTIVE → FAILED
ACTIVE → EXPIRED
ACTIVE → CANCELLED

7. Goal Model

interface Goal {
  goalId: string;

  tenantId: string;

  parentGoalId?: string;

  name: string;

  description: string;

  owner: GoalOwner;

  scope: GoalScope;

  objectives: Objective[];

  constraints: GoalConstraint[];

  successCriteria: SuccessCriterion[];

  priority: number;

  status: GoalStatus;

  startAt: string;

  deadline?: string;

  autonomyLevel: AutonomyLevel;

  version: string;

  createdAt: string;

  updatedAt: string;
}

8. Goal Owner

Todo objetivo deverá possuir responsável.

Pode ser:

HUMAN
TEAM
AGENT
SYSTEM

Exemplo:

{
  "type": "TEAM",
  "id": "safety-compliance"
}

9. Goal Scope

O objetivo deverá definir onde pode atuar.

Exemplo:

interface GoalScope {
  entityTypes: string[];

  entityIds?: string[];

  organizationalUnits?: string[];

  locations?: string[];

  departments?: string[];
}

Nunca assumir:

“Todos os registros do sistema.”

sem que isso esteja explicitamente autorizado.

10. Goal Hierarchy

Objetivos poderão possuir hierarquia.

Exemplo:

GOAL
Manter conformidade SST
│
├── OBJECTIVE
│   Work Permits conformes
│
├── OBJECTIVE
│   Treinamentos válidos
│
└── OBJECTIVE
    Exames/documentação válidos

11. Parent/Child Goals

Um objetivo filho não poderá ultrapassar o escopo do pai.

ChildScope ⊆ ParentScope

12. Objective

Um Goal pode possuir múltiplos objetivos mensuráveis.

interface Objective {
  objectiveId: string;

  goalId: string;

  description: string;

  metric: MetricDefinition;

  target: TargetDefinition;

  currentValue?: number;

  status: ObjectiveStatus;
}

13. Metrics

Exemplo:

Metric:
percentage_of_valid_work_permits

Target:

>= 99%

14. Success Criteria

O objetivo precisa ter uma condição objetiva de sucesso.

Exemplo:

ALL:
training.valid == true

AND

workPermit.status != BLOCKED

AND

complianceRate >= 99%

15. Goal Completion

O Goal somente poderá ser marcado como:

ACHIEVED

quando os critérios definidos forem verificados.

O agente não poderá simplesmente declarar:

“Acredito que o objetivo foi alcançado.”

16. Goal Progress

O sistema deverá calcular:

progress

por exemplo:

Work Permits conformes:
9.850 / 10.000

Progress:
98.5%

17. Progress ≠ Success

Um objetivo pode estar:

98.5%

mas ainda não estar concluído.

Isso é importante para evitar conclusões prematuras.

18. Goal Health

Além de progresso:

HEALTHY
AT_RISK
BLOCKED
UNKNOWN

Exemplo:

Progress: 72%

Deadline: 2 days

Health: AT_RISK

19. Goal Risk

O Goal poderá possuir risco:

LOW
MEDIUM
HIGH
CRITICAL

Mas o risco não substituirá a Policy Engine.

20. Goal Constraints

Exemplos:

maxCost = R$ 10,000

deadline = 2026-10-30

maxConcurrentExecutions = 20

allowedCapabilities:
  - training.notify
  - workPermit.update

21. Immutable Constraints

Algumas restrições não poderão ser alteradas pelo agente:

tenant
authorization boundary
protected resources
security policy
maximum blast radius

22. Goal Autonomy

O objetivo deverá declarar o nível de autonomia permitido.

OBSERVE
RECOMMEND
PREPARE
EXECUTE_WITH_CONFIRMATION
AUTONOMOUS_LOW_RISK

23. Autonomy Boundary

Por exemplo:

Goal:
manter treinamentos válidos

poderá permitir:

detect expiration
create notification
create review task

mas não:

terminate employee

mesmo que o LLM considere isso útil.

24. Goal Monitoring

Goals ativos deverão ser monitorados por sinais.

Fontes:

Event Fabric
Knowledge Fabric
Business APIs
Scheduled scans
Workflow
External integrations
Operational metrics

25. Goal Signal

interface GoalSignal {
  signalId: string;

  goalId: string;

  type: string;

  source: string;

  observedAt: string;

  entityRefs: EntityRef[];

  value?: unknown;

  confidence?: number;
}

26. Signal → Task

Exemplo:

TrainingExpired
       ↓
Goal Monitor
       ↓
Objective affected
       ↓
Create Task

27. Task Model

interface GoalTask {
  taskId: string;

  goalId: string;

  objectiveId?: string;

  title: string;

  description: string;

  priority: number;

  status: TaskStatus;

  scope: GoalScope;

  dependencies: string[];

  deadline?: string;

  createdAt: string;

  updatedAt: string;
}

28. Task Lifecycle

CREATED
 ↓
READY
 ↓
PLANNING
 ↓
PLANNED
 ↓
EXECUTING
 ↓
VERIFYING
 ↓
COMPLETED

Com exceções:

BLOCKED
FAILED
CANCELLED
EXPIRED

29. Goal Decomposition

O sistema poderá decompor:

Goal:
Manter todos os Work Permits conformes

em:

Task 1:
identificar permits com treinamento vencendo

Task 2:
notificar responsáveis

Task 3:
atualizar documentação

Task 4:
reavaliar permits bloqueados

30. Deterministic Decomposition

Sempre que possível, a decomposição deverá usar templates e regras determinísticas.

Exemplo:

TrainingExpired
→ FindAffectedEmployees
→ FindAffectedWorkPermits
→ EvaluateRisk
→ CreateReviewTask

31. LLM Decomposition

O LLM poderá auxiliar quando:

o objetivo for textual;
existirem múltiplas interpretações;
a decomposição não estiver prevista;
for necessária síntese semântica.

Mas a saída deverá ser estruturada.

32. No Free-Form Autonomous Planning

O LLM não poderá produzir:

"Vou acessar o banco diretamente..."

ou:

"Vou chamar esta URL..."

Apenas:

Task
→ Capability
→ Policy

33. Goal Scheduler

Goals ativos precisarão de um mecanismo de avaliação.

Goal Scheduler
     ↓
Evaluate Signals
     ↓
Evaluate Progress
     ↓
Evaluate Deadlines
     ↓
Evaluate Risk
     ↓
Generate Tasks

34. Scheduling Modes

EVENT_DRIVEN
SCHEDULED
HYBRID
CONTINUOUS

35. Event-Driven Goals

Exemplo:

TrainingExpired

aciona imediatamente a avaliação do Goal.

36. Scheduled Goals

Exemplo:

Todos os dias às 02:00

executar:

ComplianceScan

37. Hybrid Goals

A combinação será a mais comum:

Events
+
Daily reconciliation
+
Deadline monitoring

38. Deadline Intelligence

O sistema deverá calcular:

deadline
remainingTime
estimatedCompletion
riskOfMissingDeadline

39. Goal At Risk

Exemplo:

Target:
100%

Current:
93%

Deadline:
12 hours

Estimated:
96%

Resultado:

AT_RISK

40. Proactive Intelligence Integration

O PRD-021 poderá gerar:

PROACTIVE_SIGNAL

que será associado ao Goal.

Assim:

Proactive Intelligence
        ↓
Goal
        ↓
Task

41. Goal Prioritization

Quando existirem centenas de Goals/Tasks:

priority =
business impact
+
risk
+
deadline
+
dependency
+
cost

42. Priority Não Pode Ignorar Policy

Uma tarefa crítica não poderá ultrapassar uma tarefa menos crítica se isso violar:

autorização;
segregação de funções;
limite de recursos;
segurança.

43. Competing Goals

Dois Goals podem entrar em conflito.

Exemplo:

Goal A:
maximizar produtividade

Goal B:
maximizar segurança

Se uma ação favorecer A e prejudicar B:

Goal Conflict

deverá ser criado.

44. Goal Conflict Resolution

A resolução deverá passar por:

Policy
+
Decision Intelligence
+
Business Rules
+
Human Review

quando necessário.

O Goal Manager não poderá decidir arbitrariamente.

45. Goal Dependencies

Goal A
  ↓
Goal B

Exemplo:

Treinamentos válidos
       ↓
Work Permits liberáveis

46. Dependency Failure

Se Goal A estiver bloqueado:

Goal B
→ AT_RISK

ou:

BLOCKED

conforme regras.

47. Continuous Replanning

O Goal não possuirá necessariamente um plano fixo.

A cada mudança relevante:

Goal
 ↓
Current State
 ↓
Gap Analysis
 ↓
Plan
 ↓
Execute
 ↓
New State
 ↓
Gap Analysis

48. Goal Loop

┌──────────────────────────────┐
│                              │
│       GOAL                   │
│        ↓                     │
│     OBSERVE                  │
│        ↓                     │
│     EVALUATE                 │
│        ↓                     │
│     IDENTIFY GAP             │
│        ↓                     │
│     CREATE TASK              │
│        ↓                     │
│     PLAN                     │
│        ↓                     │
│     POLICY                   │
│        ↓                     │
│     EXECUTE                  │
│        ↓                     │
│     VERIFY                   │
│        ↓                     │
│     MEASURE                  │
│        │                     │
│        └─────────────────────┘

49. Stop Condition

Um Goal deverá possuir condições claras para interromper sua perseguição.

ACHIEVED
FAILED
EXPIRED
CANCELLED

50. No Infinite Pursuit

O agente nunca deverá entrar em:

execute
→ fail
→ retry
→ execute
→ fail
→ retry

indefinidamente.

Existirão:

retry budget;
task budget;
cost budget;
time budget;
execution budget.

51. Goal Budget

interface GoalBudget {
  maxCost?: number;

  maxExecutions?: number;

  maxLLMCalls?: number;

  maxRuntimeMs?: number;

  maxTasks?: number;
}

52. Budget Consumption

Cada execução deverá consumir recursos do Goal:

Goal Budget
 ↓
Task
 ↓
Plan
 ↓
Execution

53. Resource Integration

O PRD-033 define recursos e capacidade.

O Goal Manager deverá consultar:

resource availability
capacity
quota
cost

antes de criar grandes volumes de tarefas.

54. Runtime Integration

O PRD-034 executará as tarefas e poderá informar:

execution completed
execution failed
resource degraded
execution paused

O Goal Manager atualizará o estado do objetivo.

55. State Fabric Integration

O PRD-035 será responsável por garantir que:

Goal
Task
Entity
Workflow
Execution

trabalhem com versões coerentes.

56. Event Fabric Integration

Eventos relevantes:

GoalCreated
GoalActivated
GoalAtRisk
GoalBlocked
GoalTaskCreated
GoalTaskCompleted
GoalProgressChanged
GoalAchieved
GoalFailed
GoalCancelled

57. Knowledge Integration

Goals poderão utilizar:

business rules
documentation
historical knowledge
entity relationships
compliance requirements

mas sempre respeitando:

authority
freshness
provenance

definidos nos PRDs 028/029.

58. Goal Evidence

Cada progresso deverá possuir evidência.

interface GoalEvidence {
  evidenceId: string;

  goalId: string;

  sourceType: string;

  sourceRef: string;

  observedAt: string;

  knowledgeVersion?: string;

  stateVersion?: string;

  confidence?: number;
}

59. Evidence-Based Completion

Nunca:

LLM says:
"Goal achieved."

Sempre:

Success Criteria
+
Current State
+
Evidence
+
Verification

60. Goal Explanation

O usuário poderá perguntar:

Por que este objetivo está em risco?

O sistema deverá responder:

Goal:
Manter Work Permits conformes

Status:
AT_RISK

Reason:
127 permits possuem treinamento expirando
em menos de 7 dias.

Affected:
127

Deadline:
5 dias

Evidence:
TrainingStatusUpdated events
LMS synchronization

Sem expor chain-of-thought.

61. Goal Dashboard

A UI deverá fornecer uma visão semântica:

Goal
 ├── Status
 ├── Progress
 ├── Risk
 ├── Objectives
 ├── Tasks
 ├── Dependencies
 ├── Evidence
 ├── Deadlines
 └── Activity

62. Goal Timeline

01/09 Goal activated
01/09 243 tasks created
02/09 198 completed
02/09 LMS unavailable
02/09 Goal at risk
03/09 LMS recovered
03/09 45 tasks resumed

63. Human Intervention

O humano poderá:

PAUSE
RESUME
CANCEL
PRIORITIZE
APPROVE
REJECT
REASSIGN

64. Human Override

Um humano não deverá poder violar uma Policy global apenas porque possui acesso ao Goal UI.

As mesmas regras de autorização continuam válidas.

65. Goal Approval

Goals de alto impacto poderão exigir aprovação antes de:

ACTIVE

Exemplo:

Goal:
Automatically update 50,000 Work Permits

deverá exigir:

HUMAN REVIEW

66. Blast Radius

Antes da ativação:

estimatedAffectedEntities
estimatedTasks
estimatedExecutions
estimatedCost
estimatedRisk

deverão ser calculados quando possível.

67. Goal Simulation

Antes de ativar:

SIMULATE

poderá responder:

Affected entities: 2,430
Tasks: 782
Estimated cost: X
High-risk actions: 14
Human approvals: 3

68. Goal Dry Run

No modo:

DRY_RUN

nenhuma mutation real poderá ocorrer.

69. Goal Versioning

Goals deverão possuir versões:

Goal v1
Goal v2

Uma alteração significativa deverá gerar nova versão.

70. Active Goal Changes

Se um Goal ativo mudar:

scope
constraints
success criteria
autonomy

o sistema deverá avaliar se precisa:

pause
reapprove
replan

71. Execution Pinning

Tasks e executions deverão registrar:

goalVersion
planVersion
policyVersion
capabilityVersion
knowledgeVersion

para reprodução posterior.

72. Multi-Agent Goals

Um Goal poderá ser executado por vários agentes.

Exemplo:

Supervisor Agent
       │
 ┌─────┼─────┐
 ▼     ▼     ▼
Training Risk Compliance
Agent    Agent    Agent

73. Agent Delegation

A delegação deverá utilizar o PRD-027.

Cada agente receberá apenas:

delegated scope
+
allowed capabilities
+
allowed resources
+
time limit

74. Agent Communication

A comunicação utilizará o PRD-031.

Exemplo:

Supervisor
   ↓ TASK
Training Agent
   ↓ RESULT
Supervisor

75. Goal Memory

O Goal deverá manter:

previous tasks
previous outcomes
failed approaches
current blockers
evidence

Mas isso será operational memory, não conhecimento permanente.

76. Learning

O PRD-012 poderá identificar:

Task frequently fails
Task usually succeeds with capability B
Task A is unnecessary

Esses padrões poderão gerar sugestões.

Não poderão alterar automaticamente:

policies;
capabilities;
security;
autonomy boundaries.

77. Goal Optimization

O sistema poderá otimizar:

cost
latency
resource utilization
task ordering
parallelism

usando PRD-032.

Mas:

Nunca poderá otimizar a ponto de violar o objetivo, suas restrições ou políticas de segurança.

78. Goal Cancellation

Quando cancelado:

Goal
 ↓
stop generating new tasks
 ↓
evaluate active tasks
 ↓
cancel/pause according to policy
 ↓
close goal

79. Goal Pause

Ao pausar:

no new tasks

e tarefas em andamento seguirão a política definida:

COMPLETE
PAUSE
CANCEL

80. Goal Resume

Ao retornar:

PAUSED
 ↓
validate current state
 ↓
recalculate progress
 ↓
replan
 ↓
ACTIVE

Não simplesmente continuar usando o plano antigo.

81. Failure Handling

Se uma Task falhar:

Task Failure
 ↓
Exception Management
 ↓
Recovery
 ↓
Retry/Compensate/Replan
 ↓
Goal Progress

82. Systemic Failure

Se houver:

LMS outage

e milhares de tasks dependem do LMS:

Goal
 ↓
Dependency unavailable
 ↓
BLOCKED / AT_RISK

em vez de milhares de retries.

83. Circuit Breaker

O Goal Scheduler deverá respeitar circuit breakers do PRD-024/034.

84. Goal Storm Protection

Um único evento não poderá gerar:

1 event
→ 1,000,000 tasks

sem controle.

Existirão:

aggregation;
deduplication;
batching;
rate limiting;
maximum task generation;
human review.

85. Duplicate Task Prevention

Uma chave idempotente deverá evitar:

TrainingExpired
→ Task A

TrainingExpired retry
→ Task A novamente

86. Task Idempotency

taskKey =
goalId +
objectiveId +
entityId +
condition +
conditionVersion

87. Tenant Isolation

Goals deverão ser totalmente isolados:

tenant
 ↓
goals
 ↓
tasks
 ↓
evidence
 ↓
executions
 ↓
metrics

Nenhuma informação de outro tenant poderá influenciar:

progresso;
priorização;
contexto;
memória;
decisões.

88. Goal Security

O sistema deverá validar:

user
agent
delegation
tenant
goal scope
capability
resource
policy

antes de cada operação.

89. Audit

Registrar:

GOAL_CREATED
GOAL_APPROVED
GOAL_ACTIVATED
GOAL_PAUSED
GOAL_RESUMED
GOAL_CANCELLED
TASK_CREATED
TASK_ASSIGNED
TASK_STARTED
TASK_COMPLETED
GOAL_PROGRESS_CHANGED
GOAL_AT_RISK
GOAL_BLOCKED
GOAL_ACHIEVED
GOAL_FAILED

90. Observability

Métricas:

active_goals
goals_achieved
goals_failed
goals_at_risk
tasks_created
tasks_completed
tasks_failed
goal_cycle_time
goal_completion_rate
goal_cost
goal_execution_count
goal_replan_count
goal_blocked_duration

91. Goal Quality Metrics

Também medir:

Goal Success Rate
Task Success Rate
False Alert Rate
Unnecessary Task Rate
Replanning Rate
Human Intervention Rate
Budget Overrun Rate

92. Goal Health Score

Poderá existir:

Goal Health =
progress
+
deadline risk
+
dependency health
+
resource availability
+
failure rate

O cálculo deverá ser transparente e versionado.

93. No Hidden Autonomous Objective

Um agente nunca poderá criar um Goal persistente sozinho.

Exemplo proibido:

LLM:
"Seria melhor manter esse objetivo permanentemente."

Um Goal precisa ser:

explicitly created
or
created by an authorized system policy

94. Goal Creation Sources

USER
ADMIN
WORKFLOW
POLICY
PROACTIVE_ENGINE
SYSTEM
INTEGRATION

Cada origem deverá possuir autorização própria.

95. Goal Expiration

Goals temporários deverão possuir:

expiresAt

Após o vencimento:

EXPIRED

sem novas execuções.

96. Recurring Goals

Um Goal poderá possuir recorrência:

daily
weekly
monthly

Mas cada ciclo deverá possuir uma instância identificável.

Goal Definition
      ↓
Goal Run #1042
Goal Run #1043
Goal Run #1044

97. Goal Definition vs Goal Instance

Essa separação será importante.

GoalDefinition

define:

“Verificar conformidade diariamente.”

Enquanto:

GoalInstance

representa:

“Execução de 1º de setembro.”

98. Goal Run

interface GoalRun {
  runId: string;

  goalDefinitionId: string;

  tenantId: string;

  scheduledAt: string;

  startedAt?: string;

  completedAt?: string;

  status: GoalRunStatus;

  metrics: Record<string, number>;
}

99. Goal Store

A infraestrutura deverá abstrair persistência:

interface GoalStore {
  create(goal: Goal): Promise<void>;

  get(goalId: string): Promise<Goal | null>;

  update(goal: Goal): Promise<void>;

  listActive(tenantId: string): Promise<Goal[]>;

  createTask(task: GoalTask): Promise<void>;

  getTask(taskId: string): Promise<GoalTask | null>;
}

100. Cloudflare Architecture

A implementação deverá permanecer compatível com a arquitetura serverless existente.

Workers
  ↓
Goal API
  ↓
Goal Engine
  ↓
State/Workflow/Event abstractions
  ↓
D1 / KV / Durable Objects / Workflows

A escolha concreta do storage deverá respeitar:

volume;
consistência;
duração;
concorrência;
custo.

101. Goal Engine

O núcleo deverá possuir:

Goal Manager
Goal Evaluator
Goal Scheduler
Goal Decomposer
Task Manager
Progress Calculator
Deadline Monitor
Goal Policy Adapter
Goal Evidence Resolver
Goal State Coordinator

102. Goal Evaluator

Responsável por:

current state
+
success criteria
+
constraints
+
deadline
+
signals

produzindo:

GoalEvaluation

103. Goal Evaluation

interface GoalEvaluation {
  goalId: string;

  evaluatedAt: string;

  status: GoalStatus;

  progress: number;

  health: "HEALTHY" | "AT_RISK" | "BLOCKED" | "UNKNOWN";

  unmetCriteria: string[];

  risks: string[];

  evidence: GoalEvidence[];
}

104. Goal Decision

O Goal Engine não deverá executar diretamente.

Ele produz:

Goal Evaluation
        ↓
Task Recommendation
        ↓
Planner

105. Architectural Boundary

Portanto:

Goal Engine
   ↓
"é necessário fazer X"

Planner
   ↓
"esta é a melhor forma"

Policy
   ↓
"pode?"

Capability
   ↓
"como executar?"

Runtime
   ↓
"executar"

State Fabric
   ↓
"qual é o estado atual?"

Verification
   ↓
"foi realmente alcançado?"

Essa separação é fundamental.

106. First Vertical Slice — Work Permit Compliance

Goal:

Manter todos os Work Permits elegíveis em conformidade com os requisitos de treinamento.

107. Objective

100% dos Work Permits ativos
possuem treinamento válido

108. Signals

TrainingExpired
TrainingExpiringSoon
EmployeeChanged
WorkPermitCreated
WorkPermitUpdated
LMSStatusUpdated

109. Task Generation

Exemplo:

TrainingExpired
Employee EMP-100
     ↓
Find Work Permits
     ↓
WP-1001
WP-1004
WP-1022
     ↓
Create Tasks

110. Task Execution

Cada Task seguirá:

Task
 ↓
Intent
 ↓
Plan
 ↓
Policy
 ↓
Capability
 ↓
Execution
 ↓
Verification

111. State Change During Task

Se o treinamento for atualizado enquanto a Task estiver sendo executada:

State Fabric
 ↓
new version
 ↓
task context stale
 ↓
revalidate

112. Goal Re-evaluation

Depois da execução:

Affected permits:
3

Still non-compliant:
1

Goal:
AT_RISK

O sistema poderá criar nova Task somente se necessário.

113. Completion

Quando:

all active permits compliant

evidenciado pelo Business API + LMS + State Fabric:

GOAL → ACHIEVED

114. Acceptance Criteria

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

Goals têm definição/instância tenant-bound, lifecycle explícito, owner, escopo contido, autonomia, orçamento, deadline, health e risco. O domínio valida transições, dependências e deduplicação; o runtime agendado avalia prazo/progresso e gera somente sinais ou tarefas governadas, sem autoridade implícita. Pause, resume, cancelamento e expiração preservam versão e trilha de eventos.

Em 2026-09-05, o gate de Goal Management passou com 40 testes em 5 arquivos. O canário remoto comprovou em tenant sintético isolado meta Work Permit com progresso inicial 50/AT_RISK, task deduplicada, delegação para training-agent@2.0.0, workflow e comunicação persistidos, uma replanificação, execução única e fechamento 100/ACHIEVED; o audit trail registrou GOAL_CREATED até GOAL_ACHIEVED, authorizesExecution:false e o cleanup confirmou remainingRows:0. Os contratos preservam evidência fresca por fonte, versão otimista da meta e pins de policy/capability/knowledge/state/plan em cada task. Simulação/dry-run ampla, competição explícita entre goals, cancelamento e expiração permanecem abertos para prova dedicada.

Em 2026-09-06, a regressão atual do runtime e das rotas de Goal Management passou com 11 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; simulação/dry-run ampla, competição explícita, cancelamento e expiração seguem como expansão.

115. Resultado Arquitetural

O Agentic Work passa a ter uma camada superior à execução:

                    GOALS
                      │
                      ▼
                 OBJECTIVES
                      │
                      ▼
                   SIGNALS
                      │
                      ▼
                 GAP ANALYSIS
                      │
                      ▼
                    TASKS
                      │
                      ▼
                  PLANNING
                      │
                      ▼
                   POLICY
                      │
                      ▼
                CAPABILITIES
                      │
                      ▼
                  EXECUTION
                      │
                      ▼
                 VERIFICATION
                      │
                      ▼
                STATE FABRIC
                      │
                      ▼
               GOAL RE-EVALUATION
                      │
                 ┌────┴────┐
                 │         │
              ACHIEVED   NEW TASK

O sistema agora não precisa esperar que alguém diga novamente:

“Faça isso.”

Ele pode acompanhar um objetivo explicitamente autorizado, observar o estado do sistema, identificar o que ainda falta e criar as próximas tarefas necessárias — sempre passando novamente por Policy, Capability, Execution e Verification.

PRD-037 — Agentic Temporal Intelligence & Scheduling Fabric

O próximo problema arquitetural é o tempo.

Já temos:

Workflow com timers;
Proactive Intelligence;
Goals persistentes;
Deadlines;
Tasks;
Event Fabric.

Mas ainda falta uma camada formal para raciocinar sobre:

quando algo deve acontecer
quando pode acontecer
quando não pode acontecer
quanto tempo ainda resta
qual é a janela válida
qual calendário deve ser usado
qual timezone se aplica
qual SLA está sendo violado

O PRD-037 deverá criar o Temporal Intelligence & Scheduling Fabric.

A arquitetura conceitual será:

GOAL
  ↓
TEMPORAL CONSTRAINTS
  ↓
CALENDAR / TIMEZONE / SLA
  ↓
SCHEDULE
  ↓
TRIGGER
  ↓
WORKFLOW / TASK
  ↓
EXECUTION
  ↓
DEADLINE MONITOR
  ↓
TEMPORAL RE-EVALUATION

E deverá tratar, entre outros:

Time Semantics;
Instant vs Local Time;
Timezone;
UTC;
Business Calendar;
Working Hours;
Holidays;
SLA;
Deadline;
Due Date;
Earliest Start;
Latest Start;
Time Window;
Temporal Constraint;
Recurrence;
Schedule;
Timer;
Delay;
Countdown;
Expiration;
Grace Period;
Escalation;
Temporal Dependency;
Critical Path;
Calendar Exceptions;
Tenant Calendars;
User Calendars;
Resource Calendars;
Timezone-aware scheduling;
DST;
Brazilian holidays/calendars configuráveis;
Cross-timezone operations;
Temporal conflicts;
Missed deadlines;
Deadline prediction;
Temporal simulation;
Schedule optimization;
Event-triggered scheduling;
Persistent timers;
serverless-safe timers;
recovery after downtime;
idempotent triggers;
audit temporal;
temporal versioning;
historical reconstruction;
integration with Goals, Workflow, Event Fabric, Planning, Runtime e State Fabric.

O princípio central será:

Tempo não deve ser tratado como uma simples string de data/hora; deve ser um elemento semântico, versionado, contextual e verificável da operação agentic.

1. Objetivo​

2. Problema

3. Princípio Fundamental

4. Goal ≠ Workflow

Goal​

Workflow​

Execution​

5. Goal Lifecycle

6. Goal State Machine

7. Goal Model

8. Goal Owner

9. Goal Scope

10. Goal Hierarchy

11. Parent/Child Goals

12. Objective

13. Metrics

14. Success Criteria

15. Goal Completion

16. Goal Progress

17. Progress ≠ Success

18. Goal Health

19. Goal Risk

20. Goal Constraints

21. Immutable Constraints

22. Goal Autonomy

23. Autonomy Boundary

24. Goal Monitoring

25. Goal Signal

26. Signal → Task

27. Task Model

28. Task Lifecycle

29. Goal Decomposition

30. Deterministic Decomposition

31. LLM Decomposition

32. No Free-Form Autonomous Planning

33. Goal Scheduler

34. Scheduling Modes

35. Event-Driven Goals

36. Scheduled Goals

37. Hybrid Goals

38. Deadline Intelligence

39. Goal At Risk

40. Proactive Intelligence Integration

41. Goal Prioritization

42. Priority Não Pode Ignorar Policy

43. Competing Goals

44. Goal Conflict Resolution

45. Goal Dependencies

46. Dependency Failure

47. Continuous Replanning

48. Goal Loop

49. Stop Condition

50. No Infinite Pursuit

51. Goal Budget

52. Budget Consumption

53. Resource Integration

54. Runtime Integration

55. State Fabric Integration

56. Event Fabric Integration

57. Knowledge Integration

58. Goal Evidence

59. Evidence-Based Completion

60. Goal Explanation

61. Goal Dashboard

62. Goal Timeline

63. Human Intervention

64. Human Override

65. Goal Approval

66. Blast Radius

67. Goal Simulation

68. Goal Dry Run

69. Goal Versioning

70. Active Goal Changes

71. Execution Pinning

72. Multi-Agent Goals

73. Agent Delegation

74. Agent Communication

75. Goal Memory

76. Learning

77. Goal Optimization

1. Objetivo

Goal

Workflow

Execution

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