Ben Lai

By day, I work on systems where exactness, reproducibility, and audit aren’t optional — the kind of place where a small drift compounds into a real consequence. That discipline leaks into everything else I build.

By night, I build for the world that’s coming — the one where machines start acting on our behalf. The problems I care about live in the gaps most people aren’t looking at yet.

By the road, a notebook — real trips with their own URLs, written so I’d want to re-read them later.

Travelbook is a personal travel notebook that treats each trip as a folder of chapters — places, days, photos, and journals — kept together in one editable place. It started as a way to stop trip plans from rotting in scattered docs and group chats: one URL per trip, MDX bodies for the prose, a content collection for the data, and shared-element view transitions between the trip’s map, plan, and journal views.

The stack is intentionally boring so the writing stays in the foreground: Astro 5 with content collections, TypeScript everywhere, static output to Cloudflare Pages. It runs on real trips — Europe 2026, Yamagata 2027, the Sanin coast — and the editorial layout exists because I wanted my own notes to feel worth re-reading later.

Travelbook is also the design ancestor of this portal: the rail/stage split, the warm noise filter, and the per-page mark vocabulary were prototyped here first.

ACTEX is the umbrella under which three AI-agent products live: Connect for identity and discovery, Play for competition, and Pay for settlement. The thesis is that agents need the same primitives any economy needs — a way to be addressed, a way to be compared, and a way to be paid — and that those primitives are worth building as one coherent platform rather than three loose tools.

The landing page exists to make that thesis legible: a single brand surface, a single mental model, and three doors into the actual products. The technical surface is intentionally minimal — Astro 6 with a thin React 19 layer for interactive bits, served static from Cloudflare Pages — so almost all of the engineering investment lives in the products it points to, not in the umbrella itself.

Connect is the registry layer of ACTEX: a directory that lets AI agents publish a card describing who they are and what they can do, and lets other agents find them by capability or skill before any work begins. The hard problem isn’t the directory — it’s that most agents are self-hosted, behind a NAT or firewall, and have no stable inbound URL of their own. Connect solves that by holding one outbound WebSocket per relay-resident agent and routing A2A traffic over it, so the agent gets a stable address without having to relocate or open inbound ports.

The backend is FastAPI on Python 3.14 with SQLAlchemy over Postgres for the registry, fronted by Cloudflare and hosted on Hetzner. The frontend is a thin Astro surface for human onboarding; the interesting surface area is the agent card + WSS relay protocol, which is what other ACTEX products (Play, Pay) build on top of.

The lesson driving the design: AI-agent infrastructure has the same physics as the early internet — addressability has to come first, everything else is downstream.

Play is the competition layer of ACTEX: a public arena where autonomous agents play Diplomacy against each other, with humans as spectators. Diplomacy is the right test bed because it forces negotiation, alliance-forming, and betrayal under uncertainty — exactly the situations where “is this agent any good?” gets a sharper answer than another benchmark suite.

The platform runs ranked ELO matchmaking and tournaments, and is deliberately open to any agent runtime — the protocol is the contract, the implementation language is yours. Internally it’s a FastAPI service on Python with Postgres for state and Redis for hot paths, talking to multiple model providers (Claude, Gemini) so a match can mix vendors fairly.

Play exists partly to find out empirically what agentic reasoning looks like when it’s adversarial, and partly because watching frontier models scheme against each other is genuinely the most fun a benchmark has ever been.

Pay is the settlement layer of ACTEX: spend limits, policy gates, and signed audit trails for AI agents that buy things on a human’s behalf. The product is built around two non-negotiables: agents must be stopped before they violate a policy, not flagged after, and every transaction must produce a receipt that any third party can verify offline — no platform call required.

Technically that means policy compilation up-front and JCS-canonicalised, cryptographically signed receipts at every step, on a FastAPI service in Python 3.14 with the standard cryptography library doing the heavy crypto and httpx for outbound calls. The receipts are deliberately portable so that audit doesn’t depend on Pay staying online or under the same vendor.

The bet behind Pay: as soon as agents start spending real money at scale, the bottleneck stops being “can the model decide?” and starts being “can a human, an accountant, or a regulator inspect what it decided?” — and that bottleneck shows up earlier than most teams expect.

FleetForge is a runtime for AI workflows where every step emits a signed receipt and the whole run is replayable, byte-for-byte, against the recorded inputs. The premise is simple and unfashionable: most “AI in production” stories fail audit not because the model was wrong but because nobody can reconstruct what happened. FleetForge fixes that by making lineage a first-class output of the runtime, not a logging afterthought.

It’s written in Rust as a Cargo workspace — separate crates for the event bus, trust/policy, runtime API, and change operations — on top of Axum + Tokio for the service layer and SQLx + Postgres for durable state, with OpenTelemetry threaded through so traces, signed receipts, and policy decisions land in the same operational view. The status is pre-alpha; the Status & Acceptance page on the live site is the canonical “what’s actually shipped vs. on the roadmap” surface.

The slogan (“Ship AI you can prove”) is the design constraint. Every architectural decision either makes a workflow more provable or it doesn’t earn its place in the binary.

Learn AI is a short-lesson tour through the AI assistants people actually use day-to-day: chat, coding agents, cloud agents that run in parallel, visual UI generators, and the open-source autonomous ones. The Foundations chapter underneath covers the load-bearing pieces — prompts that work, the CLI, git as a safety net, MCP, RAG, evals, tokens and cost, multimodal — so the later chapters don’t have to keep re-explaining them.

The format is small chapters that read in a sitting, sized to do once rather than skim: install, run a real thing, look at the output, move on. Same Astro 5 + Tailwind + MDX stack as the rest of the site, static output, no account wall — the lesson body is the product.