In Practice: Building an AI Company | Lesson 7: The Cost Model Is the Business Model

The first model provider invoice arrived itemized by day. Thirty-one rows, most of them small, four of them not. The four large ones corresponded to days when we had been testing, which is to say to days when nobody was using the product at all.

What struck me was not the amount, which was trivial. It was the shape. This was a bill that moved with activity, and every previous software bill I had ever seen was a bill that moved with the calendar.

That difference is the whole subject. It is the reason an AI company is not a software company with a model attached, and it is the line item that quietly decides what business you are in.

Inference is cost of goods sold

Classic software runs at eighty to ninety percent gross margin because it is built once and the cost of serving the next customer rounds to nothing. Hosting is largely fixed and spreads across a growing base. That single fact produced two decades of business models, valuation multiples and hiring plans.

An AI product cannot do that trick. Every request spends real money. The marginal cost of the next customer is not near zero, it is a function of how much they use you.

The numbers now in circulation are consistent across sources and worth committing to memory. AI product gross margins are landing in the fifty to sixty percent band rather than the eighty to ninety percent band. One widely cited 2026 survey of several hundred software executives put the average AI product gross margin at 52 percent, up from 41 percent in 2024. Model inference accounted for somewhere around twenty to twenty-three percent of total AI product cost.

Read that last figure carefully, because the direction is the surprising part. Inference share rises as products mature. It does not fall. The intuition from classic software, where unit cost decays as you scale, is exactly inverted. You succeed, usage deepens, cost of goods grows as a proportion of the total.

A founder who assumes the old curve will build a plan in which margin improves automatically with scale. It does not. It improves with engineering, or it does not improve.

Cost per query, and why it is a weekly number

There is one metric that should be on a wall. Total inference spend for the period divided by requests served in the period.

Track it weekly, not monthly, because monthly is slow enough that a bad change ships, propagates and becomes normal before anyone notices. Early-stage products commonly sit anywhere from a fraction of a cent for a lightweight completion to fifteen cents or more for a multi-step agent run that calls tools and reasons across several turns. The spread across that range is enormous and it is entirely determined by choices you make.

When the number rises, there are only two explanations and both are worth knowing about immediately. Either you shipped a more capable feature without optimizing the path underneath it, or the amount of context being consumed per task has grown, usually because somebody added history, retrieved documents or examples to a prompt and it helped.

Neither is wrong. Both are decisions, and a decision you did not know you made is the one that shows up as a margin problem two quarters later.

The levers, in order of size

Routing. This is the largest lever by a wide margin and the one most teams reach for last. Within a single provider’s lineup the price spread between the cheapest capable tier and the most expensive frontier tier commonly runs five times or more per token. Most requests in most products do not need the top tier. Classify the incoming request, send the routine majority to the cheap tier, reserve the expensive one for the cases that genuinely need it, and measure quality on both. Teams that do this well route the large majority of traffic to inexpensive models and see no user-visible degradation.

Caching. Repeated context, whether system instructions, retrieved documents or conversation prefixes, does not need to be paid for at full rate every time. The mechanisms differ by provider and the savings on a workload with stable context are large enough to change the shape of a P&L.

Context discipline. The cheapest token is the one you never send. There is a common pattern where a retrieval step returns twenty documents, all twenty go into the prompt because it is easier, and three of them were relevant. Retrieval quality is a cost lever disguised as a quality lever.

Batching and asynchronous processing. Where the user is not waiting, work that runs on a delayed queue is materially cheaper. A surprising proportion of what teams build synchronously does not need to be.

Self-hosting. Last, deliberately. There is a crossover point where running your own inference beats paying per token, and it exists, but it arrives at volumes higher than most early companies reach and it brings an operational burden that a team of six should think hard about accepting. Do the arithmetic before the conversation, not during it.

Model three futures, not one

Unit prices for inference have fallen dramatically. Capability that cost roughly twenty dollars per million tokens from a frontier model in late 2022 was available at a small fraction of that by early 2026. Hardware rental rates for the relevant accelerators fell substantially across 2025 as well.

It is tempting to plan on that continuing. Do not plan on it exclusively. Build three scenarios.

In the first, prices keep falling at roughly ten percent a quarter and today’s fifty percent gross margin drifts toward seventy without you changing your pricing. That is the optimistic case and it is genuinely plausible.

In the second, prices hold flat. Your margin is whatever your engineering makes it.

In the third, your cost per unit of work rises even as token prices fall, because you shipped more capable features and the number of tokens consumed per completed task grew. This has been the actual experience of a lot of teams. Token consumption per task has risen by one to two orders of magnitude since late 2023 as products moved from single completions to multi-step reasoning with tool use.

If the business only works in the first scenario, that is important information and it is available today rather than in eighteen months.

Three ways this goes wrong

You put inference in operating expenses. It sits in cost of goods sold. Booked as an operating cost it disappears into a line with the design tool subscription, your reported gross margin becomes fiction, and you will not discover the error until somebody in diligence asks a question you cannot answer.

You measure the average and ignore the distribution. Usage in these products is heavily skewed. A small number of users generate a large share of consumption. An average cost per customer that looks healthy can conceal a handful of accounts that are individually unprofitable, and on a flat rate plan those are the accounts most likely to renew enthusiastically.

You optimize before you measure. The instinct to cut costs early is good and it is frequently spent in the wrong place. Instrument first: cost per request, per customer, per feature. Then optimize the thing that is actually large, which in my experience is almost never the thing anyone guessed.

In AI you do not discover your margin at year end. You design it at the start, or somebody else designs it for you.

Monday: the pricing page, and the rule that stops your best customer becoming your worst one.

In Practice: Building an AI Company | Lesson 6: The Wedge

The exercise took forty minutes and it was the worst forty minutes of that month. Write down ten companies that will buy this. Real ones, with names. Next to each one, write the job title of the person who signs, and how you get in front of them this week.

We managed four. Two of those were companies where somebody in the room knew somebody, which is a route to a meeting rather than a route to a market. The other six lines stayed empty for two days while we quietly moved on to more comfortable work.

Ten names on a whiteboard is a brutally efficient diagnostic. If you cannot fill it in, you do not have a segment. You have an adjective.

A market is not a segment

Small and medium businesses is not a segment. It is roughly thirty million companies in the United States alone, sharing nothing except a headcount band. Financial services is not a segment. Operations teams is not a segment.

A segment is a group where you can do three things. Name ten members without research. Describe how a purchase actually happens inside them, including who objects. Reach all ten within a week using channels you already have.

Everything failing those three tests is a category, and categories are useful for describing a business after it works. They are useless for finding the first customers, because you cannot send an email to a category.

The reason this matters more than it used to is that the cost of building the second product has collapsed while the cost of earning the second customer has not. A small team can now ship a startling amount of software. What it cannot do is be credible to eleven different kinds of buyer at once, and credibility is now the scarce input.

The wedge test

A wedge is narrow enough that you are not a choice, you are the obvious choice. If a buyer has to compare you against three alternatives on a feature grid, the wedge is too wide.

There are three dimensions to narrow along, and most teams only use the first two.

Who. Role, industry, size, and increasingly the regulatory regime they operate under. A company that must keep data inside a particular jurisdiction is a different buyer from one that does not, regardless of what they do.

What job. Not what department. A specific recurring task with a name the buyer already uses. If you have to teach them the name of the job before you can sell them the solution, you have added a step you will pay for in every conversation for two years.

What trigger. This is the underused one. What event causes somebody to look for this today rather than in eighteen months? A new regulation with a compliance date. An audit finding. A person leaving. A volume threshold crossed. A system being retired.

Products sold without a trigger are sold on the buyer’s timeline, which is indefinite. Products sold into a trigger are sold on the trigger’s timeline, which has a date on it. When founders describe a long sales cycle, the diagnosis is usually not the cycle. It is the absence of a trigger.

Design partners, and the pilots that go nowhere

The first handful of customers are not customers in the ordinary sense. They are design partners, and the relationship needs to be structured or it decays into unpaid consulting.

A design partner gives you access to real workflows, real data conditions, and honest feedback from people doing the actual job. In exchange they get influence over what gets built and a price that will not be repeated. What they should not get is the product for free, and this is the point most founders concede too easily.

Free is not a discount, it is a different product. A free pilot is evaluated by whoever has spare time. A paid pilot, even at an almost symbolic amount, requires somebody to sign something, which requires somebody to care whether it works. The signature is the signal, not the money.

This matters because the graveyard is well documented. Research through 2025 and into 2026 has repeatedly found that only a small fraction of enterprise AI projects, on some measures around one in twenty, ever reach production. The pilots do not fail because the technology disappoints. They stall because nobody owned the transition from interesting to operational, and no budget line existed for the second year.

So structure the thing. Three components, written down: what you will deliver and by when, what they will provide including data access and the hours of the person who knows the workflow, and a date on which it either becomes a real contract or ends. Pilots without an end date do not end. They fade, and you find out four months later from somebody’s out of office reply.

Why narrow wins in AI specifically

Focus has always been good advice. In this category it is closer to a structural requirement, for three reasons.

Evaluation is domain specific. You cannot build a meaningful test set for everyone. You can build one for invoice exceptions in a particular industry, and that test set is what lets you ship changes without breaking customers. A wide product cannot be evaluated, which means it cannot be improved with confidence, which means it degrades.

Data only compounds under repetition. The asset described in Lesson 5, the record of what was accepted, corrected and eventually proved right, only becomes valuable when the same shaped task recurs thousands of times. Spread across eleven use cases it is a pile of unrelated logs.

And accountability requires competence. If part of what you sell is standing behind the output, you have to understand the domain well enough to know when the output is wrong. That is not a claim you can make across four industries with a team of six.

Three ways this goes wrong

You widen after the first rejection. A prospect says no, and the instinct is to conclude the segment is wrong rather than the pitch. Widening feels like progress and is usually retreat. Ten rejections in one segment is data. One rejection in each of ten segments is noise.

You pick the segment you can reach instead of the one that has the problem. Access is a real advantage and it is not a substitute for need. Selling into your former industry because you have the contacts, when that industry does not actually have the problem acutely, produces a year of very friendly meetings.

You let the first large logo redefine the product. A big name arrives with requirements attached. Some of those requirements are the market speaking. Most are that company speaking. Distinguishing between the two is the single hardest judgment of the first year, and the test is whether the other nine names on the whiteboard would want the same thing.

You cannot be chosen by a market, only by a customer, so pick customers you can name.

Tomorrow: the first model provider invoice, and the line item that decides your business model.

In Practice: Building an AI Company | Lesson 5: Decide What You Sell Before You Decide What You Build

We rewrote the one-page product definition eleven times. I know it was eleven because the file names went to eleven, and because somewhere around the seventh I stopped believing we would ever finish it.

Version one described a technology. It used the word platform twice and named three model capabilities. It was accurate and it was useless, because it did not say what anybody would stop doing if they bought it.

Version eleven described a job. Who does it today, how long it takes them, what goes wrong when it goes wrong, and what the company takes responsibility for. It was shorter, less impressive to read aloud, and it was the first version an engineer could build against and a salesperson could sell from.

The Monday test

There is one question that should be asked before any serious money or time is committed, and it is uncomfortable enough that most teams avoid it until an investor asks it for them.

If the model provider shipped your headline feature natively on Monday, what would you still have?

Not what would you do. What would you still have. The answer is usually one of five things, and only four of them are a company.

The fifth answer, the one that is not a company, is: a better interface. Interfaces are real work and they are genuinely valuable, but they are also the layer that gets absorbed first, because the party whose feature you are wrapping has every incentive to wrap it themselves and a much lower cost of doing so.

It is worth saying plainly that wrapper is not an insult. Every application in history is a wrapper around something: a database, an operating system, a payment network. The question was never whether you wrap. It is whether the wrapping is the part that carries the value.

The four places value actually sits

Workflow depth. The product does not answer a question. It completes a job that has steps, state, handoffs and an approval somewhere in the middle. A model answers. A workflow remembers what happened last Tuesday, knows who has to sign off, and behaves correctly when somebody is on holiday. That accumulated correctness is not something a raw capability replaces, because the capability was never the hard part.

The test is simple. Can a user get most of the value by pasting their problem into a general purpose assistant? If yes, you are selling convenience. Convenience is a real business and it is a thin one.

Data you accumulate by operating. Not data you licensed, which your competitor can also license. Data that exists only because your product ran: which suggestions were accepted and which were rejected, what the correction was, what the outcome turned out to be six weeks later. This is the asset that compounds, and it is the one most teams forget to capture because capturing it is not on the critical path to the demo.

Decide on day one what you log. It is nearly free to record and impossible to backfill.

Integration surface. Work happens where work already lives. A product that reaches into the systems of record, reads the real state, and writes back is doing something a general capability cannot do without the same integration work. That work is unglamorous, slow, and it is a moat precisely because it is unglamorous and slow.

Accountability. This is the least discussed and it may be the strongest. Model providers are explicit that output correctness is not guaranteed. Somebody has to stand behind the result. When you sell into a function that has consequences, whether financial, clinical, legal or operational, a large part of what the customer is buying is that a company exists which will answer for the output being wrong.

That has a cost. It means evaluation, monitoring, human review paths and insurance. It is also the reason a serious buyer will pay you rather than use a general tool that is free to them, and it is not a position an interface can occupy.

Write down what you are not

The most useful half of a product definition is the exclusions.

A definition that only says what you do will be stretched by every customer conversation, because saying yes is pleasant and saying no is not. Six months later you have four half-products, a roadmap nobody believes, and an engineering team that has stopped asking what the priority is because the answer keeps changing.

The working test for a product definition is this: can somebody on your team decline a customer request without asking you? If they have to ask, the definition is a description rather than a decision, and you are the bottleneck on every conversation the company has.

Write both columns. What this does. What this does not do, and where those requests go instead. Put a date on it and revisit it deliberately rather than continuously.

Three ways this goes wrong

You build the demo that impresses other builders. There is a specific kind of demo that gets applause from engineers and produces no purchase orders. It shows capability rather than completion: look what it can do, rather than look what it finished. Buyers do not buy capability. They buy the absence of a problem they currently have, and the demo that sells is often visually dull because it ends with a task being finished and a person going home.

You define the product as a capability rather than a job. Any sentence of the form we use artificial intelligence to improve something is not a product definition. It contains no user, no current alternative, and no way to tell whether it worked. Rewrite it as: this person spends this long doing this thing, it goes wrong in this way, and afterward they do not have to.

You confuse novelty with demand. That nobody else does this is not evidence that anybody wants it. Sometimes it is evidence that several people tried and discovered why not. When you find genuinely empty space, spend a day asking who else has stood here before assuming you are the first to arrive.

The eleven versions were not wasted, although at the time it felt like avoidance. Each rewrite removed something we had been carrying because it was impressive rather than because it was true. What was left was smaller than what we started with and considerably harder to argue with.

A feature is not a company. A workflow somebody is afraid to change is.

Tomorrow: the ten-name customer list, and why a market is not a segment.

In Practice: Building an AI Company | Lesson 4: The Cap Table You Can Still Raise On

Our first cap table was a spreadsheet with nine rows. Founders, a placeholder for an option pool nobody had modeled, and a note at the bottom in a different color reminding us to add the advisor we had promised something to but had not yet quantified.

It fitted on one screen. That was the last time it did.

A cap table looks like a record of who owns what. It is not. It is a forecast of who will own what once everything you have already promised comes true, and the gap between those two readings is where founders lose companies they still technically control.

Outstanding versus fully diluted

There are two numbers for every line and they are rarely the same. Outstanding shares are what has actually been issued. Fully diluted includes everything that could become a share: the unissued option pool, outstanding options, warrants, and every convertible instrument you have signed.

Founders quote outstanding. Investors read fully diluted. The number that matters in every negotiation you will ever have is the second one, so start using it now, and build the model yourself rather than accepting somebody else’s summary. Not because anyone is dishonest, but because the person who built the model understands the assumptions inside it, and in a negotiation that understanding is the entire advantage.

The option pool and where it comes from

You need equity to hire. A pool of ten to twenty percent is standard, sized against the hiring plan for the next eighteen months rather than against a number somebody quoted.

The part that surprises people is when the pool gets created. Investors almost always require it to be established before their money goes in, which means it comes out of the pre-money valuation. In practice that means the founders pay for it entirely, and the arithmetic is not intuitive.

Take a round of three million dollars on a fifteen million pre-money valuation. Post-money is eighteen million, so the new investors hold one sixth of the company, about 16.7 percent. Now add a fifteen percent option pool created pre-money. That fifteen percent is fifteen percent of the post-money company, and it is carved entirely out of the existing holders. The founders do not end up with 83.3 percent minus a bit. They end up with roughly 68.3 percent, and the fifteen points went somewhere they had not modeled.

This is not a trick and it is not hidden. It is standard practice and it is negotiable at the margin. What is not acceptable is being surprised by it on the day the term sheet arrives, because a founder who is doing this arithmetic for the first time in a meeting has already lost the argument about pool size.

SAFEs, and the trap in the word post-money

Most early money now arrives as a simple agreement that converts into equity later, usually at a valuation cap. It is fast, cheap and lawyer-light, which is why it won. It also defers the moment anybody has to think, which is why it hurts.

The critical detail is whether the cap is pre-money or post-money. Under the post-money version, which is now the common one, the investor is promised a fixed percentage of the company as it stands at conversion. That percentage does not dilute when you issue the next instrument. Only the founders dilute.

Work it through. You raise one million dollars on a ten million post-money cap. That investor is promised ten percent. Six months later you raise another million on a twelve million post-money cap. That investor is promised 8.33 percent. The first investor still gets their ten percent. The founders now hold 18.33 percent less than they did, before any priced round, before any option pool, and before anyone has valued the company in a negotiation.

Three or four of these stacked up is common, and the result is a founding team that discovers at their first priced round that they collectively hold less than half of their own company and have no idea when it happened. The instrument did not do anything unfair. Nobody modeled the conversion.

So model the conversion. Before you sign each one, build the row where all outstanding instruments convert at a plausible next round, add the pool, and look at what the founders hold. If that number makes you uncomfortable, the time to act is before signing, not after.

The small grants that add up

The large numbers get scrutiny. The small ones get waved through, and collectively they do more damage because nobody is tracking the total.

  • Advisors. The market range is roughly a quarter of a percent to one percent, vesting over one or two years, with a defined commitment such as a monthly call. Anyone requesting five percent for advice is not an advisor. Vesting matters here more than anywhere else, because advisor engagement reliably decays.
  • Agencies and contractors taking equity instead of cash. This is attractive when cash is short and it is almost always expensive. You are selling the most valuable asset you have at the lowest price it will ever carry, to a party whose involvement ends when the project does.
  • Uncapped notes from friends and family. Well intentioned, and they convert at whatever the next round decides, which means the person who took the earliest risk gets the worst terms. That produces a conversation you will not enjoy.
  • Verbal promises. A percentage mentioned in a conversation and never documented is not on the cap table, but it is absolutely in somebody’s head. Those surface during diligence, always at the worst moment.

Three ways this goes wrong

You keep the cap table in a spreadsheet past the point where that works. It works for about a year. It stops working the first time somebody exercises an option, or a note converts, or a founder departs mid-vest. Move it to a proper register before it breaks, not after, because reconstructing a cap table from email is a genuinely awful week.

You optimize for a headline valuation instead of a clean structure. A high cap feels like a win and costs nothing today. The bill arrives when the priced round has to reconcile every instrument you signed. Investors are not primarily buying your valuation history. They are buying whether the founders still own enough to stay motivated for another four years, which is the actual question behind every diligence request about the cap table.

You treat dilution as loss. It is not. Owning a smaller share of a company that exists beats owning all of one that does not. The failure is not dilution, it is unmodeled dilution, which is the same mistake as unmodeled cost and produces the same expression on the same face eighteen months later.

Every early act of generosity gets priced by the next investor, and they price it against you.

Tomorrow: the one-page product definition, and the question that decides whether you have a company or a feature.

In Practice: Building an AI Company | Lesson 3: The Founder Agreement Is the First Product You Ship

The founder agreement was the fourth or fifth document we produced and the first one anybody was reluctant to open. It is a strange thing to write. You sit in a room with people you chose, whose judgment you trust enough to bet several years of your life on, and you write down what happens when one of you leaves and the rest of you resent it.

Nobody enjoys the conversation. Everybody who has skipped it has regretted it.

The agreement is not a legal formality wrapped around a friendship. It is the first thing the company builds, and like anything you build, it is either designed for the conditions it will actually meet or it is decorative.

Vesting is a promise to your future self

The standard shape is four years with a one year cliff, then monthly. Nothing vests for the first twelve months. At month twelve a quarter of the grant vests at once. After that it drips.

Founders resist applying this to themselves. The reasoning is always some version of: we are the ones building it, why would we restrict our own stock. The answer is that vesting is not protection against you. It is protection against the version of this company that exists after somebody leaves.

Run the scenario. Five people split the company evenly. In month seven one of them takes a job somewhere else, for reasons that are entirely understandable and possibly medical. Without vesting they walk away owning a fifth of the company, permanently, with no further obligation to anyone. The four people who remain now work for four more years knowing that twenty percent of everything they build accrues to somebody who left before the product existed. That is not a legal problem. It is a motivation problem, and it will not resolve.

With vesting, the same person leaves in month seven having crossed no cliff and keeps nothing. That sounds harsh in the abstract and it is exactly right in practice, because the alternative punishes the four people who stayed.

Two refinements worth understanding. Acceleration on a change of control determines what happens to unvested stock if the company is acquired. Single trigger accelerates on the acquisition itself, which acquirers dislike because it means the people they are buying can leave immediately. Double trigger accelerates only if the acquisition happens and the person is terminated, which is the market standard and the one you should default to. The other refinement is credit for time already served. If you have been working on this for a year before incorporating, it is normal to vest a portion at signing rather than pretend the year did not happen.

The election with a thirty day window

If your stock is subject to vesting, there is a tax election you must file within thirty days of the grant. Thirty calendar days. There are no extensions and there is no relief for not having known about it.

The mechanics matter, so here they are plainly. Restricted stock is normally taxed as it vests, at the value on each vesting date. In a company that is going well, that value rises. So you would recognize ordinary income every month, on stock you cannot sell, in a company with no liquid market, and you would owe real tax in cash on paper gains. Founders have been genuinely ruined by this.

The election lets you choose to be taxed at grant instead, when the stock is worth close to nothing. You pay tax on approximately zero, and everything afterward is capital gain rather than ordinary income. It also starts the clock for the qualified small business stock holding period discussed in Lesson 1, which is a second reason it belongs on day one rather than day thirty-one.

The cost of filing it when you did not need to is a stamp. The cost of not filing it when you did need to is uncapped. Treat it as unconditional.

The intellectual property, including the part from before the company existed

Here is the uncomfortable default: work belongs to the person who did it unless there is a written assignment. Not to the company they were thinking about forming. Not to the group chat where the idea was discussed. To the individual.

That means the prototype somebody built in the two months before incorporation, the model evaluation harness, the brand name, the domain, the pitch deck and the schema all sit outside the company until they are formally assigned into it. Investors check this. Acquirers check this harder. A single unassigned component discovered during diligence can hold up a transaction for weeks while lawyers chase a person who has since stopped answering email.

Two related traps. The first is employment agreements at day jobs, many of which claim inventions made during the employment period, sometimes regardless of whether company equipment was used. If any founder built anything material while still employed elsewhere, that needs a real answer, ideally a written release, before it becomes somebody else’s leverage. The second is the helpful friend. Somebody who contributed a weekend of work, was thanked warmly, was never paid and never signed anything, now holds a copyright interest in part of your product. Get a short assignment signed at the time. It is a one page document and it costs a favor.

The parts everyone skips

The equity terms get attention because they are about money. The following clauses get skipped because they are about behavior, and they are the ones that actually determine whether the company survives its second year.

  • Roles and decision rights. Not job titles. A written statement of what each person can decide alone, what needs agreement, and what needs everyone. Without it, every disagreement escalates to a vote, and a company that votes on things moves at the speed of its slowest conversation.
  • What full time means, and when it starts. Founders frequently have different runway, different obligations and different tolerance for risk. Some are in on day one, others in four months. Write down which, and tie the equity to it, because the unspoken version of this is the most common source of resentment I have seen.
  • Departure mechanics. What happens to unvested stock, to vested stock, to the title, to the email address, to the customer relationships that person owned. Decide it now, when nobody is angry.
  • Deadlock. An even number of founders needs a tiebreak rule. An odd number needs one too, once somebody leaves.

Three ways this goes wrong

You split evenly because it is the polite thing to do. An even split among a large founding team is often the right answer, and it is just as often the answer nobody wanted to argue about. If contributions and commitments differ materially, an even split encodes a disagreement rather than resolving it. Have the conversation while it is still cheap.

You agree it verbally and mean it sincerely. Verbal agreements between friends are perfectly genuine and completely unenforceable. They also drift, because two people remember the same conversation differently after eighteen difficult months. The document is not there because you distrust each other. It is there so that the version of you in month twenty does not have to reconstruct the version of you in month one from memory.

You defer it until the first raise. By then it is not a negotiation among peers, it is a condition imposed by a term sheet in a week when you have no leverage and no time. Every founder who has done it this way describes the same feeling.

Equity is easy to give and impossible to take back.

Tomorrow: the cap table, and what your early generosity looks like to the person writing the next check.

In Practice: Building an AI Company | Lesson 2: What It Costs to Stay Alive Before You Sell Anything

The first invoice the company ever received was from the registered agent. It was for a small amount, it arrived by email with no covering note, and it was addressed to an entity that had no product, no customers, no bank account and no revenue. We had been a company for eleven days.

I remember looking at it and thinking that it was a rounding error, which it was, and then thinking that it would arrive again next year and the year after that whether or not anything else went well. Which it will.

That invoice is the beginning of a category of spending most founders never model: what it costs simply to exist. Not to build anything. Not to serve anyone. Just to remain a company in good standing that has not been administratively dissolved.

The standing costs

There are five of them and they are all boring, which is why they get missed.

The registered agent. Every US entity needs a registered agent with a physical address in the state of formation, available during business hours to receive legal service. If you have no US address you cannot be your own. This is an annual fee and it is the one bill that arrives whether or not you do anything.

Franchise tax. For a Delaware LLC this is a flat annual amount due on 1 June, which is refreshingly simple. For a Delaware corporation it is not simple, and this is where founders get their first genuinely alarming letter. There are two calculation methods. The default one is based on authorized shares, and a company that has authorized ten million shares receives a number that looks like a mistake. The second method takes account of issued shares and gross assets and typically produces something far smaller for an early-stage company. Both are legitimate. You pay the lower one. Nobody tells you this in advance.

The employer identification number. Free to obtain, but if no founder has a US social security number you cannot use the online process. You file the application by fax or mail and you wait, sometimes for several weeks. Nothing else can proceed without it, so this is the item that should be started on day one rather than day forty.

A bank account. This is consistently the hardest step for a founding team based outside the United States, and it is the one that blocks everything else. You will need the formation documents, the employer identification number, identification for the beneficial owners, and usually a plausible answer about what the business does and where its customers are. Budget months, not weeks. Plan around it rather than assuming it.

Accounting and tax preparation. A US entity files a return whether or not it earned anything. Zero revenue does not mean zero filings, and a preparer who understands foreign-owned entities is not the cheapest one available.

The filings that carry real penalties

Most of the annual obligations are small in money and irritating in effort. Two are neither.

The first is the information return required of a foreign-owned single-member LLC, filed alongside a pro forma corporate return. It reports transactions between the entity and its foreign owner. It is not a tax calculation and often results in no tax at all. The penalty for not filing it is twenty-five thousand dollars. That number is not a typo and it is not scaled to the size of the company. Founders who form an LLC precisely because it seemed like the light option are the ones most likely to be unaware this exists.

The second is the corporate income tax return itself, which is due regardless of activity. A dormant company still files. Filing late compounds, and the first year of a startup is exactly when nobody is watching a calendar.

Then there are the deadlines, which do not move for you. Delaware corporations file their annual report and franchise tax by 1 March. Delaware LLCs pay by 1 June. If you have registered as a foreign entity in another state because that is where you actually operate, that state has its own report, its own fee and its own date. Put every one of them in a shared calendar with a reminder two weeks ahead, because the person who remembers in year one will be busy in year two.

Three layers of cost, and why you should separate them

The useful move here is to stop treating spending as one number and split it into three, because they start at different moments and behave differently under growth.

Cost to exist. Registered agent, franchise tax, accounting, filings. Fixed, annual, unavoidable, starts on the day you file. It does not care about revenue and it does not scale with users. For a lean single-entity structure this lands in the low four figures a year, more if you have qualified in a second state or your ownership structure needs specialist tax work. Write the real number down. It is the amount you must be able to cover in a year where nothing happens.

Cost to operate. Domain, email, code hosting, error monitoring, the design tool, the thing that sends transactional email. Starts when you begin building and grows with the team rather than with the customers. Most founders track this one because the bills are monthly and visible.

Cost to serve. Inference, storage, egress, anything metered per request. Starts when someone uses the product and scales with success rather than with headcount. This is the layer that makes an AI company different from a software company, and it is the subject of Lesson 7. For now the only thing that matters is that it is a separate line, because if you blend it into operating cost you will never be able to answer the question of what a customer costs you.

Three layers, three behaviors. The first is a floor. The second is a choice. The third is a consequence.

Three ways this goes wrong

You budget formation as a one-time cost. The filing fee is one-time. Everything else recurs, and it recurs in a year when there is no revenue to absorb it. A company that raised nothing and earned nothing can still be dissolved for not paying a few hundred dollars on time, which is an embarrassing way to lose a name you have been using for eighteen months.

You optimize the wrong end. Founders will spend two weeks comparing formation services to save a hundred and fifty dollars, then miss an information return that carries a twenty-five thousand dollar penalty. The formation is the cheap part. The maintenance is the part with the sharp edges.

You sequence the bank account last. It is the longest lead item and the one you control least. Everything else can be done in an afternoon. If you leave it until you need to receive money, you will be explaining to your first customer why you cannot invoice them yet.

None of this is expensive in absolute terms. That is exactly why it gets ignored. A cost that is small but certain is much easier to plan for than a cost that is large but uncertain, and yet founders reliably do the opposite, modeling the revenue nobody has promised and skipping the invoice that arrives every year without fail.

A company has a heartbeat cost, and it starts on the day you file, not the day you sell.

Monday: the founder agreement, and why it is the first product you ship.

In Practice: Building an AI Company | Lesson 1: Pick the Entity Before You Pick the Logo

The certificate of incorporation runs to two pages. Mine arrived as a PDF with a state seal in the corner, a file number, and a timestamp accurate to the second. It cost less than a decent dinner. It contains no description of what the company does, no mention of the product, and none of the names of the people who had spent four months arguing about the product.

It is the least interesting document the company will ever produce and the most expensive one to get wrong.

Everything downstream is shaped by it. Who is allowed to own a piece of the company. Whether you can issue options to the engineer you want to hire in eight months. What happens to your money if there is ever an exit. Whether an investor’s lawyer spends twenty minutes on your paperwork or three weeks. You feel none of this on the day you file. You feel it two years later, usually in a week when you have no time.

The question that decides it for most teams

There are three structures in the conversation: the limited liability company, the S corporation, and the C corporation. For a lot of founding teams one of those three is eliminated before the tax argument even starts, and almost nobody finds out early enough.

An S corporation cannot have a nonresident alien as a shareholder. That is not a guideline. Section 1361(b)(1)(C) of the Internal Revenue Code makes it a condition of the election, and a single share held by an ineligible person terminates S status for the entire company. Residency here is a tax classification, not a passport and not a visa. You qualify by holding a green card or by meeting the substantial presence test, which is a day-count formula. Living abroad while holding US citizenship is fine. Living abroad on a foreign passport is not.

If any of your co-founders sits outside the United States without a green card, the S corporation is gone. There is a trust structure that allows a nonresident to be a beneficiary of an entity holding S corporation stock, but it is an estate planning instrument, not a founding structure, and no early-stage company should be building one.

Two further S corporation constraints matter even for an all-US team. The cap is one hundred shareholders, which sounds generous until you have run two SAFE rounds. And there can be only one class of stock, which means you cannot issue preferred shares. Institutional investors buy preferred shares. That one line quietly makes the S corporation incompatible with nearly every venture round that has ever been done.

So for most teams the choice is not three ways. It is two.

LLC or C corporation, and the question underneath it

The limited liability company is simpler and cheaper in almost every respect. There is no share structure, which removes the main variable that makes corporate formation expensive and fiddly. Profits pass through to the members and are taxed once. Annual maintenance is lighter. If you are building a business you intend to fund out of its own revenue, and you plan to take money out of it as distributions, the LLC is not a compromise. It is the correct answer, and a lot of quietly profitable software companies are structured this way on purpose.

The C corporation is what institutional investors buy, and not out of preference. Many venture funds have tax-exempt limited partners, university endowments and foundations among them, who face real problems taking pass-through income from an operating business. Others have foreign limited partners with their own reasons for staying out of partnerships. Beyond that, employee stock options are a corporate instrument. If you intend to compete for engineers using equity, you need a corporation and a stock plan.

The question underneath the entity choice is not legal at all. It is this: how do you plan to get paid?

If the answer is distributions from profit, you want the LLC. If the answer is the sale of stock, whether to an acquirer or in a secondary, you want the corporation, and you want it early.

Where, and why the answer is boring

Delaware remains the default for corporations, and the reasons are structural rather than sentimental. It has a dedicated business court with judges who hear only corporate matters and no juries, which has produced a deep and predictable body of case law. Investor lawyers know it, which means your documents do not need to be explained to anyone. Choosing it removes a conversation rather than winning one.

It is not free. A Delaware corporation pays annual franchise tax that varies with share structure, and founders who authorize ten million shares and then use the wrong calculation method receive a bill that looks like a typo. There is a second method that produces a far smaller number for a normal early-stage company, and it is worth knowing that before the first invoice arrives rather than after. For an LLC the equivalent is a flat annual amount and the paperwork is lighter.

The argument that changed in July 2025

There is a provision in the tax code, Section 1202, that lets an individual exclude capital gain on the sale of qualified small business stock. It applies to stock in a domestic C corporation. Not an LLC, not a partnership. Stock.

For fifteen years the rule was straightforward and slow. Hold the stock more than five years, exclude 100 percent of the gain, capped at the greater of ten million dollars or ten times your basis, and only if the company’s aggregate gross assets never exceeded fifty million dollars at issuance.

That changed on 4 July 2025. For stock issued after that date the exclusion became tiered. Three years gets you 50 percent. Four years gets you 75 percent. Five years still gets you 100 percent. The per-issuer cap rose from ten million to fifteen million, indexed for inflation from 2027. The gross asset ceiling rose from fifty million to seventy-five million, also indexed. Stock issued on or before 4 July 2025 stays under the old rules, and you generally cannot reset the clock by exchanging old stock for new.

The three-year tier is the part that changes founder behavior. The old regime asked you to bet on a five-year horizon before any relief appeared at all, which for a lot of people was longer than they could honestly forecast. Partial relief arriving at year three makes the corporate structure worth choosing at formation rather than at the first term sheet.

Two cautions. This is stock, so an LLC gets nothing, and converting an LLC into a corporation later starts the holding period from the conversion, not from the day you had the idea. And every one of these conditions has to hold at issuance and afterward. It is worth an hour with a tax professional before you file anything rather than after.

Three ways this goes wrong

You form an LLC because it is cheap, then convert under time pressure. Conversion is possible and routine. It is also a taxable event in some configurations, it resets your employer identification number, it costs a few thousand dollars in legal fees, and it lands in the exact week you are trying to close a round. The saving at formation was a few hundred dollars.

You elect S corporation status on general advice and terminate it without noticing. This happens when an accountant optimizes for self-employment tax without asking where every shareholder is tax resident. The election does not fail loudly. It fails on a return, later, with interest attached.

You incorporate somewhere you do not operate and skip the second filing. Incorporating in one state and running the business from another usually requires registering as a foreign entity where you actually operate, with its own fees and its own annual reports. It is not optional, and it is easy to forget because nothing happens for a while.

None of this is advice about your situation and I am not qualified to give any. It is a description of the machinery. The point of describing it is that the machinery is knowable in an afternoon, while the cost of not knowing it shows up years later, priced in something other than money.

Choose the entity that matches how you plan to get paid, not how you plan to be described.

Tomorrow: the registered agent invoice, and what it costs to keep a company alive before it has sold anything.

In Practice: AI in the Enterprise | Day 90: What Comes Next: The Future of Enterprise AI Governance (What to Prepare For Now)

Ninety days of thinking about enterprise AI governance has been useful partly because it’s forced the question: what changes after day 90?

The honest answer is: the challenges ahead are likely to be different from the challenges of today. What follows are observations about emerging patterns and possible directions—not predictions. I’m exploring scenarios rather than asserting certainties.

Today’s governance challenges are structural and procedural. They’re about building governance frameworks that fit foundation models. They’re about distributing governance expertise. They’re about shifting from reactive to predictive. These are hard problems, but they’re addressable with work, with the right expertise, and with organizational will.

The challenges coming are different. They’re about governance in a world where AI isn’t an isolated function—it’s embedded in every part of the business. Where the competition isn’t about who has the best AI. It’s about who can govern AI reliably enough to build customer trust and regulatory confidence. Where the risk surface isn’t models or data in isolation—it’s the complex system of humans, algorithms, and business processes that are deeply entangled.

What follows isn’t a prediction about AI itself. It’s about what enterprise AI governance may need to become.

From Islands to Networks

Today, enterprises still think of AI systems as somewhat discrete things. You have a team working on a recommendation model. Another team working on a fraud detection system. Another on customer service. These are governed separately, with separate risk frameworks and separate accountability.

This was always an artificial isolation. But it was manageable. You could govern each system largely independently.

That’s ending. First, because enterprises are stacking systems—you call the recommendation model, which calls another model, which reads data that’s been transformed by a third system. The risk surface is no longer one model. It’s a network.

Second, because AI is moving from specialized applications to general infrastructure. Language models are becoming utilities. Vision systems are becoming integrated into many workflows. The same foundational system is being used across an organization in dozens of ways, most of which you didn’t architect.

This creates a governance problem that doesn’t exist today: how do you govern a network where the components are interdependent, where the same model is used in multiple contexts, where failures in one place cascade to others?

The governance frameworks of today—designed for individual systems—will not scale to that. You’ll need network-level governance. You’ll need to understand not just whether individual systems are safe, but whether the network is stable. You’ll need to understand emergent behaviors that come from interactions between systems.

The Visibility Problem Gets Harder

Right now, enterprises have an advantage: they’re still building AI systems consciously. Someone in the organization knows about them. There’s a project. There’s a team. There’s a deployment.

That’s changing. As foundation models become more accessible and easier to integrate, organizations could have systems running that nobody in a governance role knows about. A team might fine-tune a model internally for a specific use case. Another team might integrate a public model into a workflow. A third could use an AI service from a cloud provider that abstracts away the model entirely.

This is the governance problem that keeps senior leaders awake at night: shadow AI. Systems running in production, creating consequential outputs, that the governance function doesn’t know exist.

Today, most governance programs are built around the assumption that they have visibility into what’s being built. Tomorrow, they won’t. You can have strong governance processes, but if you don’t know about 60% of the AI systems in your organization, what are you actually governing?

This requires a completely different governance architecture. Not one based on approval gates for known systems, but one based on continuous discovery. Instrumentation. Monitoring. Scanning for systems that are showing characteristics of AI—generating synthetic outputs, making decisions based on pattern recognition, behaving in ways that suggest trained models.

The organizations that are preparing now are starting to think about system discovery. How would you find a deployed model you don’t know about? How would you identify that a system is using AI? What signals would tell you? Those are the governance capabilities you’ll need.

Regulation May Mature (and Create New Risk)

Right now, AI regulation is nascent. Different jurisdictions have different rules. They’re often vague. They’re still being formed. This creates uncertainty, but it also creates breathing room. You can be compliant with one standard and not fully compliant with another.

That may change. Over the next two years, regulation is likely to become more mature. The rules may become more specific, more demanding, more overlapping. Different regions may have conflicting requirements. A system that complies with the EU may not comply with Singapore. Compliance could become increasingly complex.

But here’s the harder part: regulation may create new liability. Right now, if you have a good-faith governance program, regulators are generally forgiving. But as regulation matures, the standard may shift from “did you have a governance program?” to “did you have the right governance program?” And penalties for being wrong could increase.

This creates a risk that most organizations haven’t thought through: governance drift. You could have a program that was state-of-the-art in 2026 and find it outdated by 2028. You might then face a position where you’re compliant with old rules but non-compliant with new ones, but you don’t realize it yet.

Organizations preparing now are building governance programs that are forward-compatible. That can adapt as rules change. That don’t assume the current regulatory environment is stable. Because it’s not.

The Human Factor Will Matter More, Not Less

A common hope in governance is that once you have the right processes and frameworks, execution becomes more routine. You can delegate it. It becomes systematic.

This hope is wrong, especially for AI. The more sophisticated AI governance becomes, the more it depends on human judgment. Is this model output surprising in an important way or an expected way? Does this emerging behavior represent a new risk or just normal variation? When two governance requirements conflict, which do we prioritize?

These aren’t questions you can answer with process. They require judgment. They require experience. They require people who understand both AI and the business deeply enough to see the connections.

Organizations preparing for this are investing in governance people. Not compliance people. People who can reason about risk, who understand technical AI, who can translate between technical and business language, and who are trusted by product teams as helpers, not blockers.

This is counterintuitive. The instinct is that more governance should be less dependent on people, more systematic. But with AI, it’s the opposite. Better governance requires better people.

The Trust Problem Will Emerge

Over the next few years, an interesting dynamic may emerge: AI could start failing in ways that matter. Not catastrophically—not AI systems destroying companies or harming people at scale. But visibly. Systems that discriminate. Systems that produce outputs that turn out to be confidently wrong. Systems that make decisions that, in hindsight, should have been caught.

These failures could be covered. They could be litigated. They could affect customer trust. And they may create an opportunity for enterprises that have genuine governance to differentiate.

Organizations with real governance would be able to say: we caught this. We understand our risks. We know where our systems can and can’t be trusted. We’re not perfect, but we’re reliable.

Organizations without it would be saying: this was an unforeseen edge case. We have controls. We have policies. But they wouldn’t be able to point to concrete governance practices that caught or would have caught the problem.

Trust becomes the battleground. And trust is won through demonstrated governance, not asserted governance.

What You Should Do Now

If you’re responsible for AI governance in an enterprise, here’s what I’d focus on preparing for:

First: Build the capability to discover and map your AI systems. You need to know what’s running in your organization. Invest in scanning. Instrumentation. Monitoring. Not to police, but to understand what you actually have to govern.

Second: Shift from system governance to network governance. Start thinking about how systems interact. Where do failures cascade? Where do emergent behaviors appear? Network-level risks are becoming the dominant risk category.

Third: Prepare for governance evolution. Your current governance program may need significant updates within 18 months. Design it to be updatable. Design it to be forward-compatible. Plan for change.

Fourth: Invest in people. Governance expertise is more valuable than governance process. Build a team that can reason about complex tradeoffs, that’s trusted by the business, that can evolve as the landscape changes.

Fifth: Focus on trust, not compliance. Compliance is table stakes. Trust is the competitive advantage. Build governance practices that genuinely give customers and regulators confidence in your systems.

The Work Continues

Ninety days of thinking about AI governance reveals something important: this is not a problem that gets solved. It’s a problem that gets managed continuously. The organizations that are winning are the ones that accept this. They’re not trying to build governance once and have it work forever. They’re building organizations that can think clearly about AI risk and adjust as the landscape changes.

The challenges of today—framework-building, expertise distribution, governance scaling—are real. And they’ll be solved by enterprises that take the work seriously.

But the challenges ahead are different. They’re about discovering systems you don’t know exist. About governing networks instead of islands. About building trust instead of compliance theater. About developing governance expertise that can evolve as AI itself evolves.

The work of ninety days was about understanding the current moment. The work that comes next is about preparing for what’s coming.

The organizations that are moving fast on enterprise AI are the ones that know this. They’re not waiting for perfect governance in 2026. They’re building governance that can adapt to a 2028 world they don’t fully know yet.

That’s how you prepare for what comes next.

In Practice: AI in the Enterprise | Day 89: Beyond Compliance: How Governance Becomes Competitive Advantage

A question that sometimes reveals misaligned priorities in AI governance is: “What’s the minimum we need to do to comply?”

It’s misguided because it assumes compliance is the constraint. It’s not. The constraint is everything compliance is trying to prevent: deploying systems that fail, that create liability, that damage trust, that lock you into operational patterns you can’t escape.

The organizations that get this right have stopped thinking about governance as cost and started thinking about it as operational infrastructure. The same way that supply chain management isn’t a cost—it’s what enables scale. The same way that financial controls aren’t a constraint—they’re what make complex transactions possible.

Governance becomes competitive advantage exactly when you stop treating it as something imposed from outside and start treating it as something that enables your business to move faster.

The Minimum Compliance Trap

Companies that focus on minimum compliance usually end up with the same governance architecture: a compliance team checking boxes, a business team moving fast and discovering problems later, and a constant friction between the two.

The compliance team is seen as the people who slow things down. The business team is seen as the people who take risks. They’re adversaries. And in that adversarial relationship, the organization moves slower, not faster.

Then when something goes wrong, the compliance team says “we told you so” and implements stricter controls. Which makes everything slower. And the cycle continues.

The question “what’s the minimum we need to comply” leads directly to this dynamic. Because the answer is usually “enough to pass audit.” And passing audit is a low bar for actual governance.

What Competitive Governance Looks Like

The organizations that are genuinely leading on enterprise AI have reframed governance completely. Compliance is a constraint they have to manage, but it’s not what governance is for.

Governance is for enabling confident deployment at scale. It’s the infrastructure that lets you move fast because you understand your risks.

What that actually looks like is different from what most governance programs look like. It includes:

Distributed decision-making capability. Governance isn’t something that happens at a gate. It’s something every team in the organization has learned to do. Your product teams understand how to think about AI risk. Your data teams understand how to govern datasets. Your engineering teams know how to monitor for problems. The governance team’s job shifts from making all the decisions to ensuring that capability is distributed.

Predictive rather than reactive risk management. You’re not waiting for things to break. You’re watching for signals that suggest things are about to break. You’re adjusting assumptions and approaches before problems become crises. This is faster than reactive management because you’re not spending weeks investigating problems and months remediating them.

Clear decision frameworks that empower rather than constrain. Instead of “you need approval to deploy,” the framework is “if your system meets these criteria, deployment is automatic. If it doesn’t, here’s why and what needs to change.” Teams know exactly what they need to do to move fast. They’re not waiting for exceptions. They’re building systems that meet the framework.

Integration of governance learning into how you architect future systems. When something fails, you don’t just investigate—you use that to improve how you approach similar systems going forward. Over time, you’ve learned what works and what doesn’t. Your architectures improve. Your decision-making improves. You fail less frequently.

Speed and Safety as a Unified Goal

This is where the framing shifts from cost to capability. The organizations moving fastest on enterprise AI aren’t moving fast despite governance. They’re moving fast because of governance.

They’re moving fast because:

  • They understand their risks, so they can make confident decisions
  • They catch problems early, so they don’t lose months to remediation
  • They learn from what happens, so they make better decisions next time
  • They distribute decision-making, so they’re not bottlenecked by centralized approval

These are all governance capabilities. And they’re all competitive advantages.

Compare that to companies that view governance as a constraint. They move fast initially, deploying systems without full understanding. But then they discover problems. Then they have incidents. Then they have to explain those incidents to regulators. Then they implement strict controls that slow everything down.

That’s not speed. That’s speed followed by hard stop.

What This Costs and What It Returns

Building governance that’s actually competitive is more expensive upfront than checking compliance boxes. You need people with governance expertise distributed through the organization. You need systems that give you visibility into risks. You need to invest in learning infrastructure.

But what you get back is worth it:

  • Operational speed: Your average time from decision to deployment shrinks because you’re not discovering critical problems after commitment
  • Risk reduction: Your incident rate goes down because you’re catching problems early
  • Organizational learning: You compound improvements because you actually learn from what you see
  • Regulatory confidence: Regulators see an organization that understands and manages its own risks, which leads to lighter-touch oversight over time
  • Customer trust: Your customers see a company that takes governance seriously, which builds long-term relationships

These aren’t small returns. Over a multi-year horizon, the competitive advantage of genuine governance over compliance theater is enormous.

The Threshold Moment

There’s usually a moment when organizations shift from “governance is cost” to “governance is capability.” It’s not when they read an article or hire a consultant. It’s usually when they’ve had a meaningful incident that cost them something real—money, customer trust, regulatory attention, or organizational reputation.

At that moment, they’re forced to choose: double down on theater (hire more auditors, create more policies) or invest in real governance infrastructure. The ones that choose real governance find that six months later, their incident rate has dropped. Their decision velocity has improved. They’re moving faster while being safer.

Where You Actually Are

If you’re reading this, you’re probably not at minimum-compliance-trap organization anymore. You’ve recognized that governance is important. The question is whether you’re still thinking of it as cost to minimize or capability to develop.

Here’s a useful signal: Does governance slow you down or speed you up? If every governance interaction adds time, you have theater. If governance interactions improve your confidence in decisions and reduce time spent on post-deployment remediation, you have something real.

The organizations that are winning on enterprise AI are the ones that have completed the shift from “minimum compliance” to “competitive governance.” That shift isn’t about doing more governance. It’s about doing governance that actually works.

That’s the competitive advantage.

In Practice: AI in the Enterprise | Day 88: The Organizational Learning Loop: How Accountability Creates Continuous Improvement

There’s a category of governance that doesn’t show up in policy documents or frameworks. It’s not something you can hand off to a governance team. It’s how your organization actually learns when something goes wrong.

The difference between organizations that improve and organizations that repeat failures is accountability—not in the punitive sense, but in the structural sense. When something fails, what happens? Does the organization understand why? Does that understanding change how you operate? Does it change how you build and deploy systems in the future?

Most enterprises are terrible at this. They investigate incidents, file reports, move on. They don’t have organizational memory. So they deploy similar risky systems six months later, make the same mistake, and are surprised.

The best-run organizations have built accountability into their governance structure as a learning mechanism. That’s how you improve continuously.

Why Accountability Matters for Governance

Accountability is often positioned as a way to prevent bad behavior—if people know they’ll be held responsible, they’ll be more careful. That’s true, but it’s not the important part.

The important part is learning. When something fails, someone needs to understand what happened and why. That understanding needs to be persistent—it needs to affect future decisions, not just the immediate response.

Most organizations have incident investigation processes. They’re just not connected to their governance systems. When something goes wrong, an engineering team investigates, files a report, and moves on. The governance team doesn’t see the connection. The broader organization doesn’t adjust. The same underlying issue shows up again months later in a different form.

That’s not accountability. That’s theater.

Real accountability is structural. It means when something fails, the learning flows through the organization. It means future decisions are informed by past failures. It means you’re building an organization that gets smarter over time, not one that’s constantly rediscovering the same problems.

What This Looks Like in Practice

The organizations doing this well have built a few specific structures into how they operate.

First: Clear ownership and decision documentation.

Every significant AI system has someone or some team that owns it. That ownership includes understanding what assumptions the system is based on, what the risks are, what conditions would make the system unsafe. This isn’t a symbolic ownership—it’s actual responsibility.

When something fails, the investigation starts with understanding what the owner knew and when they knew it. Not in a blame sense, but in a learning sense. Did they understand the risk? Was the risk identified but accepted? Was there genuinely no way to predict it?

This distinction matters. If a risk was identified and accepted, the organization learned something about its risk tolerance. If a risk was identified but missed, that’s a different learning—the organization needs to improve its risk identification processes. If the risk was truly unforeseen, that’s organizational education.

Second: Structured learning from incidents.

When an incident happens, you want to understand: What were we assuming? How did that assumption break? How could we have detected it earlier? What would we do differently next time?

The best organizations have a structured way of asking these questions. Not a checklist—those tend to become theater. But a genuine conversation with the people involved, aimed at understanding what can be learned and what needs to change.

That learning then gets documented and connected to future decisions. If you discover that a particular type of data is riskier than you thought, you update how you approach similar data going forward. If you discover that your monitoring systems missed an important signal, you add that signal to your monitoring. If you discover that communication broke down, you change your governance structure.

Third: Distributed accountability instead of centralized.

In many organizations, accountability for AI governance sits with a central governance team. They’re responsible for risk. But they can’t actually change how products get built or what data gets used. So accountability becomes disconnected from action.

Leading organizations distribute accountability. Product teams own the risk profile of their systems. Data teams own the governance of their datasets. Engineering teams own how systems are monitored. The governance team’s role shifts from accountability itself to ensuring accountability is being taken seriously across the organization.

This requires trust and clarity about escalation. If a team is taking accountability seriously, the governance team supports them. If accountability is being taken lightly, there’s escalation. But the day-to-day accountability is distributed.

Fourth: Connecting patterns across incidents.

Individual incidents are learning opportunities. But patterns across incidents are governance opportunities. If you have three different teams making similar risk decisions in different ways, that’s information. If you see the same type of problem emerging in three different systems, that’s a signal.

The organizations that improve fastest are the ones that aggregate these patterns and make them visible. They might hold quarterly governance reviews where patterns are discussed. They might have a simple dashboard showing types of risks being discovered, systems affected, and whether learnings are being applied. The point is to make patterns visible so the organization learns systematically, not just individually.

How This Connects to Governance Architecture

This brings us back to a theme I’ve mentioned before: effective governance requires distributed expertise and shared understanding of risk.

When accountability is centralized in a governance team, you get compliance theater. The governance team is checking boxes. The business teams are moving fast and discovering problems later. Nobody is really learning.

When accountability is distributed, you get continuous improvement. Each team owns their risk. They’re incentivized to learn from failures because it affects their own systems. Governance becomes a capability each team develops, not something external that’s imposed on them.

This is why decision velocity and governance effectiveness are connected. Organizations with high decision velocity aren’t moving fast because they’re skipping governance. They’re moving fast because governance is embedded in the teams making decisions. The accountability for the decisions is clear. The learning from failures is rapid. The organization improves continuously.

Why This Matters for Enterprise Scale

At enterprise scale, with many teams building many systems, the difference between learning-oriented and theater-oriented governance becomes dramatic. Learning-oriented governance compound over time. Early learnings affect later decisions. The organization gets smarter.

Theater-oriented governance doesn’t compound. Each team makes decisions independently. Learnings don’t spread. The organization makes the same mistakes repeatedly at different scales.

By year two of an enterprise AI program, you can usually tell which model an organization is running. The learning-oriented organizations have systems that are stable, that are improving over time, that have fewer incidents. The theater-oriented organizations have constant fires and constant surprises.

Where to Start

If you’re building accountability into your governance, start with the highest-risk systems:

  1. Define clear ownership. Who is responsible for this system? Not in a title sense, but in a substantive sense. What do they own?

  2. Document assumptions at deployment time. What are you assuming about this system? What conditions would make it unsafe? When will those assumptions be tested? Get this in writing.

  3. Create structured learning processes. When something goes wrong, what’s the process for understanding why? How do you make sure learning is documented and shared?

  4. Connect patterns across incidents. Are you seeing similar risks in different systems? What does that tell you about your organization?

  5. Measure distributed accountability. How many governance decisions are being made by product/data/engineering teams versus being escalated to a central team? Higher distribution is a signal of health.

The organizations that improve fastest aren’t the ones with the most rigid governance. They’re the ones with the most effective learning loops. And those learning loops are built through accountability structures that make learning visible and continuous.

Governance without accountability is just process. Governance with accountability is how organizations improve.