Thoughts on "Reconsidering Coase in the Age of AI"

This conversation is a discussion of this new paper.

Abstract

Coase explained the firm as the answer to transaction costs. Work stays inside when specifying, verifying and directing outsiders costs more than hiring employees. This note argues that AI erodes the assumptions behind that answer, rather than merely lowering the costs. Engineered systems known as harnesses largely complete contracts in real time, make external work more observable than employment, and carry context and control across the firm’s edge. As a result, the boundary that predicts where context sits, who controls the work, and where knowledge accumulates becomes the instrumented system, not the legal entity. Legal services, the profession organized most completely around Coasean frictions, is the worked example. Three tests decide the order in which work migrates. Three un-Coasean consequences follow. The boundary becomes something providers compete to move, knowledge pools with them, and incentives invert toward legal dispute prevention. Four conditions identify which other sectors restructure. The argument is predictive because the external-harness model is still early, and the pace is set by organizational inertia rather than the technology itself.

Three Erosions

1. Incomplete Contract Now Completes Itself

Contracts were incomplete when specifying every contingency was impossible, and the firm existed in part because a contract for "handle whatever arises" could not be written. Instead a general counsel was employed. Within an engineered AI system, what practitioners now call a harness covers context retrieval, encoded policies, deterministic rules, logging, and escalation gates. It thereby applies the client's encoded policies, sometimes in a probabilistic (so non-deterministic way) to cases nobody foresaw, escalates what is genuinely novel, and records every step and the rationale. In functional terms the harness acts as a contract that largely completes itself in real time. The classic reason to employ rather than contract weakens in proportion to what the harness can carry. Residual incompleteness remains for genuine novelty; the harness does not eliminate the need for human authority at the edge.

2. Observability Inverts

Williamson's hazard, and Alchian and Demsetz's account of the firm as a monitoring device, assumed that what is outside is opaque, and the employee can be monitored. The AI inversion is that a harness-delivered, external service is more observable than an employee: every retrieval, every check, every draft, every sign-off is logged and inspectable, while your own employee's reasoning cannot be audited at all. The make-or-buy hazard was moral hazard in the market from unsupervised external providers. In the AI era it is becoming relatively opaque internally. Buying becomes the more transparent option, given the
right interfaces.

3. Boundary

The boundary that matters stops being the firm. Coase's question was which transactions come inside the legal entity. With AI the question now is which decisions come inside the
instrumented, policy-governed, logged system, and that boundary cuts across entities. A
company's general counsel approving work inside an external provider's harness is inside the harness boundary while outside the firm boundary. Employment versus contract stops predicting where context sits, who controls the work, or where knowledge accumulates. The harness carries context and control across the boundary of the firm and thereby blurs it.

Four Conditions for Sector Restructuring

Whether a sector restructures, or just adopts AI into what it already has, rests on four
conditions. The work has a large procedural core that recurs at volume. Its outcomes can be
observed and learned from. Doing it across many clients makes the provider better at it.
Responsibility for it can rest on escalation and insurance, without the whole function being
under one insurance umbrella.

Discussion Topics

If we assume that the papers argument is correct:

• What sectors are most susceptible to restructuring?
• What information management systems will companies use in order to be legible to AI agents? They’ll want to have up to date, consistent, and searchable context for AIs to use and monitor.
• Does this change software development? Will more companies hire contractors?

The strongest implication is not that firms disappear. It is that the legal entity stops being the main unit of operational integration. A cross-company control plane becomes the practical firm.

That may be less “un-Coasean” than it first appears. AI does not abolish transaction costs; it shifts them into designing the harness, maintaining context, assigning liability, controlling access, and resolving exceptions. The winning organizations may be those that can perform those functions at scale.

Sectors most susceptible

The best candidates combine:

1. High recurring volume
2. Expensive professional judgment that can mostly be decomposed into rules and precedents
3. Machine-observable outcomes
4. Similar work across many customers
5. Exceptions that can be escalated to a relatively small human layer

That points to:

• Accounting, audit preparation, tax, and bookkeeping
• Insurance underwriting, claims, and subrogation
• Healthcare administration: coding, prior authorization, billing, compliance—not diagnosis generally
• Cybersecurity operations: monitoring, triage, remediation, evidence collection
• Procurement and vendor management
• Financial compliance: KYC, AML, surveillance, regulatory reporting
• HR administration: benefits, payroll, routine employee relations, policy compliance
• Logistics and trade compliance
• Property management
• Routine legal services

Insurance may be especially important because it can supply the missing accountability layer. The provider says, in effect: “Use our harness; we will log every decision, escalate defined cases, and insure the residual risk.”

Less susceptible sectors have physical bottlenecks, hard-to-measure outcomes, highly local knowledge, long feedback loops, or tightly coupled strategic decisions. Executive management, frontier R&D, complex sales, and much physical fieldwork remain harder.

A useful ranking question is:

Can a provider learn more from serving 1,000 clients than any one client loses by externalizing the function?

If yes, restructuring pressure will be strong.

The new corporate information system

Companies will need something beyond today’s document repositories and SaaS sprawl. The basic architecture looks like an organizational context layer:

• Canonical models of customers, products, contracts, employees, and vendors
• Event histories rather than merely current database states
• Policies represented as executable rules
• Fine-grained identity, permissions, and delegation
• Provenance for every fact and generated conclusion
• Versioning and effective dates
• Confidence levels and conflict resolution
• Logs of agent actions, tool calls, approvals, and escalations
• Evaluation systems that compare decisions against later outcomes
• APIs through which internal and external agents can act safely

The difficult part will not be semantic search. It will be deciding what is authoritative. Most organizations contain contradictory policies, stale documents, undocumented exceptions, and incentives to keep activities illegible.

So AI readiness may become a form of institutional discipline. Firms will have to turn “how things actually work” into explicit, maintained state. That is both valuable and politically threatening.↳ Politics of Observability

There is also a security paradox: the more legible a company becomes to its agents, the more legible it may become to an attacker. Context architecture will therefore need to support selective disclosure. An external legal agent might know everything relevant to a contract without receiving broad access to the company’s internal systems.

Does software development move to contractors?

Some of it will, but probably not toward individual freelancers. The likely winner is the harness-owning software service provider.

Software contains two different kinds of work:

Easier to externalize

• Tests and test maintenance
• Dependency upgrades
• Migrations
• Routine integrations
• Bug triage
• Security remediation
• Internal tools
• Well-specified product features
• Operations and incident classification

These activities are observable, repeatable, and can be bounded by repositories, CI systems, tickets, telemetry, and acceptance tests.

Harder to externalize

• Product discovery
• Architectural tradeoffs
• Decisions involving undocumented business constraints
• Security-critical platform ownership
• Work requiring sustained coordination across many teams
• Systems where failure is visible only months later

Software’s limiting resource may no longer be coding labor. It may be coherent product judgment. AI makes implementation cheaper, which can increase the value of people who understand what should be built and how it fits the business.

There is also a countervailing effect: if AI lowers the cost of software enough, companies may build far more custom software internally. Thus the share of code produced externally can rise while internal software activity rises too.

The key distinction is not employee versus contractor. It is:

Who owns the persistent context, evaluation loop, and production authority?

A contractor who only submits code remains outside. A provider whose agents continuously inspect telemetry, open changes, run evaluations, and deploy approved fixes is effectively inside the operational boundary.

The deeper competitive consequence

The paper’s most consequential idea may be that providers will compete to expand their harness boundary. A legal provider starts with contract review, then absorbs procurement policy, compliance monitoring, negotiation history, and insurance. A cybersecurity provider moves from alert triage into identity governance and infrastructure policy.

At that point, these providers are not merely vendors. They become private administrative systems spanning many firms. Their accumulated cross-client data and process knowledge may create stronger economies of scale than traditional employment ever did.

That raises the question I would watch most closely:

Does the customer retain enough context and control to replace the provider?

If not, lower transaction costs at the worker level may produce higher switching costs at the harness level. The firm’s old bureaucracy could be replaced by a vendor’s proprietary bureaucracy—more observable, perhaps, but also more powerful.

What are opportunities are there for new types of software that can provide that organizational context layer? What would a minimal viable product in this space look like?

The opportunity is easy to describe badly: “Put all company knowledge in one AI-readable layer.” That usually becomes an expensive knowledge graph with no clear owner and stale data.

A better framing is:

Build the system that determines what an agent is allowed to believe and do for one important workflow.

The organizational context layer is not mainly a search product. It is an authority, state, and control product.

Where new software could emerge

1. Context compiler

A context compiler turns fragmented organizational information into a bounded, versioned package for a specific task.

For example, before an agent reviews a vendor contract, it assembles:

• Current procurement policy
• Vendor risk classification
• Prior negotiations
• Approved fallback clauses
• Data handled by the vendor
• Relevant regulatory obligations
• Who can approve each exception

The output is not “ten possibly relevant documents.” It is a structured case file with provenance, effective dates, conflicts, and missing fields.

This could become infrastructure analogous to a compiler:

documents + system records + policies + permissions
                         ↓
         task-specific executable context

The important capability is deterministic context assembly. Given the same organizational state, the system should be able to explain why an agent received a particular fact or instruction.

2. Authority-resolution systems

Companies often have multiple answers to basic questions:

• Which discount may sales offer?
• Who can approve this vendor?
• Is this customer entitled to support?
• Which security requirements apply?
• Which version of the policy was effective when the decision occurred?

Today, humans reconcile these contradictions informally. Agents need an explicit hierarchy of authority.

A product could let organizations specify:

• Source precedence
• Effective dates
• Scope and jurisdiction
• Owners and approvers
• Exception rules
• Confidence and freshness requirements
• Procedures for resolving conflicts

The opportunity is not another database. It is a control plane for organizational truth.

3. Policy-as-code for business operations

Infrastructure teams already use policy-as-code products such as OPA. Most business policies remain trapped in prose.

A business policy platform could translate prose into:

• Deterministic rules
• Probabilistic guidance
• Required checks
• Approval thresholds
• Escalation conditions
• Test cases
• Version histories

A legal or operations leader should be able to modify a policy and run it against the previous six months of cases:

“If this rule had been active, which decisions would have changed?”

That kind of policy simulation could be a valuable standalone product.

4. Agent identity, delegation, and permissions

Traditional access control asks whether a user can read a file. Agentic systems require richer questions:

• On whose behalf is the agent acting?
• For what purpose?
• Which facts may it retrieve?
• Which actions may it take?
• How much money may it commit?
• When must it ask for approval?
• Can it disclose retrieved information to an external model?
• Does its authority expire?

There is room for an “Okta for agents,” but simple identity will probably commoditize. The stronger product would combine identity with delegated authority, purpose restrictions, and action logs.

5. Decision and exception ledgers

Companies record transactions better than decisions. They often cannot reconstruct:

• What information was available
• Which policy applied
• Why an exception was granted
• Who approved it
• What happened afterward

A decision ledger would preserve the full decision object:

case
context snapshot
applicable policy version
agent recommendation
human edits
approval
action taken
eventual outcome

That creates the feedback loop needed to improve agents. It also supports audits, disputes, insurance, and postmortems.

The exception data may become more valuable than the ordinary case data. Normal cases teach the system the procedure; exceptions reveal the organization’s real constitution.

6. Organizational consistency monitoring

A product could continuously detect contradictions such as:

• A sales promise conflicts with the contract
• A contract conflicts with billing configuration
• A current practice conflicts with published policy
• Two departments use different customer classifications
• An employee retains authority after changing roles
• An operational system implements an obsolete policy

This is less “enterprise search” and more organizational static analysis. Just as a compiler finds type errors before software runs, the system finds policy and state inconsistencies before an agent acts on them.

7. Portable context and provider interfaces

If external providers operate inside a customer’s harness boundary, companies need a safe way to expose only the context required for a job.

A product could produce signed, purpose-limited context packages containing:

• Facts relevant to the task
• Applicable policies
• Permitted actions
• Required outputs
• Escalation channels
• Expiration time
• Audit requirements

This could become a standard interface between companies and AI-enabled law firms, accountants, insurers, and software contractors.

What not to build first

I would avoid starting with:

• A universal company knowledge graph
• A generic RAG layer
• “Chat with all your company data”
• A new document repository
• An ontology editor sold to IT
• A platform requiring a company-wide migration
• An agent dashboard without control of a real workflow

Those products may become components, but they lack a forcing function for accuracy. If a wrong answer has no operational consequence, nobody will maintain the context.

The system becomes valuable only when it sits in the path of a recurring decision.

A credible MVP

The MVP should handle one decision type for one functional buyer.

A good initial workflow might be vendor approval. It has:

• Recurring volume
• Inputs spread across several systems
• Explicit policies
• Multiple approvers
• Frequent exceptions
• Meaningful delays
• Observable outcomes
• Enough risk to pay for control

MVP: vendor-approval context engine

Integrate with only three or four sources:

• Procurement or ticketing system
• Contract repository
• Security questionnaire platform
• Identity provider or HR system

Then provide five capabilities.

1. Build a structured case file

For each vendor request, extract:

• Vendor identity
• Product owner
• Spend
• Data classifications
• Countries involved
• Contract status
• Security posture
• Renewal date
• Prior relationship

Every field should include its source, timestamp, and confidence.

2. Apply versioned policies

Represent perhaps ten to twenty high-value rules:

• Security review required if customer data is processed
• Legal approval required above a spend threshold
• Finance approval required for auto-renewal
• Additional review required for particular jurisdictions
• Executive approval required for specified exceptions

Do not begin by converting the whole policy manual. Encode only rules that alter routing or approval.

3. Identify conflicts and missing context

Instead of silently guessing, the product should say:

• Contract says no personal data; security questionnaire says personal data is processed.
• Vendor owner is missing.
• The cited policy expired last month.
• Requested approver lacks authority at this spend level.

This is likely more valuable initially than autonomous approval.

4. Route exceptions

Create a small exception inbox where authorized people can:

• Supply missing facts
• Resolve conflicts
• Grant time-limited exceptions
• Modify the recommended action
• Explain their reasoning

The system then stores those resolutions as structured data.

5. Produce an auditable decision packet

The output should show:

• Facts relied upon
• Rules applied
• Conflicts detected
• Approvals obtained
• Final decision
• Actions taken

It should also write the result back to the existing procurement system. The customer should not have to replace its system of record.

The first product probably should not make decisions

A startup may be tempted to promise an autonomous operator immediately. That introduces trust and liability before it has learned the organization.

The better sequence is:

1. Observe: Assemble the context currently used by humans.
2. Check: Find missing, stale, and contradictory information.
3. Recommend: Apply policies and suggest a decision.
4. Act with approval: Execute bounded actions after review.
5. Act automatically: Handle the low-risk, repetitive majority.

This also creates a natural sales path. The first value proposition is faster decisions and fewer errors, not “replace your operations team.”

What makes the MVP defensible?

Connectors and retrieval will not be much of a moat. Model quality probably will not be either.

The defensible assets are more likely to be:

A decision ontology

The product develops a strong model of a particular function: its cases, facts, policies, authorities, exceptions, and outcomes.

An exception corpus

Each corrected recommendation teaches the system where written policy differs from actual practice. That is difficult for a new entrant to reproduce.

Workflow position

Once every relevant decision passes through the product, it becomes the place where policy is interpreted and operational state is reconciled.

Outcome data

The system can eventually learn which approvals, clauses, vendors, or exceptions lead to good and bad outcomes across customers.

Trust infrastructure

Auditors, insurers, and external providers may begin accepting its decision records. That institutional acceptance could matter more than technical differentiation.

How to tell whether a wedge is good

I would score candidate workflows on seven questions:

1. Does the decision happen at least hundreds of times per year?
2. Is context currently gathered from at least three systems?
3. Does gathering it consume expensive labor?
4. Can the relevant policy be partially encoded?
5. Is there a recognizable person with final authority?
6. Can the eventual outcome be observed?
7. Does an incorrect decision impose a measurable cost?

Vendor approval, contract intake, customer discount approval, access provisioning, security remediation, insurance claims, and software release governance all score reasonably well.

A software-development-specific wedge

For engineering organizations, an attractive MVP could be a change-authority layer for AI coding agents.

For each proposed change, it would assemble:

• Repository and service ownership
• Relevant architecture decisions
• Current incidents
• Security requirements
• Deployment restrictions
• Dependency relationships
• Required reviewers
• Tests and service-level objectives
• Recent changes to the same system

It would then decide what the agent may do:

• Draft a pull request
• Modify particular directories
• Run tools
• Request reviews
• Deploy to staging
• Roll back
• Escalate to an owner

The product would not compete directly with coding agents. It would govern every coding agent a company uses.

The risk is that GitHub, GitLab, cloud providers, or observability platforms naturally extend into this position. A startup would need to start with a painful cross-system problem that none of those incumbents sees clearly—perhaps production change approval across code, infrastructure, incidents, and compliance.

The sharpest MVP thesis

If I had to reduce the product to one sentence:

Given a business case, produce the smallest authoritative context package needed to make a decision, detect what is missing or contradictory, and record how the decision was resolved.

That is narrow enough to build and broad enough to become the organizational context layer later.

The key startup question is not “How do we centralize all company knowledge?” It is:

Which recurring decision is expensive enough that the company will pay us to become its authority on what was known, which rule applied, and who could act?