System

FAFO Core and Function Forge

The execution substrate under everything else: one function definition becomes an orchestrated, budgeted, agent-callable tool

Rust · generated function cratesRedis Streams and PostgreSQLLocal, LAN and cloud GPUs
One function · three axes · set by configuration
The same function, placed on a cloud GPU
packed to a token budget, under a budget a person set
A change of hardware is a change of config
  • 7 of 14function crates written by the generator
  • 19control actions on a job in flight
  • 180actions across 18 tools, compiled from YAML schemas
  • 23close items on the integration platform, each with an independent verdict

Every organisation that puts AI agents to work hits the same wall. Each new capability needs its own integration, orchestration, database plumbing, rate limiting, compute and someone to run it. I was going to build many systems and I did not want to solve orchestration, data safety and spend control more than once. FAFO Core is the substrate where those are solved. One function definition becomes an orchestrated, controllable, agent-callable tool that runs against any registered data source, in-process or in a container on a local machine, a LAN workstation or a rented cloud GPU, under a budget a human set. Function Forge is the generator that lets an agent write such a function itself, inside a sandbox, callable only after a human rebuild and restart.

The idea

One execution model, three orthogonal axes. Lifecycle: a one-off job or a continuous service, with queue-depth and interval triggers. Batching: by row count, by GPU token budget, or decoupled submit-and-exit, with memory-budget packing. Location: in-process or in a container, local, LAN or cloud. The same function runs in any combination by configuration, so a change of hardware is a change of config.

AI agents are bounded authors. The generator emits framework files the author must not modify and a developer zone where the author writes logic against a context object, never against raw resources. Reads go through a schema resolver that validates every identifier. Writes go only through the governed queue. The human gate sits exactly at the privileged step, the rebuild and restart, and nowhere else. See Tools that build tools, under governance.

One generated function
generated, lockeddeveloper zone, open
framework files and the wiring into the gateway and control planelogic against a context object; reads through the schema resolver, writes through the queue
A new tool
generateauthorbuildhuman restartregistered

What I built

The universal execution trait and the generic conductor that runs it across lifecycle, batching and location.

The function lifecycle: design, generate, wire, author, validate, build, human restart, link-time registration, execute, control, delete. Registration at link time means a function is fully wired or the build fails; there is no half-registered state.

A control plane on a Redis-stream command bus with atomic job promotion and control of jobs in flight: pause, scale, drain, inspect.

A governed data plane: a single governed write path with a batching writer, schema-agnostic database operations validated through a schema resolver, and an admission controller. The writer and the admission controller are trade secrets.

A location substrate: runtime injection into generic containers; local, LAN and cloud GPU providers; loader modes for jobs, capabilities, agents and infrastructure; a fail-closed operator-calendar budget with per-second spend accounting that agents cannot raise from inside the provisioning path. Cloud GPU bursting sits under that gate.

A sibling API integration platform that applies the same idea to third-party APIs, a generic core plus a declarative unit per target, serving multiple integration profiles per server. I built it through gated AI work orders and held it open until every close item had an independent verdict. See Closed by evidence.

A model-facing gateway that compiles YAML tool schemas into dispatch.

The probe-generation pipeline, the workload that shaped all of this, which populated tens of millions of dataset items on two consumer GPUs. See The workload that shaped the platform.

Where the code is · approximate lines
Fourteen function crates168,000Core substrate45,000API integration platform20,000Generator17,000

The judgment in it

I let the real workload drive the substrate. Nothing speculative went in.

Each wall, and what came after it
The workload
wasted batch capacity gave token-aware packingcolliding workers gave lease-based claiming
deadlocks gave atomic multi-table writesblocked generation gave a decoupled producer

The first version of the generator passed its own fifteen-point integration check and produced code that did not compile. I redesigned it with the sandbox and inverted ownership instead of patching it.

No hot-loading.

Rebuild and human restart is slower, and it is the governance step.

When a bulk write path crawled with 196 deadlocks, I measured from PostgreSQL's own tuple statistics instead of the queue's counters, and one index took it to zero. See 196 deadlocks to zero.

What it demonstrates

Solving the platform problem once so every later system inherits orchestration, data safety and spend control; security by API design for AI-generated code; and the discipline to throw away a first version that passed its own tests.

Stories

Tools that build tools, under governance · 196 deadlocks to zero · The workload that shaped the platform · Closed by evidence · Redistribution inside the database · One call to a GPU anywhere · Twenty thousand rows a second · A write path that sizes itself · Rules that never ran · Pricing writes by what they cost the database

Technologies

Rust · Redis Streams · PostgreSQL write-behind patterns · Handlebars code generation · Link-time registration · Docker · Federated provisioning across local, LAN and cloud · Budget enforcement · YAML schema compilation · Model Context Protocol · PostgreSQL bulk-update engineering