Why we build Pea this way.

Governance starts at source

Pea assigns compliance markers at the architecture level. To every primitive, every runtime event. That means at any moment you can stop Pea cold and get a full readout of exactly what it's doing, not as a log dump, but as a structured telemetry bundle that an auditor can actually read.

Before I was building agent runtimes I worked in physical commodities. Specifically in minerals and mining compliance, the Dodd-Frank conflict minerals provisions under the SEC, and REACH under the EU. What those frameworks taught me is that compliance has to start when the material is created at source. Not after it's been processed into a finished good. Traceability is not a reporting layer. It's the chain itself.

As the AI landscape gets messier, more models, more autonomous systems, more consequential decisions being delegated to software, traceability is the only thing that will hold. Audit-grade decision records aren't a nice-to-have. They're infrastructure.

Governance isn't friction. It's standardisation.

The common objection is that governed agents are slow agents. Approval gates everywhere, humans in the loop constantly, nothing gets done. This misunderstands what governance actually is.

Compliance is standardisation. The industrial revolution ran on steam, but it scaled because of standardisation, interchangeable parts, common tolerances, shared specifications. Without that, every machine is a one-off.

When Pea scales out clone agents to handle a large task, every clone produces work that carries the same standard envelope as the master Pea instance. Pea doesn't have to inspect each clone's output in depth before it executes, because the bundle produced by a clone is structurally identical to one Pea made itself. The governance layer is the proof. Trust is flat. Coordination cost doesn't compound as the agent family grows.

That only works if the standard is architectural, not cosmetic.

Nothing reaches execution unsanctioned

One of the questions I get is: what happens when Pea is mid-task and about to do something consequential? The honest answer is that the situation shouldn't arise.

All tasks entering Pea's workflow pass through a resolver before they touch anything real. The resolver evaluates the intent, then either allows it, denies it, or surfaces a clarification request. That adjudication happens at intake, not as the agent is about to fire a live action. If a task is unsanctioned, it doesn't reach execution. There are no surprises at the last moment because the decision was already made at the front.

This is a deliberate inversion of how most agent frameworks handle approvals. Gating at execution makes the agent feel unreliable, it builds a plan, reaches the critical step, then stops. Gating at intake makes the agent feel trustworthy, it knows what it's allowed to do before it starts, and it completes what it begins.

Anyone in the organisation can read it

Pea is an enterprise product, which means it needs a first-class operator UI, not a dashboard built for engineers. The telemetry bundles Pea produces can be displayed as a task view, a posture view, or mapped against a specific compliance standard. A user selects the lens they care about and sees what's allowed, what isn't, what's recorded, and when.

Too much of what current agents do is invisible. The decisions happen in inference, the actions happen in API calls, and the only record is whatever the developer chose to log. That's not viable in any organisation that has audit obligations, legal exposure, or regulated workflows. Visibility needs to be a first-class product feature, not something reconstructed after the fact.

The harness outlasts the model

In two years, won't models be capable enough that governance overhead becomes irrelevant? The architecture question answers itself.

New models aren't certified. Pea, as the harness those models run inside, will be. We're building toward formal compliance audits, not just to pass them but to exceed them. When a new model ships, when architectures shift from MoE to something else, when chain-of-thought behaviour changes, none of that breaks Pea's compliance posture, because the compliance posture lives in the harness, not the model. Reproducibility matters. Certification attaches to Pea.

What Pea actually is

In trading there's a saying: you're only as good as your last deal. Something similar applies to agents. An agent is only as reliable as its last mistake.

The industry is obsessed with capability. More tools, more autonomy, more tasks delegated. We think the focus belongs somewhere else. Reliability, reproducibility, auditability, not as constraints on capability, but as the foundation that makes capability trustworthy enough to actually deploy in places that matter.