Blog.
Notes from the build.

Agent memory, confidential computing, and the economics of separating storage from compute.

Posts

Showing all 5 posts, newest first.
9 October 2026 · Benchmark

Get 90% of memory questions right on 4% of the tokens.

On 267 user-fact questions from LongMemEval, Recall 0.12 with an embedding model answered 89.9% with a frontier model, sending about 4,400 tokens instead of the whole 104,000-token history. Keyword search answered 83.9%.

Agent memory · LongMemEval · Token cost · Latency
89.9%user-fact questions answered right
96%fewer tokens than the full history
0.9 msexact recall, p50
26 September 2026 · Launch

Resume a killed agent from a few kilobytes.

When an agent's pod dies, the next process picks up from records in your own bucket instead of a snapshot of the whole machine.

Agent memory · Recovery
20 / 20killed agents finished their task
+4.4%tokens to resume
KBof records, not a machine snapshot
24 September 2026 · Benchmark

Same accuracy as DuckDB, a fifth of the memory.

On one machine and one million vectors, Polign answered faster at the same recall, and a second agent can share the data.

Vector search · DuckDB · Memory use
5×less memory under load, 0.7 vs 3.7 GiB
3×faster to first answer
0acknowledged writes lost when killed
6 September 2026 · Benchmark

Serve 12.5 million passages straight from S3.

The index stays in one bucket; only the machine in front of it changes how many searches a second you get.

Object storage · Cost · Throughput
861 / ssearches from a $97-a-month spot machine
82 GiBindex, all in S3
$2a month for the bucket with no traffic
24 August 2026 · Design notes

Put agent memory where the agent runs.

Typed memory with fixed correction rules, on a database small enough for edge hardware.

Agent memory · Edge
37 MiBPolign at idle
Typedfacts with correction rules
Localfolder or your own bucket