CBAMbridge: shipping an agentic AI compliance platform in 6 weeks

01 — ContextThe problem hiding inside a regulation

In 2026, the EU's Carbon Border Adjustment Mechanism (CBAM) began requiring importers to report the embedded carbon emissions of goods like steel, aluminium, cement, and fertilizer. For large corporations with sustainability teams, this is an annoyance. For the 10,000+ small and mid-sized U.S. exporters in these supply chains, it's a wall — they have no compliance staff, no carbon accountants, and no affordable tooling.

The core friction wasn't understanding the law. It was the data work underneath it: pulling emissions figures out of utility bills, fuel receipts, and production logs that arrive as inconsistent, unstructured PDFs, then mapping them to CBAM's specific calculation methodology. Done by hand, a single product's reporting could take days of expert time most of these businesses don't have.

02 — DiscoveryFinding the one workflow that mattered

I started with conversations, not code. Talking to people inside small manufacturing and export operations, one pattern surfaced again and again: the bottleneck wasn't the final calculation or the regulatory interpretation — it was the manual extraction of data from documents. People were squinting at scanned utility bills and re-typing numbers into spreadsheets.

That insight scoped the entire MVP. Instead of trying to build a full compliance suite, I narrowed to the single highest-friction step and worked backward from it.

03 — The key decisionWhy an agentic pipeline, not a single prompt

The naive version of this product is one large prompt: dump the PDF text in, ask the model for emissions data, hope for the best. I rejected that early. Emissions reporting is a high-stakes, auditable workflow — a hallucinated number isn't a quirky output, it's a compliance liability.

So I architected it as a multi-step agentic pipeline using LangGraph, where each stage has a defined job and its output can be inspected:

Choosing LangGraph over a single chain meant I could add checkpoints, retries, and inspection at each node — which became essential the moment things started breaking.

04 — What brokeThe honest part

The first version worked beautifully on clean PDFs and fell apart on real ones. Utility bills from different providers had wildly different layouts; some were scanned images, some had data in tables the extractor flattened into nonsense. Early on, the agent would confidently produce emissions figures that were plausible but wrong — the most dangerous failure mode for a compliance tool.

I couldn't ship something that fails silently. So before adding any features, I built the thing that made the product trustworthy:

• A LangSmith observability layer so I could trace exactly where in the pipeline an extraction went wrong, instead of guessing from a bad final output.
• A gold-dataset regression framework — a curated set of documents with known-correct answers that every change had to pass before merging, so improvements in one area couldn't quietly break another.

This eval infrastructure cut the agent error rate by 40% and, more importantly, turned "I think it works" into "I can prove where it works and where it doesn't."

05 — Making it usableRemoving expertise as a prerequisite

The data pipeline solved the hard technical problem, but the user still faced 200+ pages of regulation to even know what to report. So I decomposed that regulation into a guided Registration Wizard — a structured flow that asks plain-language questions and assembles the compliance picture behind the scenes.

The goal was simple: a small-business operator with zero carbon-accounting background should be able to get to a valid output without ever reading the underlying law. That reframing — from "tool for experts" to "expertise built into the tool" — is what makes it a product rather than a utility.

06 — Outcome & reflectionWhat I'd build next

The result was a live MVP shipped in 6 weeks that reduced manual processing time by an estimated 85% and, just as importantly, produced output its users could actually trust. I owned the full lifecycle: discovery, architecture, build, evaluation, and deployment.

What this project taught me as a product builder:

• Scope to the real bottleneck. The discovery conversations saved me from building the wrong, larger thing.
• In AI products, trust is the feature. The eval framework wasn't overhead — it was the difference between a demo and a usable tool.
• The hardest part is rarely the model. It was the messy real-world data and the user's lack of domain expertise — both product problems, not ML problems.

The natural next steps are multi-jurisdiction support (the same document-to-data engine generalizes well beyond CBAM) and automated report generation — turning the structured output directly into submission-ready filings.