PRD-035 — Agentic State & Context Synchronization Fabric

1. Objetivo

O PRD-035 define a infraestrutura responsável por manter estado e contexto sincronizados entre todos os componentes do Agentic Work.

A partir dos PRDs anteriores, o sistema já possui:

Conversation Runtime;
Semantic UI Context;
Knowledge Fabric;
Workflow Engine;
Event Fabric;
Execution Runtime;
Capability Registry;
Policy Engine;
Decision Intelligence;
Resource/Capacity Management;
Agent Communication Fabric.

Agora surge um problema central:

Qual estado representa a realidade atual e como garantir que todos os componentes estejam trabalhando sobre uma versão válida desse estado?

O objetivo é impedir que o agente execute uma operação baseada em informação que já deixou de ser verdadeira.

2. Problema

Considere:

Usuário seleciona:
WP-1001

UI:
status = SUBMITTED

Business API:
status = APPROVED

Knowledge:
status = SUBMITTED

Workflow:
WAITING_APPROVAL

Agent:
plan = APPROVE

Existem quatro visões diferentes da mesma entidade.

O sistema precisa detectar essa situação antes que uma ação seja executada.

3. Princípio Fundamental

Deve existir uma distinção explícita entre:

STATE

CONTEXT

State

Representa uma condição do sistema ou entidade.

Exemplo:

WorkPermit WP-1001 = APPROVED

Context

Representa aquilo que um componente sabe ou está utilizando naquele momento.

Exemplo:

Agent Context:
WP-1001 selected
status observed 10 seconds ago

Portanto:

Contexto pode ficar obsoleto sem que o estado tenha mudado incorretamente.

4. State Ownership

Cada estado deverá possuir um proprietário canônico.

Exemplo:

Estado	Source of Truth
Work Permit	Business API/DB
Employee	HR/SST
Training	LMS ou SST conforme domínio
Workflow	Workflow Engine
Execution	Execution Runtime
UI selection	Browser/UI
Knowledge document	Knowledge Fabric
Policy	Policy Registry
Capability	Capability Registry

O Agent nunca será proprietário do estado empresarial.

5. Canonical State

O conceito de Canonical State deverá representar o estado oficial de uma entidade.

interface CanonicalEntityState {
  tenantId: string;

  entityType: string;

  entityId: string;

  state: Record<string, unknown>;

  version: string;

  source: string;

  observedAt: string;

  updatedAt: string;
}

6. Entity Version

Toda entidade relevante para operações agentic deverá possuir uma versão.

Exemplo:

WP-1001
version = 42

Após alteração:

WP-1001
version = 43

7. Optimistic Concurrency

Uma operação poderá informar:

expectedVersion = 42

Se o servidor encontrar:

currentVersion = 43

a operação deverá falhar com:

STATE_CONFLICT

em vez de sobrescrever silenciosamente a alteração.

8. Por que isso é crítico

Sem versionamento:

Agent A lê → version 42
Usuário altera → version 43
Agent A grava

O agente poderia apagar uma alteração legítima feita pelo usuário.

Com versionamento:

Agent A → expected 42
Server → current 43
        ↓
      DENY

9. State Fabric

O State Fabric funcionará como camada de coordenação:

Business API
     │
     ▼
Canonical State
     │
     ├─────────────┐
     ▼             ▼
Workflow        Event Fabric
     │             │
     └──────┬──────┘
            ▼
       State Fabric
            │
      ┌─────┼─────┐
      ▼     ▼     ▼
     UI    Agent Knowledge

Importante:

isso não substitui o banco transacional.

O sistema empresarial continua sendo a fonte de verdade.

10. State Fabric ≠ Database

O State Fabric será uma camada de:

sincronização;
versionamento;
projeção;
distribuição;
detecção de conflitos;
snapshots;
contexto.

Não deverá se transformar em um segundo banco transacional concorrente com o sistema principal.

11. State Snapshot

Cada execução poderá capturar um snapshot:

interface StateSnapshot {
  snapshotId: string;

  executionId: string;

  tenantId: string;

  entities: StateSnapshotEntity[];

  createdAt: string;

  sourceVersions: Record<string, string>;
}

12. Snapshot Semântico

O snapshot não deverá necessariamente conter toda a entidade.

Poderá conter apenas:

WorkPermit:
  id
  status
  validity
  employeeId
  revision

Isso reduz:

armazenamento;
tráfego;
tokens;
exposição de dados.

13. Context Snapshot

O Agent Context deverá registrar:

interface AgentContextSnapshot {
  contextId: string;

  conversationId: string;

  executionId?: string;

  uiContextVersion?: string;

  entityVersions: Record<string, string>;

  knowledgeVersion: string;

  capabilityVersion: string;

  policyVersion: string;

  createdAt: string;
}

14. Context Validity

Um contexto será considerado:

VALID
STALE
INVALID
CONFLICTED
UNKNOWN

15. Context Staleness

Exemplo:

Agent lê:
WP-1001 version 42

Após 30 segundos:
WP-1001 version 43

O contexto do Agent torna-se:

STALE

16. Context Invalidation

Eventos como:

WorkPermitUpdated
TrainingStatusUpdated
WorkflowTransitioned
PolicyChanged
CapabilityDeprecated

poderão invalidar contextos existentes.

17. Context Delta

Em vez de reenviar todo o contexto:

FULL CONTEXT

deverá ser possível enviar:

CONTEXT DELTA

Exemplo:

{
  "entity": "workPermit:WP-1001",
  "changes": {
    "status": {
      "from": "SUBMITTED",
      "to": "APPROVED"
    }
  },
  "version": "43"
}

18. Context Version

Cada contexto terá:

contextVersion

Exemplo:

v1
v2
v3

Qualquer mudança semântica relevante incrementará a versão.

19. UI Synchronization

A UI já possui Semantic Context definido no PRD-011.

Agora ele deverá participar da sincronização.

React UI
   │
   ▼
Semantic Context
   │
   ▼
Context Bridge
   │
   ▼
State Fabric
   │
   ▼
Agent Runtime

20. UI State ≠ Business State

A UI pode informar:

selectedEntity = WP-1001

mas não pode declarar:

status = APPROVED

como verdade empresarial.

Essa informação deverá ser validada contra a fonte apropriada.

21. UI Optimistic State

A interface poderá possuir alterações ainda não persistidas:

form.dirty = true

Nesse caso:

Agent
 ↓
"Atualize a validade"

deverá saber que existem alterações pendentes.

22. Unsaved Changes Protection

Se houver:

dirty = true

e o agente tentar navegar ou executar uma operação incompatível, poderá solicitar:

Existem alterações não salvas neste formulário. Deseja salvá-las antes de continuar?

23. Form State Version

Forms deverão possuir:

interface SemanticFormState {
  formId: string;

  entityType: string;

  entityId?: string;

  version: string;

  dirty: boolean;

  valid: boolean;

  fields: Record<string, unknown>;

  serverVersion?: string;
}

24. Business State Synchronization

Depois de uma mutation:

Capability
   ↓
Business API
   ↓
Mutation
   ↓
Event
   ↓
State Fabric
   ↓
UI/Workflow/Knowledge

25. Event-Driven Synchronization

O Event Fabric do PRD-020 será o mecanismo primário de propagação.

Exemplo:

WorkPermitApproved

gera atualização em:

Workflow;
UI;
Knowledge;
Proactive Intelligence;
Conversation;
Agent contexts.

26. Read-After-Write

Após uma alteração importante:

WRITE
 ↓
EVENT
 ↓
READ/VERIFY

deverá confirmar o estado real.

27. Eventual Consistency

Nem todas as projeções precisarão ser imediatamente consistentes.

Por exemplo:

Business DB
   ↓
100ms
   ↓
Knowledge projection

é aceitável se a operação não depender da projeção imediatamente.

28. Strong Consistency Boundary

Porém, antes de operações críticas:

APPROVE
RELEASE
DELETE
CANCEL

o sistema deverá consultar o estado canônico.

29. Consistency Levels

EVENTUAL
SESSION
READ_AFTER_WRITE
STRONG

Cada capability deverá declarar o nível necessário.

30. Capability State Requirements

interface StateConsistencyRequirement {
  level:
    | "EVENTUAL"
    | "SESSION"
    | "READ_AFTER_WRITE"
    | "STRONG";

  maxStalenessMs?: number;

  requiredVersions?: string[];
}

31. Example

Uma busca:

SEARCH_WORK_PERMITS

poderá aceitar:

EVENTUAL

Já:

RELEASE_WORK_PERMIT

poderá exigir:

STRONG

32. State Conflict

Conflito ocorre quando duas fontes afirmam estados incompatíveis.

Exemplo:

LMS:
training = VALID

SST:
training = EXPIRED

O State Fabric não deverá simplesmente escolher arbitrariamente.

Deverá produzir:

STATE_CONFLICT

e encaminhar ao PRD-029/030.

33. Conflict Record

interface StateConflict {
  conflictId: string;

  tenantId: string;

  entityType: string;

  entityId: string;

  sources: ConflictSource[];

  detectedAt: string;

  status:
    | "OPEN"
    | "RESOLVED"
    | "ESCALATED";
}

34. Source Authority

A resolução deverá utilizar:

source authority
+
freshness
+
domain rule
+
verification

conforme PRDs 029 e 030.

35. UNKNOWN State

É obrigatório suportar:

UNKNOWN

Exemplo:

LMS unavailable

O sistema não deverá concluir:

training = expired

apenas porque não conseguiu consultar o LMS.

36. Unknown ≠ False

Essa distinção é crítica:

VALID
INVALID
UNKNOWN

e não apenas:

true / false

37. Temporal State

O State Fabric deverá suportar:

validFrom
validUntil
observedAt
updatedAt

permitindo perguntas como:

Qual era o estado do Work Permit no momento em que a decisão foi tomada?

38. Historical State

Exemplo:

00 → SUBMITTED
05 → APPROVED
08 → RELEASED

Uma auditoria às 10:06 deverá reconstruir:

APPROVED

39. State Timeline

Cada entidade importante poderá possuir timeline:

WP-1001

55 CREATED
00 SUBMITTED
05 APPROVED
08 RELEASED

40. Workflow Synchronization

Workflow possui seu próprio estado:

WAITING_APPROVAL

Business Entity:

SUBMITTED

Esses estados podem ser temporariamente diferentes.

O sistema deverá declarar explicitamente qual é:

business state;
workflow state.

41. Workflow Transition

Quando ocorrer:

APPROVAL_COMPLETED

deverá existir uma transição coordenada:

Workflow
   ↓
Business Capability
   ↓
Business State
   ↓
Event
   ↓
Projections

42. Execution Synchronization

Execution Runtime deverá possuir:

executionState

sem confundi-lo com:

businessState

Exemplo:

Execution = COMPLETED
Business = RELEASED

43. Completion Verification

Uma execução só será:

COMPLETED

quando sua condição de negócio estiver verificada.

44. Agent Synchronization

Agentes que trabalham sobre a mesma entidade deverão receber mudanças relevantes.

Exemplo:

Risk Agent
Training Agent
Compliance Agent

todos trabalham sobre:

WP-1001

Se o treinamento mudar, os agentes afetados deverão receber:

STATE_CHANGED

45. Agent Context Invalidation

TrainingStatusUpdated
       ↓
affected contexts
       ↓
INVALIDATE

46. No Automatic Re-execution

A invalidação de contexto não significa:

automatically execute again

Pode significar:

re-evaluate

e a Policy determinará o próximo passo.

47. State Subscriptions

Componentes poderão assinar mudanças:

interface StateSubscription {
  subscriberId: string;

  tenantId: string;

  entityType?: string;

  entityId?: string;

  eventTypes: string[];

  deliveryMode: "PUSH" | "PULL";
}

48. Subscription Filtering

Não enviar:

all tenant events

para todos os agentes.

Filtrar por:

tenant
entity
domain
workflow
capability
agent

49. Tenant Isolation

Todas as chaves de estado deverão conter escopo de tenant.

Exemplo:

tenant:{tenantId}:entity:{entityType}:{entityId}

Nunca:

entity:{entityId}

isoladamente.

50. Cache Isolation

Caches deverão incluir:

tenantId
user scope
permission scope
version

quando necessário.

51. Permission Context

Uma mudança de permissão deverá poder invalidar contextos.

Exemplo:

User had permission
 ↓
permission revoked
 ↓
agent context invalidated

52. Policy Version Synchronization

Uma execução poderá começar com:

policyVersion = 17

Se a Policy mudar para:

o sistema deverá determinar se a execução pode continuar.

53. Policy Change During Execution

Para operações críticas:

re-evaluate

poderá ser obrigatório.

Para operações já autorizadas e irreversíveis:

policy transition rules

deverão determinar o comportamento.

54. Knowledge Synchronization

O Knowledge Fabric não deverá ser tratado como estado transacional.

Ele deverá receber:

events
+
snapshots
+
projections

e manter:

knowledgeVersion

55. Knowledge Drift

Se:

Business State = 43
Knowledge Projection = 42

o sistema poderá marcar:

KNOWLEDGE_STALE

56. Retrieval Guard

Durante decisão crítica:

Knowledge
 ↓
stale
 ↓
refresh canonical state

antes de concluir.

57. State Projection

O State Fabric poderá manter projeções especializadas:

Agent Projection
UI Projection
Workflow Projection
Knowledge Projection
Analytics Projection

Todas derivadas de fontes oficiais.

58. Projection Metadata

interface ProjectionMetadata {
  projectionId: string;

  sourceVersion: string;

  projectionVersion: string;

  generatedAt: string;

  lagMs: number;

  status:
    | "CURRENT"
    | "LAGGING"
    | "FAILED";
}

59. Projection Lag

Monitorar:

source version = 100
projection version = 98

Lag:

2 versions

60. Projection Recovery

Se uma projeção falhar:

rebuild from snapshot
+
replay events

61. State Replay

O sistema deverá permitir:

snapshot
+
events

para reconstruir estado histórico.

62. Replay Modes

DRY_RUN
SIMULATION
AUDIT
RECOVERY
PRODUCTION

63. Production Replay Protection

Replay nunca deverá executar automaticamente mutations.

Eventos antigos poderão reconstruir estado, mas não disparar novamente uma operação perigosa sem autorização explícita.

64. State Lock

Algumas operações poderão exigir lock lógico:

WorkPermit WP-1001
LOCKED

durante uma operação crítica.

65. Prefer Versioning Over Long Locks

Locks prolongados deverão ser evitados.

Preferir:

version
+
compare-and-set

quando possível.

66. Distributed Lock

Quando necessário, deverá existir abstração:

interface StateLock {
  acquire(
    resource: string,
    owner: string,
    ttlMs: number
  ): Promise<boolean>;

  release(
    resource: string,
    owner: string
  ): Promise<void>;
}

67. Lock Safety

Nunca depender exclusivamente de lock para autorização.

Mesmo com lock:

Policy
Authorization
Validation
Verification

continuam obrigatórios.

68. State Machine

Entidades com lifecycle deverão possuir estados válidos.

Exemplo:

DRAFT
 ↓
SUBMITTED
 ↓
APPROVED
 ↓
RELEASED
 ↓
COMPLETED

69. Invalid Transition

Não permitir:

DRAFT → RELEASED

se o domínio não autorizar.

Isso pertence à Business Rule/Capability, não ao State Fabric.

70. State Fabric Responsibility

O State Fabric deverá detectar:

state changed
state stale
state conflict
state missing
state projection lag
state version mismatch

Mas não deverá inventar regras de negócio.

71. State Synchronization API

Uma API interna poderá expor:

interface StateService {
  getState(
    tenantId: string,
    entityType: string,
    entityId: string
  ): Promise<CanonicalEntityState>;

  getVersion(
    tenantId: string,
    entityType: string,
    entityId: string
  ): Promise<string>;

  validateVersion(
    entityRef: EntityRef,
    expectedVersion: string
  ): Promise<boolean>;

  getSnapshot(
    executionId: string
  ): Promise<StateSnapshot>;
}

72. Context Synchronization API

interface ContextService {
  getContext(contextId: string): Promise<AgentContextSnapshot>;

  updateContext(
    contextId: string,
    delta: ContextDelta
  ): Promise<void>;

  invalidate(
    contextId: string,
    reason: string
  ): Promise<void>;

  validate(
    contextId: string
  ): Promise<ContextValidationResult>;
}

73. Context Delta

interface ContextDelta {
  contextVersion: string;

  changes: Array<{
    path: string;
    value: unknown;
  }>;

  sourceEventId: string;
}

74. State Synchronization Flow

EVENT
 ↓
State Resolver
 ↓
Identify affected entities
 ↓
Update projections
 ↓
Invalidate stale contexts
 ↓
Notify subscribers
 ↓
Revalidate active operations

75. Active Execution Revalidation

Nem toda mudança exige interrupção.

Classificar:

NO_IMPACT
LOW_IMPACT
MATERIAL
CRITICAL

76. Example

Mudança:

WorkPermit.description

pode ser:

LOW_IMPACT

Mudança:

WorkPermit.status = CANCELLED

pode ser:

CRITICAL

77. Execution Response

Impacto	Ação
NO_IMPACT	continuar
LOW	atualizar contexto
MATERIAL	reavaliar
CRITICAL	pausar/stop/replan

78. Context Conflict Resolution

Quando dois contextos divergirem:

Agent A → version 42
Agent B → version 43

a versão canônica deverá prevalecer.

79. User Intent Preservation

Sincronização não deverá perder a intenção original.

Exemplo:

“Atualize a validade desse documento.”

Se o documento mudou de versão, o sistema deverá:

preservar intent
+
resolver nova versão
+
revalidar

em vez de simplesmente abandonar a operação.

80. Reference Re-resolution

Após stale context:

"esse documento"

deverá ser novamente resolvido.

A referência não deverá ser convertida silenciosamente em outro documento.

81. Security

O State Fabric deverá tratar contexto como dado potencialmente sensível.

Não deverá propagar:

dados desnecessários;
tokens;
credentials;
informações de outros usuários;
dados de outro tenant.

82. Data Minimization

Cada consumidor receberá somente:

minimum required state

83. State Classification

Estados poderão possuir classificação:

PUBLIC
INTERNAL
CONFIDENTIAL
SENSITIVE
RESTRICTED

84. Agent Access

Um agente somente receberá estados autorizados pela combinação:

User
+
Agent
+
Delegation
+
Tenant
+
Capability
+
Policy

85. Audit

Registrar:

state read
state snapshot
state conflict
state invalidation
state transition
version conflict
context refresh
context invalidation
projection rebuild

86. Observability

Métricas essenciais:

state_conflicts_total
stale_context_total
context_invalidations_total
projection_lag_ms
version_conflicts_total
snapshot_creation_latency
state_read_latency
context_sync_latency

87. Performance

Metas iniciais:

State lookup P50 < 10ms
State lookup P95 < 30ms

Context validation P50 < 5ms
Context validation P95 < 20ms

Event propagation P95 < 500ms

Valores poderão ser ajustados conforme infraestrutura real.

88. Caching

Estados poderão ser cacheados quando:

baixa volatilidade;
leitura frequente;
versão conhecida.

Cache deverá sempre permitir:

version validation

89. Hot State

Exemplos:

active workflow
active execution
current UI selection
current entity revision

poderão ter armazenamento otimizado.

90. Cold State

Histórico poderá permanecer em armazenamento mais econômico:

snapshots
event history
audit
historical context

91. Cloudflare Compatibility

A implementação deverá manter abstrações para storage e coordination.

Não assumir:

local filesystem
local memory permanence
single process

O desenho deverá funcionar sobre componentes compatíveis com:

Cloudflare Workers
D1
KV
R2
Durable Objects
Workflows

quando aplicável.

92. Não Criar Dependência Prematura

O PRD não obriga o uso de Durable Objects para tudo.

Cada mecanismo deverá possuir interface abstrata.

Exemplo:

interface StateCoordinator {
  acquire(resource: string): Promise<void>;
  release(resource: string): Promise<void>;
}

A implementação poderá mudar sem alterar o domínio.

93. First Vertical Slice

O primeiro caso será:

Work Permit + Training + Workflow + UI + Agent

Cenário inicial:

Usuário abre WP-1001
 ↓
UI seleciona WP-1001
 ↓
Agent recebe contexto
 ↓
Agent consulta Training
 ↓
Workflow começa análise

94. Mudança Durante Execução

Enquanto o agente trabalha:

Training status:
VALID

o LMS envia:

TrainingStatusUpdated

alterando para:

EXPIRED

95. Synchronization

Evento:

TrainingStatusUpdated

produz:

State Fabric
 ↓
invalidate Agent Context
 ↓
invalidate Decision Context
 ↓
notify Workflow

96. Decision Re-evaluation

O Decision Engine percebe:

previous evidence = stale

e não reutiliza silenciosamente a decisão anterior.

97. Policy

A Policy poderá determinar:

Training expired
→ Work Permit cannot be released

98. Runtime

Se a execução estava:

RELEASE_WORK_PERMIT

o Runtime receberá:

CRITICAL STATE CHANGE

e deverá:

PAUSE

ou:

STOP

conforme policy.

99. User Experience

A UI deverá receber:

Agent execution paused

Reason:
Training associated with this Work Permit expired
during validation.

Action:
Review required.

100. No Race Condition

Se o usuário tentar liberar simultaneamente:

User → Release
Agent → Release

o Business API deverá aplicar:

version check
+
business rule
+
authorization

A primeira operação válida altera o estado; a segunda deverá ser reavaliada.

101. Acceptance Criteria

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

State e Context Fabric persistem snapshots versionados, referências de entidades, projeções e permissões de contexto tenant-bound. Deltas canônicos detectam conflito/staleness; uma mudança crítica pausa runtime ativo, invalida confirmação de plano e registra eventos de sincronização sem alterar o estado de negócio por inferência. O reconciliador agendado marca contexto sem estado obrigatório como UNKNOWN e repete entregas de projeção duravelmente.

Em 2026-09-05, assinaturas do State Fabric passaram a seguir a mesma vinculação de identidade das projeções: usuário não-governor só pode criar assinatura UI para si; assinantes internos, agentes, conhecimento ou outro usuário exigem governor. Isso impede a criação de consumidores internos e de escopos declarados por um usuário comum. Worker 9e378647-e165-4617-88ff-47f05415a5b8 publicado com health público saudável.

Em 2026-09-05, o gate de State & Context Synchronization passou com 43 testes em 5 arquivos. O canário remoto comprovou em tenant sintético isolado estado canônico na versão 2, contexto INVALID, runtime PAUSED na versão 2, notificações de workflow e comunicação, confirmação invalidada, projeção na versão 2, subscription entregue, replay histórico na versão 1, proteção contra corrida e formulário sujo, sem autoridade de execução; o cleanup confirmou remainingRows:0.

Em 2026-09-06, a regressão atual de sincronização operacional, rota, runtime e State Fabric 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.

102. Resultado Arquitetural

Com o PRD-035, o Agentic Work passa a possuir uma noção formal de realidade compartilhada.

A arquitetura passa a ser:

                       BUSINESS SYSTEM
                             │
                             ▼
                     CANONICAL STATE
                             │
                    ┌────────┴────────┐
                    │                 │
                    ▼                 ▼
               EVENT FABRIC       STATE FABRIC
                    │                 │
          ┌─────────┼─────────┐       │
          ▼         ▼         ▼       │
       Workflow  Knowledge   UI ◄─────┤
          │         │         │       │
          └─────────┼─────────┘       │
                    ▼                 │
                 AGENTS ◄─────────────┘
                    │
                    ▼
             EXECUTION RUNTIME
                    │
                    ▼
                 VERIFY
                    │
                    ▼
              CANONICAL STATE

A consequência mais importante é:

O agente deixa de trabalhar apenas com “informação disponível” e passa a trabalhar com informação cuja versão, origem, validade e relação com o estado atual podem ser verificadas.

Isso é fundamental para que o sistema possa evoluir de um conjunto de agentes para uma verdadeira plataforma operacional.

PRD-036 — Agentic Goal Management & Continuous Task Pursuit

O próximo problema natural é diferente de planejamento e execução.

Até agora o agente consegue:

receber intenção
→ planejar
→ executar
→ adaptar
→ sincronizar estado

Mas uma empresa frequentemente não quer apenas uma ação.

Ela possui objetivos persistentes.

Exemplo:

“Mantenha todos os Work Permits dos funcionários em conformidade.”

Isso não é:

uma execução

nem:

um workflow isolado

É um Goal.

O PRD-036 deverá portanto introduzir:

GOAL
  ↓
OBJECTIVES
  ↓
KEY RESULTS
  ↓
POLICIES
  ↓
SIGNALS
  ↓
PLANS
  ↓
EXECUTIONS
  ↓
OUTCOMES
  ↓
RE-EVALUATION

com:

Goal Definition;
Goal Ownership;
Goal Scope;
Goal Hierarchy;
Goal State;
Goal Progress;
Success Criteria;
Constraints;
Deadlines;
Persistent Monitoring;
Goal-to-Task decomposition;
Goal-to-Workflow;
Goal-to-Agent delegation;
Goal prioritization;
competing goals;
goal conflicts;
measurable outcomes;
progress tracking;
continuous replanning;
proactive task generation;
budget allocation;
human ownership;
goal approval;
goal suspension;
goal cancellation;
goal completion;
goal failure;
long-running objectives;
tenant-specific goals;
security boundaries;
audit;
observability;
learning.

A mudança conceitual será:

PRD-005
"Entenda o que o usuário pediu."

PRD-032
"Encontre a melhor forma de fazer."

PRD-034
"Adapte a execução enquanto faz."

PRD-035
"Garanta que todos trabalham sobre o estado correto."

PRD-036
"Garanta que o sistema continue perseguindo
o objetivo até que ele seja realmente atingido."

Isso começa a transformar o Agentic Work de um executor de comandos em um sistema operacional orientado a objetivos, sem permitir autonomia irrestrita ou ultrapassar as fronteiras de Policy, autorização e governança.

1. Objetivo​

2. Problema

3. Princípio Fundamental

State​

Context​

4. State Ownership

5. Canonical State

6. Entity Version

7. Optimistic Concurrency

8. Por que isso é crítico

9. State Fabric

10. State Fabric ≠ Database

11. State Snapshot

12. Snapshot Semântico

13. Context Snapshot

14. Context Validity

15. Context Staleness

16. Context Invalidation

17. Context Delta

18. Context Version

19. UI Synchronization

20. UI State ≠ Business State

21. UI Optimistic State

22. Unsaved Changes Protection

23. Form State Version

24. Business State Synchronization

25. Event-Driven Synchronization

26. Read-After-Write

27. Eventual Consistency

28. Strong Consistency Boundary

29. Consistency Levels

30. Capability State Requirements

31. Example

32. State Conflict

33. Conflict Record

34. Source Authority

35. UNKNOWN State

36. Unknown ≠ False

37. Temporal State

38. Historical State

39. State Timeline

40. Workflow Synchronization

41. Workflow Transition

42. Execution Synchronization

43. Completion Verification

44. Agent Synchronization

45. Agent Context Invalidation

46. No Automatic Re-execution

47. State Subscriptions

48. Subscription Filtering

49. Tenant Isolation

50. Cache Isolation

51. Permission Context

52. Policy Version Synchronization

53. Policy Change During Execution

54. Knowledge Synchronization

55. Knowledge Drift

56. Retrieval Guard

57. State Projection

58. Projection Metadata

59. Projection Lag

60. Projection Recovery

61. State Replay

62. Replay Modes

63. Production Replay Protection

64. State Lock

65. Prefer Versioning Over Long Locks

66. Distributed Lock

67. Lock Safety

68. State Machine

69. Invalid Transition

70. State Fabric Responsibility

71. State Synchronization API

72. Context Synchronization API

73. Context Delta

74. State Synchronization Flow

75. Active Execution Revalidation

76. Example

77. Execution Response

78. Context Conflict Resolution

1. Objetivo

State

Context

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