The Reproducibility Infrastructure Delaware AICs Will Need

Today Delaware announced it's opening a legal doorway for a new kind of business entity: the artificial intelligence company. An AIC — an entity run autonomously by AI agents — as a first-class member of American corporate law.

Norm Ai is leading the public-private partnership to draft the framework. The Fortune piece is the shot heard around startup Delaware.

The story is real and the shift is significant. What the announcement doesn't spell out — because it can't yet — is the piece that has to exist for the framework to actually function once real companies use it: the reproducibility infrastructure that turns an AIC's decisions into legally defensible evidence six months, six years, or six decades after the decision was made.

Every AIC decision becomes an evidentiary artifact.

Every AIC decision has to reproduce.

Most AIC-adjacent tech stacks don't reproduce, and the vendors selling into the AIC world are about to run into that gap at speed.

---

What breaks if reproducibility is treated as optional

The AIC framework is designed for a jurisdiction that already runs the majority of U.S. corporate law. That jurisdiction's authority rests on one boring civic infrastructure: records. You can, right now, walk into the Delaware Court of Chancery and produce the exact minutes of a board meeting from 1997. Or the exact term sheet from a 2003 seed round. Or the exact wire authorization from a 2015 acquisition. Not summaries. Not paraphrases. The actual record, verifiable, dated, signed.

That's the standard the AIC will be held to. When claim, audit, litigation, or opposing counsel comes for an AIC six months after the decision they're contesting, the answer "well, we ran an agent, it did some things, we don't have the exact input+output+state that produced the decision" will not be a defensible answer in a Delaware courtroom.

A human-run company that lost the meeting minutes has civil exposure. An AI-run company that lost the agent trace has the same exposure — worse, because the agent replaced the humans whose testimony would have partially reconstructed the record.

Reproducibility isn't a technical nice-to-have for AICs. It's the load-bearing requirement that makes the entity type legally coherent at all.

The five reproducibility layers every AIC will need

The AIC framework will eventually — either through statutory rule, through case law, or through market-driven due-diligence standards — require entities to demonstrate reproducibility across five distinct surfaces. Each is a source of drift that current AI-agent stacks handle poorly by default.

1. Model version pinning

gpt-4 today is not gpt-4 from six months ago. Providers silently update weights, refresh training data, swap variants under the same API name. An AIC that authorized a payment on 2026-03-14 based on gpt-4's recommendation is not, in 2026-09-14, going to be able to re-run that call against the same model to reproduce the reasoning — the model is functionally different.

The AIC will have to pin to date-versioned endpoints (gpt-4-0613, claude-3-5-sonnet-20241022, etc.) and log the resolved version on every call. When providers eventually sunset the pinned versions, the AIC's retained OUTPUT record becomes the sole evidentiary artifact for the pre-sunset period.

This is not hard engineering. It's just unglamorous engineering that most AIC-focused vendors haven't budgeted for.

2. Prompt and configuration versioning

Every system prompt, RAG chunking config, tool description, and template preamble the AIC uses is a functional part of the decision. Change any of them silently — as almost every AI startup does on almost every sprint — and reproducibility of pre-change decisions is broken.

The AIC has to version its own operating configuration as code, log the exact version identifier alongside every decision, and retain the full config history for the audit horizon. In corporate governance terms, this is analogous to retaining the exact bylaws in effect on the date of any decision — trivially obvious for humans, systematically missed by AI stacks.

3. Tool-call trace as primary artifact

Most AICs will use tools — pay a vendor, query a database, sign a document, execute a trade, file a form. Each tool call is a step in a decision sequence, and the sequence itself is what produces the outcome.

Reproducing "the reasoning" of an AIC decision means reproducing the entire tool-call trace: which tools fired, in what order, with what inputs, returning what outputs, feeding into what next-step decision. A summary of the final output is not the record. The trace is the record.

A trace-free AIC is functionally equivalent to a corporate entity that shredded its meeting minutes and kept only the resolutions. Insufficient for any regulator you'd bring to court.

4. Cache determinism and provenance

Every response cache, embedding cache, RAG chunk cache, and semantic memory layer in the AIC's stack creates an asymmetry: cache-hit decisions are deterministic (same input, same cached value returned); cache-miss decisions are not (fresh model call, provider variance applies).

An AIC has to distinguish, in its own records, which decisions were cache-served vs. model-generated. Otherwise "reproduce this decision" becomes a probabilistic exercise where the AIC honestly doesn't know whether it's replaying the original computation or re-computing from scratch with different results.

Bonus: some caching architectures leak state between tenants. When the AIC serves multiple counterparties or is one of several AICs sharing infrastructure, the audit-of-record has to demonstrate cache isolation. Data privacy law dressed up as a reproducibility question.

5. Independent output-of-record retention

The temperature=0 conversation is a red herring. Even greedy decoding is not bit-deterministic across GPU implementations or provider infrastructure. Trying to reproduce the model's exact bytes from the input in 2026-09 what was produced in 2026-03 is unreliable by design.

The workable posture is different: the OUTPUT itself becomes the record of truth for that decision, retained verbatim, immutably, for the full audit horizon. Reproducibility becomes a records question — can the AIC produce the exact output it emitted, the exact input that produced it, and the exact configuration/version metadata that framed the call — rather than a determinism question.

This is boring. It works. Most AICs will not build it until their first evidentiary problem lands, and by then it's expensive.

Who audits the AIC?

The Delaware announcement is silent on the enforcement layer, which is where the interesting work is going to happen.

The plausible answers, ranked by likelihood of being where the market lands:

• Traditional Big Four audit + AI-specialist consultancies — will absorb the AIC reproducibility audit into existing SOC 2 / ISO 27001 / financial-audit workflows. This is where the volume goes. Kevin's read: the Big Four will not build native tooling for this; they will subcontract to specialists.
• Insurance carriers — will require reproducibility attestation as a condition of writing D&O policies on AICs. This will drive faster adoption than statutory rule, because uninsured AICs won't attract capital. Kevin's read: the E&O and D&O policy language for AICs is being drafted right now in the same offices that write cyber policy — probably by the same people.
• Regulator-driven audit — SEC, FTC, state AGs, and CFPB will all have opinions once an AIC screws up publicly. The first regulatory enforcement action against an AIC — for consumer harm, for financial-manipulation, for civil-rights adverse-impact — will define the audit standard by case law before any statutory rule catches up.
• Counterparty due diligence — every other company doing business with an AIC will start asking, in their MSAs, for reproducibility attestations. The AIC's ability to answer those RFPs will materially affect deal flow.

Whichever mechanism lands first, the AIC that has independent reproducibility infrastructure in place will pass audit, insurance underwriting, and counterparty DDQ processes faster than the AIC that promises to build it later.

The specific question every AIC counterparty will ask

Here is the follow-up question that will appear, verbatim or paraphrased, in every MSA negotiation, every insurance carrier's E&O questionnaire, every regulator's investigative subpoena, and every Court of Chancery discovery request:

"Reproduce the AIC's decision on [transaction X / disclosure Y / commitment Z] from [date], including all inputs, outputs, tool-call traces, model versions, and configuration state as they existed at decision-time."

The AIC's ability to answer this question with something concrete — not "well, our agents are stochastic" — is the AIC's operational insurance policy.

An AIC that cannot answer it is an entity that is either (a) about to be exposed at the first adversarial process, or (b) about to spend a very expensive quarter retrofitting reproducibility infrastructure under regulatory duress.

The former is a governance failure. The latter is a market opportunity for the vendors building the infrastructure now.

What founders building for the AIC world should instrument today

If you are building a product that will be used by an AIC, or is intended to be an AIC's own decision-making infrastructure, the checklist is short and boring:

1. Pin all model versions to date-versioned endpoints; log the resolved version on every call.
2. Version every prompt template, RAG config, and tool description as code; log the version on every call.
3. Log the full tool-call trace as the primary audit-of-record artifact.
4. Log cache hit/miss status on every call.
5. Retain the exact input + output + configuration + version metadata on every decision, immutably, for the full anticipated audit horizon (at minimum 7 years for D&O-adjacent decisions, longer for HIPAA/HITRUST/regulated-industry AICs).

These five don't require deep engineering. They require deciding, right now, that the reproducibility posture is a first-order design constraint rather than a Q3 tech-debt line item.

The AICs that treat reproducibility as design-constraint will move through Delaware formation, insurance underwriting, and counterparty due-diligence faster than the AICs that don't.

What Delaware doesn't have to write into the framework — and shouldn't

The right form of this evolves through market-driven standards more efficiently than statutory rule. Delaware Secretary of State's office does not need to prescribe cache-invalidation policy in the AIC statute. What it needs to establish is the principle that AICs are, like every other legal entity in Delaware, held to a records standard sufficient to support evidentiary process. The technical implementation gets to evolve.

This is exactly the pattern Delaware used for corporations, LLCs, LPs, series LLCs, benefit corporations, and every prior form. Establish the principle. Let the market build the tooling. Let case law refine the boundary.

The AIC framework should — and, Kevin bets, will — do the same for AI-decision reproducibility. And the market work of building that infrastructure is what the next few years look like.

The scoreboard question for AIC founders

Every founder considering AIC formation, or building AIC-adjacent infrastructure, should be able to answer, out loud, today:

• What percent of the AIC's production decisions are you able to reproduce with a bit-for-bit output match?
• What percent are you able to reproduce with a defensible-records match (input + output + version + config + trace, verbatim)?
• What is the audit horizon you're retaining, per decision-class?
• Who signs, personally, on the reproducibility attestation your counterparties are going to require in Q2 2027?

If the answers are hedges, the AIC formation is premature. If the answers are numbers, the AIC is one of the ones that survives its first adversarial process.

The uncomfortable move is putting the actual numbers on the table before Delaware asks.