What happens when economic discovery becomes computational?

We spend extraordinary amounts of money and computing power searching for opportunities in financial markets. Some of the smartest engineers, mathematicians, and researchers in the world spend their careers building systems designed to identify small advantages, test them, and deploy capital. Much of the broader economy operates with nothing resembling that level of systematic investigation. Prices vary wildly. Distribution is inefficient. Entire industries run on outdated processes. New technologies create opportunities that nobody has seriously explored. I've been wondering what happens when we point that same research machinery at everything else. Quant firms have developed an entire discipline around research, backtesting, capital allocation, and managing strategies that eventually stop working. What if we applied that discipline to discovering and creating businesses? That would mean finding inefficiencies in existing markets and exploring an enormous, continuously changing space of possible products, services, transactions, and industries. Some opportunities are waiting to be discovered. Others don't exist until someone experiments with creating them. Historically, investigating these possibilities has required considerable human effort. Research takes time, validation costs money, and commercial execution often means assembling an entire organization. AI is beginning to change those economics. Making economic discovery computational Imagine a research organization investigating thousands of commercial opportunities simultaneously. Its agents study industries, examine pricing and supply chains, research emerging markets, and develop hypotheses about where economic value might be captured or created. Finding interesting ideas isn't particularly difficult. Figuring out which ones are worth pursuing, and then actually doing something about them, is another matter. I'd organize this research through directed acyclic graphs (DAGs), where some experiments can run in parallel while others depend on evidence from earlier work. Agent swarms explore competing approaches, investigate difficult problems, and challenge assumptions. Findings from one experiment might open entirely new branches of research elsewhere. Consider the invention of Post-it Notes. In 1968, 3M researcher Spencer Silver was trying to develop a stronger adhesive. Instead, he produced one that stuck lightly and could be removed easily. For years, he struggled to find a compelling use for it. Another 3M researcher, Art Fry, later remembered Silver's adhesive while trying to keep bookmarks from falling out of his church hymnal. The connection eventually became Post-it Notes. Even then, commercial success wasn't immediate. An initial launch in four cities produced mixed results, and 3M had to experiment with getting the product directly into customers' hands before it found broader demand. What interests me is the connection between two problems that originally had nothing to do with one another. The knowledge was already there. It took years, another person's experience, and further experimentation to turn it into a business. Imagine a research system that retains findings like Silver's and continually looks for applications in other industries. One swarm investigates possible uses, another studies customer problems, and others evaluate production costs and distribution. A promising connection can become a new branch of experiments instead of waiting for someone to stumble across it. The system might simulate the economics, develop a prototype, contact suppliers, or attempt to secure actual customers. Some assumptions can be tested against historical data. Others require experiments in the real world. Much of this execution is already possible with today's tools. Agents can write and deploy software, operate browsers, send emails, make calls, interact with APIs, and coordinate workflows. We still have reliability and oversight problems to solve, but we don't need to wait for some future agent-to-agent economy to conduct meaningful commercial experiments. Depending on the opportunity, very little human involvement may be required. Others will depend on specialized expertise, physical infrastructure, or existing operators. A disciplined evaluation process would begin with relatively inexpensive research. Promising results justify progressively more expensive experiments. At each stage, the system evaluates the evidence and decides whether to allocate additional compute, commit capital, revise the hypothesis, or move on. The goal is to investigate and act on far more commercial opportunities than conventional organizations can reasonably explore. The economics of experimentation Reducing the cost of research is useful. Reducing the combined cost of discovering, validating, and executing an opportunity changes which opportunities are worth pursuing in the first place. Consider a simplified model for the expected value of an opportunity: Here, $pi$ is the probability of commercial success, $Vi$ is the net value if successful before research and deployment costs, and $C{r,i}$ and $C{d,i}$ represent the costs of research and expected deployment. A real model would need to account for unsuccessful outcomes, capital constraints, timing, and risk. This is enough to illustrate the idea. Suppose an opportunity has a 1% chance of producing $100,000 in economic value. Its expected payoff before research and deployment costs is $1,000. If it costs $10,000 to investigate and attempt, the expected value is negative $9,000. If computation and automation reduce those costs to $200, the expected value becomes positive $800. The numbers are hypothetical. We can't assume cheaper experiments are equally reliable, or that we can accurately estimate the probability of success in the first place. Lowering the cost of experimentation doesn't just make entrepreneurship faster. It makes previously uneconomical opportunities worth investigating. An opportunity that couldn't justify hiring developers, building a team, or committing substantial capital might justify a relatively inexpensive computational experiment. Some discoveries could produce modest profits from temporary market inefficiencies. Others might reveal opportunities for entirely new products or businesses. Most hypotheses probably won't survive validation. That's fine if the organization can recognize that quickly and cheaply. What matters is whether systematic experimentation discovers more economic value than it costs to investigate and exploit. Compute becomes a capital allocation problem As more research, engineering, and commercial execution can be purchased through computation, compute itself becomes an increasingly direct input into economic production. A firm could investigate an emerging market, develop several competing products, test different distribution strategies, or allocate additional resources to an operation already generating revenue. All of those activities compete for the same resources. Where is the next dollar most likely to create value: investigating an uncertain hypothesis, validating something promising, or scaling a business that's already working? Some problems might benefit from hundreds of agents exploring competing approaches. Others require customer feedback, supplier negotiations, or real transactions. No amount of additional computation will make a customer respond to an email faster. The portfolio itself could look quite different from a conventional venture portfolio. A pricing discrepancy might generate attractive returns for a few weeks before competitors eliminate the advantage. A specialized software business might be worth owning for decades. The institution would need to decide which opportunities deserve more capital, which should be maintained, and when to exit. Businesses aren't liquid financial instruments. Capital can be difficult to recover, and obligations to customers, employees, and suppliers can't simply be closed like a trading position. The allocation process needs to account for these different kinds of assets, with their different risks, time horizons, and capital requirements. The institution becomes the asset I keep coming back to the possibility that the research itself could compound. Imagine an experiment in customer acquisition reveals an underserved industry. Operating in that market produces information about its customers, pricing, and competitive dynamics. That knowledge exposes an opportunity in vertical software. The software business, once operating, reveals inefficiencies in procurement or financing that weren't apparent during the original investigation. The original business generates cash flow while teaching the organization something about how the market works. One discovery leads to another. Successful operations can finance additional research. That research might uncover opportunities that wouldn't have been visible without the experience of operating the first business. Even failed experiments can contribute useful information, provided the organization captures reliable evidence about what actually happened. Over time, the firm could develop proprietary commercial intelligence, operational infrastructure, and relationships that improve subsequent research. There may also be an advantage to investigating such a broad opportunity space. Research in one industry could uncover applications in another, particularly as the organization learns to recognize relationships between technologies, business models, and markets. Information isn't automatically valuable because we collect it, and knowledge from one industry may not transfer to another. A compounding advantage depends on whether accumulated experience actually improves the firm's ability to discover and evaluate the next opportunity. If it does, the most valuable asset might not be any individual business the system creates. It might be the research institution itself. Where this might lead Agent-to-agent commerce could eventually reduce some of these costs further. As identity, communication, and payment infrastructure mature, autonomous businesses may be able to discover suppliers, negotiate routine transactions, purchase services, and coordinate directly with other autonomous systems. That could make certain markets more accessible and create entirely new ones. It could also eliminate existing inefficiencies as pricing and distribution become more competitive. Agents can already participate in meaningful commercial activity through tools built for people, so the thesis can be tested before this infrastructure matures. A more machine-native economy would change the opportunities available to the research institution. The question worth testing There are good reasons this might not work. Financial markets provide structured data and rapid feedback. The broader economy is messier. Customer relationships, distribution, regulation, and physical execution can dominate commercial outcomes. Perhaps discovering opportunities isn't the real bottleneck. Maybe the hard part has always been exploiting them, and even with cheaper research and software, the economics won't improve nearly as much as we expect. There's also a real danger of generating enormous numbers of convincing but commercially useless hypotheses. Quantitative finance has spent decades dealing with overfitting and strategies that look extraordinary in a backtest but fail when exposed to actual markets. An autonomous research organization would face many of the same problems. The central question is whether it can consistently discover and capitalize on opportunities at a lower total cost than conventional methods. Can it produce superior risk-adjusted economic returns? Does additional compute improve those results? Does accumulated research make the institution better at subsequent discoveries? What interests me is whether the discovery and creation of economic value can become a continuous process that scales with computation. The institution I'm imagining would investigate opportunities across the economy, validate them through real experiments, and allocate capital according to what the evidence supports. Some discoveries might produce short-lived commercial strategies. Others could become businesses worth owning for decades. Successful investments generate capital, while research and operating experience inform whatever comes next. The individual opportunities come and go. The institution retains what it learns. I don't know whether the economics will work at scale. Many of the technical pieces already exist, and the remaining questions are ones we can begin answering through real commercial experiments. I think there's a new kind of economic institution worth building here. One whose primary business is the systematic discovery and creation of economic value. --- Further reading - 3M. The history of Post-it Notes. - Stenger, G. & Dewey, R. Financial Times, on the convergence of quantitative trading and AI laboratories. - Lu, C., et al. (2024). The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery. - Bailey, D. H., et al. (2017). The Probability of Backtest Overfitting. - Hayek, F. A. (1945). The Use of Knowledge in Society. American Economic Review, 35(4), 519–530.

The quantitative firm

LinkedIn

A bot in every tool is just SaaS sprawl with better models. Don't rent how your company works.

The fleet nobody wants to manage xAI just shipped Team Bots. Meta just shipped Muse for Small Business. OpenAI just shipped dots. The AI employee is becoming the default picture of how a business uses intelligence. I have used most of what is out there. Grok Bot and its Team Bots. Muse. Codex. Claude Code and Claude Cowork. Hermes Agent, OpenClaw, Gemini. Every SaaS product you already pay for now ships with a copilot. Some of it is great. All of it is powerful, and I am extremely bullish on what it can do. I still think the industry is building toward the wrong end state. The agent is not the problem. Having to know which agent to ask is. Every vendor is selling you more of them, each with its own memory and its own idea of how your company works. Some people build one agent to manage the rest. That helps one person. The next person builds their own, and the company is back where it started. Try it. Ask your agent to build one tool that runs the same way every time and that everyone at your company can use, with the same rules and the same permissions. See how far it gets. What is missing is one layer in front of all of them, so anyone can just ask. And most fleets come priced per seat, with everything your company teaches them living in one vendor's tools. That part is more dangerous than it sounds. We spent twenty years scattering company functions across tabs. Then AI arrived and the answer was to put a bot in every tab. Now every tab has someone to talk to, and you still carry the context between them. We gave the fragmentation a personality. I think we can aim higher. The company is the interface What a company needs is a persistent organizational runtime. That is a layer that knows how the business works, carries that understanding forward, and runs work across the tools the company already uses, inside boundaries the company sets. To the person asking, it is one thing to talk to. Under the hood it is not one giant agent, and it is not moving the company into one database. Subagents, specialists, small decision models, and plain deterministic tools each do the part they are best at, coordinated by the layer. GitHub stays the source of truth for code, Salesforce for customers, and some obscure internal database for the one thing that matters more than either. Specialist tools should stay specialized. The mistake is making people orchestrate any of it. The runtime knows what exists, where truth lives, who is allowed to act, which workflows apply, what happened before, and what requires approval. Then it gets the work done. That might mean a coding agent, a SQL query, a deterministic workflow, a small local model, a temporary specialist spun up for one task and retired, or a human. The person asking should not know or care which. It lives where work already happens. Tag it in Slack. Mention it in GitHub. CC it on an email. Different doors into the same system, with the same rules and the same accumulated experience. Every door has the same lock. It acts as the person asking, with their permissions, never its own. A message from outside the company is something to read, not something to obey. Anything that cannot be undone waits for a person, until proven otherwise. A request can start in Slack and pass through a database, three models, a specialist agent, and a human approval. You orchestrate none of that. You asked the company. The company figured out the rest. Personal agents fit here too. Yours knows how you write and how you like to work. The organizational runtime knows how the company works. Your agent should operate through that layer, with your identity and permissions, following the company's rules. Bring whichever one you like. Your personal agent should not own how the business runs. Neither should mine. People leave, vendors change, models improve. The company's experience has to outlive all of us. Ask it. Delegate to it. Program it. You do not just ask it questions. "Get me ready for Acme." "Figure out why this customer is pissed and fix whatever we reasonably can before I call them." "From now on, when this happens, do this, unless one of these conditions is true." "Every Friday, tell me which of our workflows should move to a cheaper model." "Get me ready" should mean something specific. Read the recent correspondence. Check the contract, the open issues, and the commitments we made. Work out what changed since we last spoke. Resolve what can be resolved within the agreed boundaries, and tell me what still needs my judgment. I should arrive at the call ready to decide. I should not spend the first twenty minutes being the integration between five pieces of software. The standing rule matters just as much. Most companies are full of work that happens only because someone remembers to check something. The runtime should watch for conditions, run the recurring workflows, chase what did not happen, and escalate the exceptions without waiting for a prompt. Take the month-end close. It knows what has to happen, pulls from the systems of record, reconciles what it can, chases missing inputs, runs the standard checks, and prepares the package. The handful of exceptions that need judgment go to a person. Continuous work. Bounded decisions. Exceptions to humans. Humans should stop being the workflow engine. The part nobody wants to hear Giving your team an agent is easy. Teaching it what "done" means at your company is where the work starts. Where does customer truth live? Which Slack channel matters? Who owns this process? When the CRM disagrees with the signed contract, which one wins? What does "ready to send" mean here? Which exceptions are normal, and which should wake someone up? What did we decide six months ago, and why? That knowledge is scattered across people, threads, docs, databases, and a thousand unwritten conventions. Humans carry most of the connective tissue in their heads. Someone has to map the workflows, encode the conventions, define the boundaries, and connect the systems. And because the company never stops changing, someone has to keep spotting what has drifted and keep it maintained. That work is unglamorous. It is also the product. The software is only half of it. The runtime should carry much of that maintenance itself. It should accumulate understanding through the work, from decisions, corrections, approvals, exceptions, and outcomes. A transcript records what was said. Operating experience records what was tried, what worked, what failed, and how the company chose to handle it next time. When someone corrects it, the system should record what changed, where the correction applies, and how to check that it holds. Otherwise the company pays to explain the same lesson forever. Every workflow after the first has less to learn from scratch. That is where it starts to compound. Investors have started calling this a record of decisions, meaning not just what happened but why. That is right, and it is not enough. A record is still passive. The layer should read its own history and propose the next change. How it improves without breaking anything The runtime should also get better at operating itself, and the mechanism is not exotic. Daily or weekly, it reviews the work that passed through it. The conversations, the corrections, the exceptions, the task that took three tries. Then it proposes. A request that keeps coming back becomes a candidate skill. A failure that repeats calls for a guardrail or a specialist. A workflow that spends frontier-model money on routine decisions gets a cheaper path. Work that comes out the same way every time stops going to a model at all and becomes a tool, which costs almost nothing to run. Each week it also looks outward. It checks what was released, uses benchmarks to shortlist candidates, tests the promising ones against representative company tasks, reads the inference bill, and gives an estimate of which workflows are worth trying on a new model and which are not. Nobody has to keep up with the release cycle to benefit from it. There is no prize for sending every decision to the most expensive model. Some work needs frontier intelligence. Some needs a small model. Some needs a query and a rule. The runtime should be able to tell the difference. The building blocks underneath will keep changing. I have already watched it happen in my own build. A better component arrived and absorbed tool calling, routing, memory, and briefing work that used to take several systems, at lower cost. The architecture changed. The work the system was responsible for did not. That is exactly why the runtime has to sit above the primitives. Every one of those is a proposal, not a change. Models get compared. Tools get evaluated. Changes get tested. Material changes follow the company's own approval rules. The system can improve its machinery without silently rewriting how the business operates underneath everyone's feet. None of this means it is never wrong. Once in a while it will pull the wrong context, misremember a decision, or automate something that needed a person. When it does, these are the questions that matter. Who can see what happened and why? Can you stop a workflow? What happens when something fails halfway through? Does a correction change future behavior? Does it know when it needs approval? And six months from now, can you find out who asked for something, what it did, and who said yes? Once this layer runs meaningful parts of a business, "it usually works" is not enough. You need the organizational equivalent of regression tests. The models are probabilistic, so the wording changes from run to run. The behavior should not. A suite of real company scenarios, run whenever a model or a rule changes, checks whether it asks before sending, trusts the right source, respects permissions, and keeps last month's corrections. Models change underneath. The company's expected behavior should not, unless the company decides to change it. Trust in this category will be earned by how these systems handle being wrong, not by how impressive they look on day one. Who owns the layer The enterprise world already sells pieces of this. Some index everything your company touches. Others govern a vendor's agents. But indexing your company is not running it, and governing agents is not knowing how your work actually gets done. They are pieces, priced per seat, on someone else's platform. The organizational layer has to span whatever the company uses, including the obscure database and the systems nobody ever built a connector for. Think about what it eventually contains. Your customers, your workflows, your operating history, your exceptions, your approvals, your failures, and the unwritten decisions that make your company different from every other company. If all of that accumulates inside whichever AI vendor is winning this quarter, governed by their API terms, their pricing, and their definition of portable, you have put your IP in someone else's sandbox. Ask for it back and see what you get. Most will let you download your chats, and some will hand you a paragraph summarizing what they remember. None of the hosted ones hand you the working memory, the skills, and the tools your team built, in a form something else can run. That is the part that should follow your people and stay yours. You have heard this warning before, about your CRM, and you were fine. This is different. Your CRM holds data, and data exports. This layer holds behavior. Which rule applies, which exception gets escalated, which correction stuck, who gets to approve what. Behavior does not come with a standard export. There is no CSV that reconstructs how your company works. If your AI vendor can hold your company's institutional memory hostage, you architected it wrong. Team Bots gets an important part right. Corrections should improve future work for the whole team, and xAI's own case study shows that happening. The next question is whether that operating experience can leave the platform. The launch does not say. What it does say is that the shared context, skills, and memory live inside their product, administered from their dashboard, under their terms. The fleet and the exit cost in one box. Muse for Small Business connects to your Slack, your CRM, and your ad accounts, learns how your brand sounds and what your customers ask, and keeps all of it in Meta's cloud. OpenAI went further at DevDay. Alongside dots, it launched ChatGPT Space and Pages, a shared workspace where your team, your files, your documents, and your dots all live inside ChatGPT. These are good products. They are the wrong place for your company to live. That does not mean every company racks its own servers. It means the company controls the durable layer, meaning its operating rules, its accumulated experience, its permissions, and its ability to move the intelligence underneath. Exporting the chat logs and the skill files is not enough. A real exit has to carry the accumulated corrections and the tests that prove the company still behaves the same after a model swap. You should be able to change vendors without teaching your company how to be itself again. Use whatever model, tool, or specialist is best this month. The only thing that has to last is the part that knows how your company works. You should not have to trust anyone with this layer, including whoever builds it. It should run in your accounts, in repositories you own, and eventually on models you run yourself. Whoever builds it should hand you the keys and remove their own access. If they disappeared tomorrow, it should keep running. Underdog just launched on exactly that bet, that today's frontier intelligence reaches the devices you already own within six months. When it does, a routine decision costs about as much as the electricity it takes to make it. The companies that own this layer when that happens will move their work onto nearly free intelligence the week it arrives. The ones renting it will be waiting on a vendor whose business depends on them never switching. A layer you own does not care whose model it runs on. Whoever you pick, the work is the same. Someone has to sit with your people and map how the company actually runs, what counts as done, and where the guardrails go. So pick a partner the way you would pick any partner. Will they be in the room while it is mapped? Will they pick up the phone after? Will you be a priority to them or a rounding error? And can you walk away with everything if they stop being worth it? I think this is what an AI-native company looks like, and it has less visible AI, not more. Workflows that are observable, testable, and delegated. Humans responsible for judgment and exceptions. A company that keeps operating and improving as its tools change. What excites me is what a company could do when its people no longer carry every process in their heads. One person operating like three. Nobody spends their week on the mundane, manual work they were never hired to do. Someone leaving no longer means starting over on everything they knew. A small team takes on more without hiring a layer of people just to keep track. The owner spends the day on where the company should go, not on whether yesterday's decisions actually happened. That is the company every owner deserves to run. It is why I am building Scriptorii. You ask the company. The company figures out the rest.

Parker Esmay

Writing