2026-05-17Product· yforce1

Shipping 25 new AML capabilities in 8 hours with parallel AI agents

rev-53 went out yesterday: 25 new capabilities across streaming, scoring, sanctions reasoning, perpetual KYC, federated learning, SAR drafting, and the public marketing surface. Here is what we shipped, how, and what worked.

What just landed

Yesterday we shipped rev-53 — 25 new capabilities spanning the orchestrator, the cockpit UI, and the public marketing surface. Streaming ingestion, weighted-factor scoring, sanctions reasoning, perpetual KYC, federated-learning governance, LLM SAR drafting, public sandbox, trust dashboards, customer stories, press kit, this blog. All in roughly eight hours of wall-clock build time.

This post is the meta-update: what we shipped, the agent-driven workflow that produced it, and an honest note on what worked and what did not.

The waves

We organize work into "waves" — bundles of changes that can land in parallel because they touch disjoint surfaces. Rev-53 ran five waves end-to-end:

Wave A — Public-facing infrastructure

A1: Stripe-style /status page
A2: Synthetic-data sandbox with auto-expiring tenants
A3: Public /sandbox route
A4: Public /trust/<slug> dashboard with hash-chain integrity check
A5: Public OG-card generator for trust dashboards

Wave B — Orchestrator hardening

Streaming ingestion (Kafka + Debezium CDC)
Watchlist auto-pull from 8 sources
Weighted-factor scoring engine
Quota enforcement at the orchestrator boundary

Wave C — Reasoning and decision surfaces

C1: Continuous risk recompute on event ingest
C2: Perpetual KYC with change-event emission
C3: Federated-learning scaffolding (consent + governance only — no real training yet, and we are honest about that)
C4: LLM-powered SAR drafting with redaction + finalize step-up
C5: Sanctions reasoning engine with weighted factors + LLM rationale

Wave D — Cockpit

D1: Settings pages for streaming + WLM auto-pull + scoring
D2: Graph explorer + scenarios catalog
D3: Crypto screener + sanctions reasoning panel
D4: Perpetual-KYC feed + federated-learning governance
D5: SAR composer + SAR list

Wave E — Marketing surface (in progress)

E1: Marketing landing redesign
E2: Brand and design-system showcase
E3: Customer stories + press kit + blog (this post lives here)

How the agents worked

Every wave was driven by a different specialised agent. Each agent owned a strict file scope — for example, the wave that built the SAR composer touched the SAR endpoint, the SAR data model, the cockpit composer page, and nothing else. The agent picked its own implementation details, ran tsc --noEmit to verify the cockpit still type-checks, and committed with a structured message.

Several waves ran in parallel against the same main branch. Conflicts were rare because the file-scope split was sharp: D2 owned graph + scenarios, D5 owned SAR — they never wrote the same file. The two cases of actual overlap (both adding entries to the navigation, both appending to middleware.ts) were handled with surgical, append-only deltas instead of overwrites.

What worked

Strict file scopes is the single biggest unlock. Telling an agent "you own these N files, do not touch any others" eliminates merge conflicts and makes review tractable.

Static type checks as the gate, not a test suite. tsc --noEmit against the cockpit catches the class of error that breaks a build, and it runs in seconds. We rely on Playwright e2e and a per-surface smoke test for the rest, but tsc is the per-wave gate.

Honest content. Pages like /customers and /blog carry an explicit "illustrative" banner. We would rather show the shape of an outcome and label it honestly than fabricate quotes from customers who do not exist. Auditors will read these pages.

What did not work

Cross-wave references are hard. When wave D needed an endpoint that wave C was still building, we sometimes ended up with a placeholder client in D that pointed at a not-yet-deployed endpoint. The fix is to land orchestrator changes first, then run UI waves against the live endpoint — but that serializes work we wanted parallel.

Banner copy duplicates. Six new public pages each have their own footer with the same four links. The pattern is fine in isolation; it does not deduplicate. A future wave will lift the footer into a shared server component.

Federated learning is not "shipped" — it is scaffolded. The orchestrator records consent and the governance UI lists participants, but there is no real training loop yet. We say so on the surface itself, because we would rather under-promise than ship "AI-washed" copy.

What is next

Wave F will harden the marketing surface (SEO, OG cards, sitemap) and ship the first real customer story when a pilot signs the approval form. Wave G is the federated-learning training loop — turning the scaffolding from C3 into something that actually moves a model.

If you want to see any of rev-53 in action, the sandbox is the fastest path — synthetic tenant, no signup, expires in 60 minutes.

— yforce1

Read more from the team on the /blog index.