Windows Agent Memory Readiness Audit for a Downstream SDK Upgrade

What they did

AiphaBee, a private downstream bot product, was upgrading from @byok-sdk/client 0.28.0 and wanted to replace its own agent-home memory writer with the SDK's memory_recall / memory_save, agent.memory.projection and agent.memory.intent. Instead of testing on hardware, the author read the SDK source at tag v0.28.0 (ad0d2d25) and traced the platform gate: isAgentMemorySecureFilesystemAvailable in packages/client/src/daemon/agent-memory.ts only returns true on native Linux or macOS with a verified helper, with a comment saying Windows stays unavailable rather than picking an unproved fallback; agent-memory-helper-release.ts throws on non-darwin; and create-daemon.ts fails construction when agentMemory is set on an unsupported platform. They cross-referenced the product PRD sections listing the P2-win work items (TS platform gate, tagged identity, Go open admission, empty-env startup, windows-latest reparse/junction matrix, NTFS ledger backend, two proofs and broadcast), the wo09 Windows ledger validation doc marked BLOCKED, and the workflow_dispatch-only agent-memory-windows.yml. After searching existing issues for Windows memory, P2-win and NTFS and finding no open tracker, they filed a structured downstream issue with reproduction, acceptance criteria, downstream impact and related closed issues (#522, #521, #317). They then updated the issue with a dated status: items 1, 2 and 5 done via #761 (Windows x64 recall/save, projection, export, win32-x64.exe helper shipped) and #797 (junction/symlink and barrier injection tests in ci.yml); item 3 still blocked because strictLedgerBarrier is false on Windows so agent-memory-intent.v1 is not broadcast; item 4 partially done pending the A7 barrier conclusion.

How it went

Produced a precise, source-cited blocker report that the SDK maintainers could act on, and it moved: Windows x64 recall/save, projection and export shipped in 0.29.0 with a signed helper, and CI now runs the junction/symlink matrix. The intent broadcast and NTFS barrier semantics remain open, gated on a private helper v3 contract (W2-B), A4 evaluation-VHD licensing, and two rounds of power-loss experiments. AiphaBee kept its own memory writer and deferred its S13 switch rather than shipping a macOS-only intermediate state.

Worth knowing

The reproduction is derived from reading source, not from running 0.28 on a Windows device, so the exact error text is inferred. No version or milestone was committed for the remaining intent work. The helper v3 contract is private and incompatible with v2, requiring lockstep daemon and helper upgrades. The power-loss experiments depend on hardware and licensing decisions outside the reporter's control.

Wiring

Pin the SDK to an exact tag and cite commit SHAs in the report. Read packages/client/src/daemon/agent-memory.ts for the platform predicate, agent-memory-helper-release.ts for helper admission, and create-daemon.ts for the config-time failure. Cross-reference the product PRD P2-win acceptance rows and the Windows ledger validation doc's status line, plus .github/workflows/agent-memory-windows.yml to see whether checks are scheduled or manual. Keep a single SDK import point (packages/byok-host) so the platform gate is evaluated in one place. File the issue with a dated status block that gets edited as upstream PRs land, and subscribe to it as the downstream progress tracker.

Try it yourself

Audit my repo's use of @byok-sdk/client agent memory on Windows. Read the pinned SDK tag, find every platform gate around agent memory (secure filesystem availability, helper release admission, DaemonConfig.agentMemory construction), and list which memory features (memory_recall, memory_save, agent.memory.projection, agent.memory.intent) are actually available on win32-x64. Then check whether my daemon config sets agentMemory unconditionally, and draft a downstream issue with: versions and environment, source file:line citations for each gate, a minimal reproduction, acceptance criteria mapped to the SDK's own PRD items, downstream impact, and links to related closed issues. Search existing issues first so I do not file a duplicate tracker.