PostgreSQL

The work graph behind AgentOS

In AgentOS the root problem was state held in a model's context, so I put all of it in PostgreSQL, the one source of truth. Every work order, task, piece of evidence, verdict and cost lives in a relational work graph, and the readable views agents see are generated from it and never edited back. Cost attribution and the effort methodology are computed in PL/pgSQL from the same tables. Schema changes are generated and run against a throwaway database before they touch the real one. See Why long agent runs fail.

The work graph

work order

task

evidence

verdict

cost

What agents read

the third view was edited by an agent (orange) and is discarded; the fourth is drawn again from the rows

One governed write path for many workers

In FAFO Core and Function Forge many AI and batch workers share one database, so I decided functions read freely and write only through one governed write path. The data layer is schema-agnostic: a resolver reads the system catalogs, checks every identifier and binds by actual column type, so generated code reaches the database only through it and cannot build unsafe SQL. Work items are claimed by lease, and parallel workers never process the same item.

Work items over time · one lease each

item 1

item 2

item 3

item 4

worker A

worker B

holder gone; the lease runs out, then B claims it

When a bulk update deadlocked, I measured from PostgreSQL's tuple counts, because write performance is what PostgreSQL committed, and one unique index ended them: 196 deadlocks to zero. Probe generation and hidden-state mining keep their work items and results here with multi-table atomic writes: The workload that shaped the platform.

Metadata in, vectors out

In Inference Fabric the first generation pulled vectors out of PostgreSQL into a Python indexing job, and that was the bottleneck. My rule for the second generation: metadata in PostgreSQL, vectors never through SQL. Work-item rows are where results return, closed by a small completion service.

First generationVectors pulled out through SQL

metadata and vectors through the same pipe

Second generationMetadata in PostgreSQL, vectors never through SQLlineage and catalog rows in the database; vectors in GPU-addressable shards

rows in the database · vectors on the device

Partitions that follow the data

In the memory capability of FAFOHive code indexes come and go, so the code index is partitioned per index and the action log by month. Search ranks weighted full-text and dense vectors in the same rows. Dependency tracing is a bounded breadth-first traversal in SQL over stored call-graph edges, with no model involved: A code explainer that is not allowed to invent.

Code index · one partition per index

repo one

repo two

dropped whole

Action log · one partition per month

history accumulates; only the newest partition is written

Push with a polling fallback

In Agent Swarm I wanted push-speed signals without trusting push alone. Catalog drift detection listens with LISTEN/NOTIFY, falls back to polling when notifications back up past measured thresholds, and waits through a hysteresis period before switching back.

Catalog drift detection over time

Push · LISTEN/NOTIFYBacked up past threshold · pollingHysteresis waitPush again

The worker that turns agent actions into searchable memory claims rows with FOR UPDATE SKIP LOCKED and writes on natural keys, so a replay after a crash adds nothing twice and multi-worker processing is safe to retry. See Tools are the platform.

Conversations that survive restarts

In Helix a conversation with several model seats has to survive restarts and account switches, so the Control Center keeps sessions, documents and council deliberations in PostgreSQL across forty migrations. The Teams working service stores submissions and start claims there, and identical concurrent submissions resolve to one winner.

Teams working service · two identical submissions, same moment

firstsecondstored

the second resolves to the first; one row, one start claim

I build systems around PostgreSQL as the authority that makes autonomous agents' work recoverable and auditable, and the same habits recur across very different systems.