Commodity trade platform: verification and AI agents for physical commodity trade

The problem

Physical commodity trade in metals, rare earths and critical minerals runs on trust that is hard to check. Counterparties can’t easily prove that goods exist, that title is clean, that documents are real or that the other side can perform. The industry loses an estimated trillion dollars a year to fraud and fragmentation.

The platform closes that gap by combining deterministic verification with an agentic layer. Rules with legal or financial consequences are enforced in code and never decided by a model. AI speeds up everything around them.

I lead engineering and AI delivery across seven repositories and act as the in-house product manager: requirements, architecture decisions and the sequencing between an internal team and an external engineering partner.

Architecture

A modular monolith with supporting services, each deployed independently so no two releases have to ship together: the core platform (75 modules covering deals, verification, custody, settlement, billing, audit and admin), the trader web app, an operations and compliance console, real-time deal-room chat, the AI workers, a mobile client, and infrastructure as code.

The interesting engineering is in the domain model, not the framework.

• Conditions-for-Completion (CFC) is the execution authority. A deal moves through a dependency graph of conditions, each with its own evidence and acceptors. The nine visible deal stages are a read-only view of that graph and never an input to it, because a cosmetic label must never drive a financial transition.
• Two-tier verification. A Commodity Pass proves custody and title and is verified by an operator. A Batch Pass proves quality for one deal and needs dual consent. Owning goods and warranting their quality are different claims, made by different people at different times.
• Goods accounting. Sub-lots keep their lineage through splits, merges and custody transfers. Positions are ledger entries with a database-enforced issuance ceiling, so nobody can sell the same tonnes twice.
• Supporting layers. Document validity scoring, a rules-only fraud screening engine, a disclosure layer that controls what a counterparty or bank can see, and an immutable audit log of every state change.

MegaBrain, the agent layer

MegaBrain is the reasoning and automation layer over the platform, and its key constraint is simple: it proposes, a human disposes.

Agents write proposals into the platform API as actions that move through pending, decision and executor states. The UI never calls a model directly. An agent can draft a Commodity Pass from a document bundle, pull a condition out of an emailed contract or write a chase message, but an operator submits it. That boundary is enforced in the API, not by convention.

Fourteen Python workers handle OCR, field extraction, document validity, contract analysis, cross-checking, inspection, sentiment, profile building and context assembly, on a shared queue with one redaction and logging policy. Every agent action is metered for cost attribution and usage-based pricing.

One brain, assembled fresh every turn

The platform is big: 121 controllers, 9 workflow families and around 60 named user flows. The usual instinct is to split that into specialist agents and route between them. That fails here, because a user’s problem is one tangled state. A stalled signature is really a team-roles problem; a tranche that won’t release is a document review wearing a settlement costume. Specialists would each see part of the same person.

So the split is horizontal, not functional. MegaBrain runs as one identical brain per active user, built on LangGraph and deepagents. What changes between two live instances is never who is answering, only what that answerer has loaded.

• Skills, loaded on demand. The workflow catalogue is split into about 30 markdown skill packets, divided by failure mode rather than by document heading. The prompt only carries their index; a packet is read when it’s needed, with at most three resident at once.
• Cache-aware ordering. Context is ordered by how often it changes: core, then skills, then the live user state, then messages. Skill IDs are sorted deterministically so the same set hits the cache every time, a one-line detail that is worth real money at volume.
• The platform routes before the model does. Error codes, the deal’s sub-stage, the user’s open action items and the screen they’re on pick the right skills before the first token. Semantic matching is the fallback, not the default.
• A user envelope. Before the model wakes up, about 800 tokens of live state are assembled: workspace, verification, plan, open items and where the user is standing. The agent never has to ask who you are, and can name a blocker one step before you hit it.

Authority is a property of the registry, not the prompt

Prompt-level rules weaken under pressure; registry-level ones don’t. Every tool is stamped before it’s registered.

The agent can explain a red act in detail, show you where the button is and pre-check every condition so your click succeeds. It can’t press it. An assistant that could sign your contract would be a liability disguised as a convenience.

Autonomy is a dial, set by reversibility

The real line isn’t “writes or doesn’t”, it’s whether an act can be undone. Most of what slows a trade down is reversible admin: chasing a missing certificate, refreshing stale screening, saving a draft, re-running a search. Each user sets the dial per type of object, with an expiry, and can pull it back to zero in one click.

When it finds something wrong, it sorts it three ways: small unambiguous defects it corrects, reversible fixes it makes under mandate, and things it must not touch. A mismatch between an assay certificate and a bill of lading isn’t a typo to tidy away; it’s exactly the signal the anti-fraud layer exists to catch, so the agent stops and flags it.

Sidecars, sub-agents and knowledge

• Six sidecars do what a model shouldn’t: sandboxed code execution, document vision, rendering, allow-listed web fetch, deterministic money and price maths, and scheduling. They’re pooled, scaled on their own queue depth and given a per-call credential scoped to the user’s workspace.
• Sub-agents are for context, not capability: a document analyst that turns a 90-page contract into 400 tokens of facts, a researcher, a data runner and a thread reader. They inherit their caller’s authority and can’t escalate.
• Two knowledge corpora with a hard wall. A global product corpus, and each workspace’s own deals, documents and threads in a knowledge graph. Tenant scope is bound into the query before traversal, never filtered afterwards, because a retrieval that walks into another tenant’s data has already leaked.

Verify, don’t remember

1. Assemble the user's live state
2. Route to skills before the first token
3. Plan only when the request spans steps
4. Execute one step at a time
5. Verify by re-reading state after every write
6. Report the exact field, queue or person

Each tool declares the change it should produce, and a chain is checked against those post-conditions rather than its HTTP codes. Confirmed chains dry-run in a shadow workspace first, so what the user approves is what will happen. A half-finished chain is reported as half-finished, and recorded chains replay in CI so a renamed API field turns the build red, not the user’s day.

The same brain has three doors: interactive chat, ambient drafts for WhatsApp and email replies that wait for your approval, and monitors that can raise an alert but never act.

Runs on our own GPUs

Every conversation, and every background job, gets its own disposable worker pod on Kubernetes: same image, same skill files, different user. Nothing lives inside a worker, so one can be replaced mid-sentence and the user sees a pause, not a loss. Hard questions are split by a planner into short-lived sub-agents that run in parallel and fold their results back together.

The model is an open-weight model served on our own GPUs. Trade documents and counterparty data never leave our infrastructure, and the cost of a conversation is ours to control rather than a per-token bill.

Principles I hold the team to

• Deterministic where it matters. AI produces findings and drafts. It can’t authorise, adjudicate, sign, clear sanctions or release funds.
• Fail closed, and fail loudly. A guardrail without a CI-gated negative test counts as not implemented.
• Additive change only. New contract shapes ship alongside the old ones; the old path goes in a later release.
• Fixed-precision decimals in settlement. No floats anywhere near money or quantity.
• Tenant scoping by default. Cross-organisation access is a security boundary, not a filter.

Problems worth solving

Double-selling prevention. A goods-balance ledger where availability is enforced by a database constraint at commit, so the number a user sees and the number enforced on write can’t drift apart.

Acting for an absent counterparty. Operators can progress a deal for a party who isn’t on the platform without ever forging an attestation. Authority is per deal, revocable and recorded, and anything compiled without the owner’s own attestation is capped at a lower trust tier and disclosed as such.

Permission design. Replacing a single-role model with per-user capability grants, so one person can’t both approve a policy release and adjudicate the cases it governs.

Verify before you redact. Documents shared between counterparties are forensically scanned in their original form and only then redacted, because doing it the other way round makes a genuine document look tampered with.

How we work

The team is moving to spec-driven development: a requirement becomes a signed spec, a design document and an ordered task list before any code is generated, and changes are made to the spec and regenerated rather than patched. I led the evaluation, the adoption plan and the governance for it across the multi-repo estate.

SOC 2 attestation is in progress, backed by structured logging with secret and PII redaction, capability-based access with separation of duties, immutable audit trails, automated evidence collection and scheduled penetration tests.