An agent can finish a task on its own. The awkward part comes before and after: choosing the product, supplying the same background again, checking the result, and keeping the useful parts.
Roland Wayne (@rwayne) uses Ronald Coase to explain why one person might still build a system around those agents.
What Coase actually wrote in 1937
In 1931 Coase is at the London School of Economics. Arnold Plant is teaching that prices coordinate production: scarcity raises the price, more people make the thing, and no central planner has to issue orders. Coase asks what that account leaves unexplained: why are there companies, and why does a factory still have a manager? A Cassel Travelling Scholarship takes him to American plants. The 1937 essay in Economica (New Series, Vol. 4, No. 16, pp. 386–405) is that question written out with Marshall’s two tools — the margin, and substitution at the margin.
I was an economics student once, so this is the part of the thread I do not want reduced to a slogan. Intermediate micro hands you the firm as a production function: q = f(K, L), cost curves, profit max, and then the market does the rest. Prices allocate. The firm is a machine that turns inputs into output. Why that machine is a company — with managers, employment contracts, departments — is not the question. It is assumed.
Coase turns the usual unit of analysis into the question. If the price system already coordinates, why isn’t the economy only independent people contracting for each next hour of work? A factory is not exhausted by f(K, L). Coase draws attention to the organization around production: within the firm, managerial direction replaces some market transactions. Markets are not the only allocation mechanism. Sometimes it is cheaper not to use the market. The line between those two is itself economics. That distinction between market exchange and internal direction is the part I bring to Roland’s thread.
Economic theory, Coase says on the first page, had been treating the economic system as if it “worked itself.” Outside the firm, that is roughly true: relative prices move resources around. Inside the firm, the price mechanism is switched off.
If a workman moves from department Y to department X, he does not go because of a change in relative prices, but because he is ordered to do so. — Coase, Economica (1937), pp. 387–388
If production could be carried on with no organisation at all, “well might we ask, why is there any organisation?” His answer predates the familiar “transaction costs” label. In 1937 he writes about the cost of using the price mechanism, sometimes “marketing costs.”
Three costs, in order, from pp. 390–392:
- Discovering what the relevant prices are. Information is not free. You have to find out who can do the work, and on what terms.
- Negotiating and concluding a separate contract for each exchange. On a market you recontract every time. Inside a firm, a series of those contracts is replaced by one.
- The long-term contract you cannot fully write. Especially for services, the longer the period, the less you can specify in advance what the other party must do. So you buy, within limits, the right to direct them later.
That third item is the definition, not a side note:
A firm, therefore, consists of the system of relationships which comes into existence when the direction of resources is dependent on an entrepreneur. — p. 393
The legal cousin, in the last section of the essay, is the master-and-servant / employer-and-employee relation: the servant is under a duty to render service, and the master has the right to control how the work is done, within the contract. A one-off contractor can guarantee a result without being directed. A firm begins when someone is directed.
Coase also asks why there is not one giant firm. Organising internally is not free either. As the firm grows there are diminishing returns to the entrepreneur function: the cost of organising an extra transaction rises; the entrepreneur starts putting factors in the wrong uses; some inputs are cheaper in a small shop than a large one. Dissimilar transactions, and transactions spread out in space, raise those costs faster. So a firm expands until the cost of organising one more transaction inside equals the cost of doing it on the open market, or of having another firm organise it (pp. 394–395).
One prediction from that apparatus: inventions that make organising cheaper — he names the telephone and the telegraph — tend to make firms larger. Frank Knight’s uncertainty story is not enough on its own. You can have uncertainty, insurance, and futures markets without ever superseding the price mechanism. What needs explaining is direction.
Coase at one desk
Roland applies the same boundary question to one person using several agents. Each agent may be able to plan, call tools, and run a long task, but every separate product still has to be briefed and checked.
Roland’s thread lists the recurring costs of calling an agent: stating the goal, supplying background, setting limits, checking facts, retaining evidence, and deciding whether the result can be used.
The analogy to Coase is useful, but not exact. Roland’s list resembles the three marketing costs in a chat window. Finding which product can do the job is discovering prices. Restating the brief every session is negotiating a separate contract for each exchange. Drawing what the agent may not do, then checking the result, is the incomplete long-term contract: you cannot specify the work in advance, so you want a relation in which someone — you — still directs.
A personal system has to hold the order
Plenty of AI products already work. The reason to build around them is not that every product is inadequate; it is that the work, rules, and evidence often have to survive across products and sessions.
A macro analyst needs agents that collect, process, and filter toward a personal research direction. Without a system holding that together, the pieces do not stay in one place. A generic product is cheap at organising the same job for millions of people. A particular research direction is not that job. Coase’s point about dissimilar transactions helps explain why coordination gets harder as the work becomes more specific.
Roland puts order underneath context and memory. Goals, rules, and final responsibility still sit with the person. Each agent needs an identity and a goal. The system has to say what it does, what it must not do, and where the boundary is. After the task comes back, someone still checks it against an acceptance standard — and sends it back if it misses.
When the output is off, Roland’s list is more useful than “the model is bad”:
- the model actually erred
- the facts given to it were wrong
- the task was never stated clearly
- different agents used different rules
- there was no acceptance standard
- old rules and new rules were both still live
A stronger model may improve the run, but it cannot supply a rule or acceptance standard that was never defined.
Several agents create coordination work
Once an agent can plan, call tools, and run a long job with little babysitting, one person calling several of them starts to face work that used to belong to an organization: who does what, how information moves, who checks the result, who holds the rules, who has the last say.
Roland treats the agent as something that can take work, transact, and carry an identity rather than as a feature in a chat box. Once several agents share a desk, task assignment, fact flow, and acceptance become system concerns.
Using the “market” of products has costs. A personal system brings some of that coordination under your control, which is the part that maps to Coase’s account of direction. You will not list every case in advance; many rules only become visible after a bad result. This resembles Coase’s incomplete-contract problem, but configuring software is not an employment relation and does not confer the legal authority he described. Efficiency is only part of the decision. The system also determines who owns the rules, and who gets to decide.
Coase also puts a ceiling on the firm, and the same warning applies here. A personal system that just adds agents will hit diminishing returns to the entrepreneur function: more organising cost, more misallocated effort, more of last week’s rule sitting next to this week’s. Roland’s four layers, sandbox, archive, and dead-skill cleanup are attempts to keep that internal cost down. A task belongs inside only while coordinating it there is worth more than leaving it in a product.
Storage is not enough
The usual answer, Roland says, is: subscribe to a stronger model, build a second brain, save the chats and files, search later.
Facts change. The more you save, the more you have to update, compare, and tell apart. Remembering what happened is not the same as knowing what to do next time. A fact gets revised — do you delete the old one? Two sources disagree — which one is live? Your preference moved — why is the old one still being retrieved? A method expired — how does the system know not to use it?
Memory can store events, but storage alone does not name the current version. A vector database can fetch similar text, but similarity does not resolve a conflict between two facts. More records mean more work: update, compare, delete, pin a version.
A “second brain” usually emphasizes storage and retrieval. Roland’s personal system also chooses tools, calls them, and tests new versions. Nobody can keep, check, and compute everything. You filter first, then decide with what you have. The system has to choose what stays resident, what is fetched on demand, and what gets deleted — and it has to keep evidence so a compressed context does not swallow the number and the source.
Four layers with different update rates
Roland splits the system by what the information is for, how fast it changes, and how far a change should reach. A fact can move without rewriting who you are. A project can enter a new phase without rewriting the house rules. A shared rule changes only after a test, then a person says yes.
Resident layer. Identity, mission, values. This is who is at work, and toward what. Each agent’s identity and goal live here. Tuesday’s events do not.
Rules layer. Standards every project shares: facts get checked, evidence is kept, execution stays inside the constraints. A rule update is tested first. A person decides whether it becomes the current version.
On-demand layer. The concrete facts and raw material for a task. Start from already-sorted diary facts; if you still need to verify, go back to the original chat, file, or data source. Use the cleaned version; keep a path to the voucher.
Project layer. The live job. Skills hold that project’s facts, decisions, progress, and its own acceptance tests — a macro brief checks sources, dates, and the calculation; another project has another bar. Shared standards sit in the rules layer. “Did we finish this job?” sits here.
Material can move between layers. A conversation becomes a diary; repeated lessons may become rules; a person updates the current version after testing. A review is for turning one episode into a method you can call the next time the same class of problem shows up. When a project ends, the specifics go to archive, methods that kept working go into rules, and dead skills get cleaned out.
A macro analyst and a student do not need the same number of agents. Both still need sources, standards for the work, and a clear line around judgments that remain human.
Updates need a boundary
Roland’s example: an agent that collects macro data.
Version 1.0 is: give it the task, let it search, let it write a summary. After a few runs you see the pattern. The numbers came from news paraphrase, not the official print. Different countries sit on different calendars. A revision is sitting next to the old figure. The context window kept the conclusion and dropped the original number and the source. You still have to check it yourself.
That pain writes the candidate for 2.0: named sources; every figure keeps source, date, and version; conflicts are kept and labeled, not averaged away; the summary can compress, the evidence stays; nothing proceeds until the project’s acceptance test passes.
The candidate runs in a sandbox and gets compared with 1.0 on factual error, missing evidence, and how much a person still has to fix. If 2.0 clears the bar, a person decides whether it replaces the current version.
The system proposes, tests, and records the difference. A person decides whether to ship the new version. Principles and values are the fence around that process, not another prompt the model is free to improve.
The useful output is a method that survives another run. Recurring problems can enter the next edition of the rules, while methods that fail are removed. Versions keep that change inspectable.
The API / CLI / token split
Roland’s last sentence is the one the thread is aimed at:
From now on, products and services will be divided by whether they offer an API, a CLI, and an access token. That line splits people into two kinds: those who can build their own system, and those who can only use a system someone else built. — Roland Wayne, thread linked below
In Coase’s last pages, the firm in the real world is close to the employer–employee relation: one party is directed, within limits; the other holds the right to direct. A product with an API, a CLI, and an access token can be called from a system you direct. A product without those interfaces keeps more of the workflow inside the vendor’s system.
Coase gives Roland’s argument a useful boundary: compare the cost of repeated market exchanges with the cost of organising the same work inside. APIs, CLIs, and access tokens move that boundary by making services easier to direct from a system of your own.