Protected task state

Use a named connector as usual, then enable context.features.taskState with plugins.taskState: { taskId, scope: { ownerId, namespace, tenantId? }, association? }. Select these values in the trusted host, and keep userId consistent with the owner. The plugin is named task_state; access it through agent.context.getPlugin<TaskStatePluginNextGen>('task_state'). It shares the existing context/tool manager and exposes no model mutation/store tools.

typescript

const state = agent.context.getPlugin<TaskStatePluginNextGen>('task_state')!;
state.updateHost({ notes: [{ id: 'budget', category: 'constraint',
  text: 'Spend at most 40 EUR.', source: { label: 'Confirmed user instruction' },
}] }, state.revision);
state.propose([{ id: 'possible', category: 'decision',
  text: 'Submission may mean completion.', uncertainty: 'No remote verification.',
  source: { label: 'Explicit extractor output' },
}] , state.revision);

Import TaskStatePluginNextGen from the public package. Host corrections use new IDs with supersedes, and conflicts use conflictsWith. Action receipts are recorded explicitly from executeWithOutcome via recordAction; they do not set workflow completion. confirmAction supplies a separate sourced host status such as waiting_external or completed after the host's actual completion check. Admission failure never authorizes replay of an external action.

Default limits are 100 combined notes/actions, 8,000 estimated content tokens and 256 KiB strict JSON. Full protected state is counted in managed prompts; it remains through compaction/rollover or fails fit explicitly. Hooks cannot silently remove it at dispatch. JSON repair retains it; direct calls bypass it. No automatic extraction or model-obedience guarantee is provided.

Existing optional plugin snapshots persist state; foreign/future/malformed records fail preflight, and legacy snapshots without task state clear enabled notes. Restore only host-owned checkpoints. Task/routine statuses and MemorySystem task transitions keep their authority; explicit lifecycle views do not create another workflow engine. Read the complete recipe before configuring memory linkage, pruning, capacity handling or recovery. Offline examples: npm run example:task-state and npm run example:amos-task-state; live probes: npm run test:task-state:live.

Atomic host recovery at capacity uses the existing updateHost method with optional fields:

typescript

state.updateHost({ resolve: ['finished-question'],
  prune: { noteIds: ['finished-question'] },
}, state.revision);
// Only after the host verifies a terminal external outcome:
state.updateHost({
  confirmActions: [{ executionId, status: 'completed', source: { label: 'Verified remote status' } }],
  prune: { executionIds: [executionId] },
}, state.revision);

Notes, resolutions, confirmations and explicit pruning are one atomic transaction; only the final snapshot must fit, while the delta still satisfies the input limit. Invalid proof/target/status or overflow leaves the original state unchanged. Archive records before explicit pruning when needed. ID reuse detaches obsolete correction/ conflict links and keeps already historical predecessors inactive. Managed guards recheck after final budget observers, including repair validation. AMOS host commands add task prune, resolve-prune, prune-action and confirm-prune; they use the same host validation/checkpoint flow and make no model calls. Read Task State and the historical review/fix plan.