“And we gave it to three landlord-tenant attorneys. And we just said, nothing about AI. We just said, here is a question that a potential client asked, and here is an answer. Would you send this answer without any edits to that client? Would you be fine with that? You know, is that ethical? Is it a good enough answer to send? And 86 out of 100 was yes.”

That was the whole product. No software, no interface, no demo. And the model was bad. In a longer interview Weinberg describes the GPT-3 API of that moment: no instruction tuning, a neon green box covering your output, and if you forgot the punctuation at the end of your prompt it would autocomplete your sentence instead of answering it. His summary: “it was really rough.”

Some things I found awesome:

The questions weren't theirs. Real people on Reddit describing their actual apartment problems, tagged and taken as-is.

The AI label was removed on purpose. Weinberg's words: “We didn't say anything about ai, nothing.” In 2022, telling a practicing attorney that an answer came from a language model would have probably sunk the whole convo anyway.

The question had liability in it. Not "is this good" or "is this impressive." Thumbs up meant you would send it to a client with zero edits. Thumbs down meant tell me what you'd change. I suppose that prices in malpractice risk, professional ethics, and the reviewer's own name, which no accuracy score does.

Another curious thing to me: Weinberg was a securities and antitrust litigator at O'Melveny & Myers. He makes the point in that interview that a securities guy knows essentially nothing about landlord-tenant law in a given jurisdiction, even though people assume lawyers know all of it. So he picked a domain where he was not qualified to grade the output.

Like so many things in AI, I always think about what being wrong costs you. In the Reddit landlord scenario and the testers not much! Once it ramps up, it can cost a lot. But you can prove things out so fast nowadays. Free questions, a public API, three friends, no product. Harvey is a great success story in a lot of ways but good on them for their scrappy-ness.

The “wait calculation”, is what Ethan Mollick calls it. If technology is improving quickly enough, someone who starts later might finish before you. I liked his interstellar voyage example: a ship launched today could eventually be overtaken by a faster ship that left years later.[1]

It's pretty unnerving really, when you're trying to decide where to spend the next few months.

I liked one of the comments on the article: A project already underway can adopt a better model. It can bring along the understanding of the problem, the data it has gathered, and the ways it has learned to judge the result.[1]

You can change the engine!

Nothing is fixed in this crazy world, so why accept your current trajectory, speed, motion?

Mollick describes spending years building teaching games before AI made much of their implementation easier. He also ack'd:

“We could never have built these tools if we didn’t do the hard intellectual work of learning how to make them with our own limited human abilities first.”[1]

The implementation became easier to replace. The work had still taught them something they needed.

That's why going through the paces with agent workflows for specific business problems is still important, in my opinion. You gotta get the agent traces, the data, the systems of intelligence down. It's just hard and nitty-gritty work. At some point someone else comes along and can use that and go faster, that's the unnerving part.

Of course, changing models is not necessarily effortless. The replacement needs testing. Some work may have to be redone. Spending months compensating for a limitation that could soon disappear deserves scrutiny!

Fear of that waste can make all effort look equally disposable. Understanding what customers mean, watching where employees hesitate, and learning what makes a result useful belong in the calculation too.

If a better model arrived tomorrow, which parts of this project would I be glad we had already done?

If I change out the engine, or even re-do a large swath of things, can I move even faster with all these learnings we've gone through?

What can't the other guy do or what doesn't he know, as he's speeding by me?

Just questions I'm pondering right now.

Sources

[1] https://www.oneusefulthing.org/p/the-lazy-tyranny-of-the-wait-calculation — Ethan Mollick’s essay and Malcolm Sharpe’s comment.

It made me want to build an online Apollo software library: working recreations of the software behind the missions, each shown next to the documents it came from. This program is the first entry. You can try it here, and the code is on GitHub.

What the program did

The main source is a 1972 NASA report, TN D-6853, by Charles T. Hyle and Alfred N. Lunde. It describes a "somewhat dormant" program, first written for Gemini rendezvous and docking studies, that MSC revived and extended for Apollo. It ran in FORTRAN V on a UNIVAC 1108. The output was microfilm: a camera photographed pictures made of dots and straight lines on a cathode-ray tube. The frames were printed for mission documents and crew charts, and some were cut together into a film, View from a Spacecraft.

The report lists how the missions used it:

• For Apollo 8, it showed that the lunar horizon's position against a mark on the window could support an onboard go/no-go check for lunar orbit insertion.
• The Apollo 11 crew asked for views through the command module's scanning telescope and the lunar module's alignment telescope, and used them to choose stars before the flight.
• For the landing, views through the LM windows showed which craters should cross which marks on the landing point designator, and when.
• On Apollo 13, views of the Earth were the only attitude reference for a midcourse correction.

The Apollo 11 edition of these views, 69-FM-197, runs 321 pages. It credits G. B. Roush with developing the program's major analytical tool.

No source code

The program's source code isn't known to survive in public. What does survive is a lot of its output and a good description of how it worked. So the recreation works backward: it recomputes each published figure from the inputs printed on it, then checks the result against a scan of the original.

The inputs come from the 1969 documents themselves. 69-FM-197 prints each view's time, platform alignment and gimbal angles, plus the LM window geometry and a sequence of frames through the powered descent. The Apollo 10 edition, 69-FM-107, includes the program's 1,078-star catalog as a line-printer table. OCR recovered 826 verified rows of it. The Apollo 11 Mission Report gives the spacecraft's position and velocity at points through the flight, and the Apollo 11 press kit gives the dimensions for the vehicle models.

The rest is public data: the Yale Bright Star Catalogue, the guidance computer's own star table from Virtual AGC, Natural Earth coastlines, and lunar crater positions from the IAU/USGS gazetteer.

How it's built

I had Claude Code build it. I gave it the report and the goal, and let it work through the whole plan on its own and report back at the end. It took a day.

One rule shaped the project: never change an input to make a comparison pass. Each comparison has a pass mark written down before the scan is measured. When a comparison fails, the failure stays in the results with its analysis. Where the documents never printed an input, usually the spacecraft's attitude, the recreation solves for it from the figure and calls the result a fit instead of a prediction. Every decision is in a ledger in the repo.

The engine is TypeScript with no framework, and it follows the original's two halves. TN D-6853 says the first half integrated trajectories for up to four vehicles, by Encke's or Cowell's method, and the second half drew what an observer would see.

The recreation integrates the trajectory with Cowell's method, starting from the Mission Report's state vectors and never integrating across a burn. It points the spacecraft with a platform alignment matrix (REFSMMAT) and gimbal angles, the same quantities the guidance computer used, so a figure's printed inputs go in unchanged. The drawing side covers the star catalogs, the Earth and Moon as globes with coastlines, craters and the day/night terminator, the window outlines, and hidden-line models of the LM and the S-IVB.

The output is SVG, in a microfilm style or the style of the printed reports. There's also a 132-column line-printer version, because the report mentions the program could print "crude printer-plot images" for a quick look before the microfilm came back.

On the site, you can compare each figure with its scan, change the time or the gimbal angles and watch the view recompute, and play the film. The film is computed in your browser one frame at a time, by the same engine.

What it found

Some of it matches well. Figure 3b, twenty minutes after 3a, comes within 0.52° RMS of the printed positions with nothing fitted, against a limit of 1°. The Earth views in Figure 6 match their disc, terminator and 30 coastal landmarks.

Some misses turned out to be problems in the original documents:

• As printed, Figure 3c points the telescope the opposite way. Both 69-FM-197 and TN D-6853 print the inner gimbal angle with the wrong sign, and both label the star Alphecca as Alpheratz. The figure's own stars show both errors.
• Seven rows of the Mission Report's trajectory table are misprinted or inconsistent with the rest of the table.
• Figure 1 draws the Sun and Venus about where they would have been three days after launch. The best explanation in the ledger is a study run for a later launch date, but that's unconfirmed.

Some misses are still open. The biggest is the horizon. On Figures 1, 2 and 3b, the 1969 program drew the Earth's or Moon's horizon as a clean circle much smaller than the true one, and the recreation hasn't recovered the rule it used. Figure 7 doesn't match its own printed times. The star catalog stopped at 826 verified rows, short of the project's target of 1,000. All of these stay in the results.

If you know anything about that horizon rule, or where the program's listings ended up, the repo is the place.

how do packet-switched teams, or companies, or AI agent networks, communicate across their boundaries without any of them being “in charge” of the others?

Could independent businesses get some of the benefits of operating as a larger company without sharing an owner?

I've written before about AI helping small businesses stay independent. Making it easier for those businesses to work together seems like another part of that opportunity. I've seen some first hand examples of the difficulty in coordination between businesses (part ordering, multi-layered service and support, etc) that makes this a compelling thought exercise.

Sam describes some of the work AI could take on:

AI can do this rote work: given a task and the people who will do it, surface the assumptions that need to be agreed on before anything flows, and check to make sure the goals were met consistently.

Think of a contractor bringing in a specialist for part of a job. An agent could help prepare the scope, check availability, and keep both businesses informed when the schedule changes. The owners still agree to the work and control what information they share. They spend less time chasing details. It seems like it would make an existing business relationship easier to manage.

Sam also makes a point here I thought was interesting:

The internet’s apparent freedom runs on extremely strict, hard-won, boring contracts between machines.

For the businesses involved, someone still needs to agree on payment, ownership of the customer relationship, and who handles a mistake. Easier coordination doesn't remove those responsibilities.

Whether this can support larger networks of independent businesses is a curious question to me. Sam's illustration is cool and is making me think different about the approach. One shared job seems like a good place to find out: less administrative work between two businesses, with each owner still in control of their part.

Is there a formula for that? No idea, but I played around with it a bit in my head. The best proof I can provide, I'll sum up this way:

Compounding momentum eventually crosses every finite threshold.

Start with positive momentum and let it compound at a steady positive rate:

$M_0$ is your starting momentum, $r$ is the growth rate, and $t$ is time. A door opens when your momentum reaches its barrier, $D$:

Keep that compounding going, and any fixed, finite barrier eventually gets crossed. You don’t have to start above the threshold to reach it. (Caveat for the nerds: Obviously there's always some unseen barrier in physics..but you get the point).

Regarding AI, startups, and this new crazy world we live in: A capability can improve for a while before it becomes reliable or affordable enough to build a business around. Something that was too expensive to attempt becomes a reasonable thing for a small team to try. And that's exactly what this new AI stuff gives us. Even services now has a completely new set of scaling laws, which I don't think anyone has fully proven out yet.

Anyway back to momentum: A team can build momentum of its own. Getting a working product in front of a customer sooner means learning sooner. Feedback improves the next version. A customer who gets value can become a reference for another. Each win can make the next one easier, while improvements in AI expand what the team can take on. This is all well known and written about but with AI, the speed is so fast that you end up just going around barriers sometimes and not even consider them anymore.

The math assumes the compounding continues and the barriers stay fixed. A startup still has to find demand and survive long enough to benefit. But today’s limitations aren’t permanent. There’s a reason to keep working on a problem you understand, even when some of what you want to do remains out of reach.

I have plenty of Apple experience from my Appcelerator days. But on the Mac, the signing shenanigans alone often made a small customization feel like more trouble than it was worth. I’d think about making something, then go back to working around it.

Omarchy has changed that for me. With Quattro’s plugin system, I can change pieces of the desktop without maintaining my own version of the OS. AI makes it easier to turn those ideas into something I can try, adjust, and use.

I’ve published Island, a morphing widget for desktop controls and activity; Panel Notes, for keeping notes alongside the app I’m using; and a grid wallpaper picker just because I wanted to try a different approach to quickly switching wallpapers. They’re small things, but being able to make them changes my relationship with the computer. I don’t have to stop at the options someone else anticipated.

I've got some bigger ideas I've always wanted that I'm working on this weekend just for fun: RewindAI for Omarchy (I miss that app a lot), a Screenflow-like video editor, an intelligent background service that tries to recommend and predict what you should do next and with one keyboard shortcut go and do that (Jev-like intelligence), and a music notation editor for my daughter.

I previously wrote about a computer that learns how you work. Making these plugins has given me another way to explore that idea. An open, changeable OS gives me room to work. AI reduces the effort of making something fit...honestly it's effortless. Suddenly a "I wish it just did X but I don't have the time" turns in to a side quest agent and prompt that ends up just working with almost no time investment at all.

I can see this becoming useful well beyond people who enjoy tinkering with desktops. A small business could afford a computer shaped around its work, with interfaces and tools that change as its needs change. It could keep its data, workflows, and the knowledge accumulated along the way, even as it replaces the software or models helping with them. That's a bigger picture thing of course but my point is it lets me approach a computer with a different viewpoint.

Making changes I used to put aside makes it easier to use my imagination.

People are not going to have as many tabs open in different tools as they have historically. That experience is going to consolidate, but the vertical capabilities those tools provide will remain valuable.

A lot of B2B SaaS is good at showing you all the work you still have to do. The owner can see which customers need a follow-up and which jobs are waiting on an estimate, then spend the evening working through them. The software helps organize the work, but still expects someone in the business to do it.

Agents can actually do work. An accounting system and CRM are still useful, but for the agent that uses their capabilities to prepare something, follow up, or update the records. It is related to what I wrote about in No one can show me how: an owner wanting a job off their list, without having to adopt and manage another workflow. i.e. I agree with the experience consolidation above. It actually needs to happen.

Hedin also connects that with the context a system holds:

“It should have as much context as possible about you, your company and the world around you,” said Hedin. “Then it needs the capabilities to perform both general tasks and actions that are specific to your organization.”

In a small business, much of that context lives with the owner. They know why a customer gets different terms, or why last year’s estimate is a bad comparison for this job. They connect what the software records with what they know about the business.

An agent needs access to that reasoning, and a way to retain the owner’s corrections, if it is going to do useful work across those systems. Otherwise, the owner is still reconstructing the situation and explaining it every time.

Hedin makes another point I agree with:

Making sure they are well connected, built correctly and reliable is the hard part.

An owner needing help with a job should not have to figure out how to connect all those pieces and make them dependable. In reality, they have no desire to do that. They don't wake up in the morning and think "I can't wait to use someone's SaaS".

There's plenty of value along the way to full automation btw. As I wrote in What is the agent’s work worth?, preparing a useful estimate for review can save hours even when the owner still needs to adjust it. The relevant records and calculations should already be in front of them, with the assumptions that need their attention made clear. They can spend that time deciding what to approve instead of assembling everything from scratch.

An agent can prepare an estimate, or push through a detailed work order to 90% completion, with the last mile needing a quick expert review. There's a lot of folks talking about agents like they can do "100% of all your work, run your business entirely!" Some of that is true but humans can't even "fully run a business automated" without the owner's involvement anyway. So the framing can be deceptive and feel uncanny valley. Getting most of the work done and leaving the last mile to a person can be a very good arrangement. It depends on what that last mile involves.

The agent might gather the site notes, find comparable jobs, pull together material costs, coordinate inventory, and prepare a draft. The owner reviews the assumptions, changes the crew assignment, and adjusts the margin before sending it to the customer. If that preparation would otherwise have taken hours, the owner can come out well ahead even after reviewing and correcting it.

Well, then what is an agent's work worth? What's a person's work worth? It depends!

Tugce Erten and Sarah Wang recently argued that AI applications should price the recognizable work they deliver rather than the tokens they consume. They distinguish between selling model access, selling useful work, and selling an attributable business result. They also point out that credits do not help much if they are only tokens hidden behind another currency.

While we're all trying to figure out what billing unit to assign to an agent, ask this question: What has the agent actually contributed to the job?

An estimate is part of a conversation

Consider what happens after the owner sends that estimate. The customer comes back and asks what it would cost to leave part of the work until next year.

Now the estimate needs to change. Some materials come out. The crew may need a different amount of time. Splitting the work into separate visits might introduce costs that were not there before. The agent can help work through those changes, with the owner reviewing the result again.

A revision is not automatically evidence that the first estimate was wrong. The customer changed the request. Even with a person preparing everything, this back-and-forth can be a normal part of reaching an agreement.

The owner's earlier changes need the same distinction. Choosing a different margin may be a judgment call. Adding a material the agent omitted from the original scope is a correction. Learning that access to the building is restricted is new information that may change the plan.

And this is all happening while the operator has 4 more visits to make, he's 8 estimates behind, and phone calls are coming in!

Humans and agents need to handle all of those situations, but the agent intelligence should distinguish corrections from judgment calls and changes in scope or information. And note that producing another version of the document doesn't automatically count as more value delivered nor it was a mistake or not valuable work.

The useful work is helping the owner arrive at an estimate they can stand behind, including the revisions needed to get there, fast and with minimal involvement.

The last mile still counts

There is a big difference between reviewing a useful draft and rebuilding an unreliable one.

If the agent shows which previous jobs it used, where the prices came from, and which assumptions need confirmation, the owner has something they can inspect. They can spend their attention on the parts that require experience or a decision.

If the same draft contains plausible numbers with no explanation, the owner may have to reconstruct the estimate to find out whether it is safe to use. A finished-looking document can leave almost all of the original work intact, with the added burden of finding someone else's mistakes.

The question is whether the work left for the owner is smaller and more manageable than the work they started with.

The cost of being wrong includes what happens before someone notices. Saving preparation time matters, but so does making consequential errors easier to catch. A draft that flags an unknown gives the owner a chance to resolve it. Quietly filling the gap with a guess can make the estimate look more complete while making it less useful.

“Human review required” is a reasonable boundary for an agent. It still needs to give the human a practical way to review the work.

What are we paying for?

Preparing a useful draft, producing an owner-approved estimate, winning the job, and making a profit are different contributions.

An agent might do the first well while the owner remains responsible for approval. Winning the job also depends on the customer's budget, competing bids, and other things the agent does not control. Profit depends on what happens when the company performs the work.

It does not have to claim credit for winning the customer to be worth buying.

But the promise should be clear. If a business pays for an estimate ready for review, what condition should it be in? Which checks are still the owner's responsibility? If the agent misses something it was supposed to include, does fixing that consume more of the customer's credits? A customer changing the scope is a different reason to do more work than the product repairing its own mistake.

In No one can show me how, I wrote about starting with a job the owner wants gone. That remains a useful direction. But the whole job does not have to disappear before an agent earns its place on the org chart. An owner who gets hours back and can still exercise judgment at the right moment has received something valuable.

I would want to know whether the owner can prepare a sound estimate with less effort, handle the customer's changes more easily, and understand what they are approving. If all of that leads to an owner that doesn't have to stay up to 2am working through a backlog of estimates, that's a great start for an agent.

Don’t divide your attention: focusing on one thing yields increasing returns for each unit of effort.

We tend to price a new idea by its visible cost. A few hours each week. One person for a month. A side project that will not interfere with the main thing.

I suppose that assumes every hour has equal value.

Existing work carries accumulated context. The team knows what it has tried, where customers hesitate, which details matter, and what looked promising but failed. Feedback arrives faster because people know what to look for. The next hour can be worth more than the first simply because of that accumulation.

A new project begins lower on the curve. It needs context, vocabulary, trust, and its own feedback loop.

After ChatGPT launched, it was growing quickly, but the growth felt unstable and perhaps low-value. People inside OpenAI were discussing five or six other things they could pursue instead.

Peter Thiel told Sam Altman:

“It’s an obvious mistake to do anything but this.”

Thiel compared ChatGPT’s open text box to Google’s. People could type almost anything into it and get something useful back. It was growing, unusually flexible, and did not fit the prevailing Silicon Valley wisdom.

He was looking at the evidence already in front of them. Something rare was working before OpenAI had a clean explanation for why. Dividing attention among five or six other directions would have ignored the clearest signal they had.

Altman said they went “super hard on ChatGPT.”

“This could be good too” is a low bar. When something is working, the new thing has to compete with the next return on the current work, not its first return.

Before adding another project, ask what its first hour will replace.

“I go to a lot of these business mixers and they're always telling me how AI can change my business but no one can show me how.”

Jason Freedman recently described a startup pitch that missed for the same reason. After seeing the startup's interface, AI workflow, and assistant, he wrote:

“I’m not interested in making a big shift to how I do things. I don’t care about new UIs. I don’t want to be transformed.

I just want to pay for this particular ask on my to do list to go away.”

He was willing to pay the full services price if the startup could do the work as well or better, and faster, while using little of his time. The startup was charging like a typical B2B software product and still asking the customer to carry the load: adopt the tool, learn the interface, manage the process, and inspect the result.

He was looking for more value than just a login to a series of tables, charts, and workflows. He just wanted the problem to go away.

Nicolai Moelholm commented and pointed out the mismatch, which I appreciated:

Founder: “Our AI will transform how you work.”

Customer: “I was actually hoping to never think about this task again.”

Paul Graham described the founder's side of this problem in Schlep Blindness:

“A company is defined by the schleps it will undertake.”

Stripe is his example. Fixing online payments meant dealing with banks, fraud, security, and regulation. Those were not side issues that appeared after the software was finished. They were part of the problem, and they frightened other founders away.

AI startups can develop their own version of schlep blindness. Building an assistant and a self-serve workflow keeps the customer's bad records, exceptions, existing systems, and judgment at a distance. Taking responsibility for the job brings all of that into the product.

Graham described how this worked at Viaweb in Do Things that Don't Scale:

“Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks.”

He made the same point again recently. Asked how founders can build huge companies without being overconfident, he answered: “Incrementally.” He followed with:

“You put your head down and work. You focus on solving one problem after another. Gains accrue exponentially. And then you lift your head up a few years later and look around, and you're amazed at what you've built.”

That seems like the practical path for AI inside small businesses. Start with one job the owner wants gone. Do the schleppy work. Learn what the business actually requires. Keep what the job teaches. Then earn the next job. Which in the age of agents, I believe will actually help scale this work better than previous attempts in the B2B SaaS world.

The crazy thing to think about: a business may change after enough of those jobs disappear. AI agents can make this possible now.

I recommend people look at indie game postmortems (there’s a lot on Reddit, YouTube)

A recurring theme: “It turns out I was just making games for other indie game devs, and I found out too late they don’t actually buy games”

i.e. The people admiring the work are not the customer.

Ben's reply was to Sunil Pai’s joke about an AI agent factory that can make anything but is “mostly using it to improve the factory.” It's pretty funny but also the kind of truth that is a little painful (Like watching HBO's Silicon Valley and realizing you've been a part of some of those episodes in real life).

The "factory" is impressive. It is doing real work and getting better at doing it. The missing part is an outcome anyone outside the factory wants. i.e. Nobody cares.

Software teams with a bit of product psychosis fall into the same loop. They build something technically excellent, try to use it every day, improve it quickly, and treat that activity as evidence that a market exists or that people think it's good or cool or useful.

This is where dogfooding starts becoming a detractor.

A buddy of mine recently had a visceral reaction to the word "Dogfooding" because he had never heard of it, so here's an obligatory definition in case it's new to you: Dogfooding is the practice of using your own product inside the company. Bugs interrupt the builders’ work. Rough edges become difficult to ignore. The product has to survive daily use internally, first, instead of an outside demo.

It's useful for sure. Dogfooding shows where a product breaks under sustained internal use. It says little about whether an outsider understands it, has the same problem, or will pay.

Nielsen Norman Group describes internal use as a kind of usability upper bound. If employees struggle, customers will probably struggle too. However, employee success does not carry the same weight. Why?

Employees know too much.

They know why a term was chosen, where the configuration lives, which warning can be ignored, and what the unfinished behavior is supposed to become. When something goes wrong, they can message the person who built it. In their mind an issue can be small and easy to fix while to the user it looks insurmountable.

Researchers call this the curse of knowledge. Once we know something, we struggle to predict how someone without that knowledge will interpret the same situation. Better-informed participants in the original experiments could not fully set aside what they knew when estimating the judgment of less-informed people.

Employees also use the product under different conditions. They may be expected to use it, receive it without paying, and tolerate instability because they know what is coming next. A customer may need to migrate data, persuade a manager, pass a security review, train a team, or put their reputation behind the decision. In business software, the daily user may not be the buyer or the person carrying the risk.

Internal feedback can gradually shape the roadmap around the company itself. Employees are available, articulate, and unusually fluent in the system. Their requests are easier to collect than the problems of customers who have not adopted the product or gave up before anyone talked to them.

There's always tradeoffs

PostHog has a pretty good post about this tradeoff. Dogfooding works especially well there because PostHog builds tools for companies that resemble PostHog. The company still warns that too much internal feedback can lead a team to build what it wants rather than what its users want.

Of course there are caveats and nuances: Sometimes the builder really is a good first customer. Paul Graham has argued that strong startup ideas often come from problems the founders have themselves. Starting with your own need can establish that the problem exists and give you unusually deep insight into a solution. That doesn't mean they can't fall in the trap that dogfooding becomes harmful when a product / quality practice is mistaken for market-validation or they fully understand or can empathize with that market.

This is nothing new btw. Perhaps it's amplified in this era of AI Agents but check out Eric von Hippel’s research on lead users that gives this conversation some useful boundaries (1988)! "Lead users" experience needs that will later become common and have a strong reason to solve them. Their experience matters because they are ahead of a real trend. But that still does not mean every personal frustration points to a market but it can be an indicator.

A founder may be a real first customer, a "lead" user even. Their experience is still a starting hypothesis about a market.

This is why “you are not your customer” is worth keeping in mind. The phrase turns personal preference into something to test. It stops the team from trying to simulate another person from inside the building and gives unexpected behavior a more useful meaning: there is something left to learn.

A better take is: You may be a customer. You aren't the market.

Keep dogfooding. Let the product interrupt your day and fix what breaks. Then go outside the building and watch someone who does not know the vocabulary, cannot message the builder, and has to decide whether the product is worth the cost.

To them, a computer is a tool standing between them and the thing they want to finish. They want to do the work, close the lid, and get back to paddle boarding.

What frustrates them is not only that computers can be difficult. It is that the computer expects them to understand how it thinks.

You have to remember which application you used, where the file was stored, what you named it, which browser tabs were important, and how to put the workspace back together the next time. The computer keeps all of those pieces, but you have to reconstruct what they meant.

People who enjoy computers learn this model. We develop habits for folders, shortcuts, windows, and applications. Eventually it feels natural enough that we forget how much of the computer's internal organization we have taken on ourselves.

My daughters have no interest in doing that. From their point of view, the computer does not understand them, and they do not want to spend their time understanding it.

I recently built a small prototype on an Omarchy installation to explore the opposite arrangement.

Instead of finding and opening everything manually, they could tell the computer what they wanted: "Pull up the research paper I was working on."

The computer could restore more than the document. It could bring back the browser tabs, references, and other things that surrounded the work at the time. They would not need to remember which buttons they pushed or where every piece was stored. They could return to the work as they understood it.

That sounds like a voice interface, but voice is only one way to express the request. The more useful part is that the computer remembers what the request means for this person.

A personal computer should be just that personal! It should be able to learn that someone likes certain tools arranged in a particular way. It should remember the context around unfinished work. It should be able to create a small, purpose-built interface when the existing applications do not fit the job. Over time, the machine should require less translation between what the person wants and how the computer expects it to be done.

One of my daughters has dyslexia and gets especially frustrated with computers. She loves the idea of telling a computer what she needs, having it adapt to how she works, and getting help without first negotiating the computer's abstractions.

Her reaction changed how I think about customization.

Most customization asks us to configure the computer. We choose a theme, move a bar, install applications, and learn new shortcuts. That can be enjoyable for people like me, but it still requires the person to do the adapting.

An agent gives customization a different direction. You can describe how you work, correct the computer when it gets something wrong, and let it retain those preferences. The computer can become a custom piece of equipment for one person rather than the same general-purpose interface with a different wallpaper.

This is what caught my attention about Quattro. Engineers can look at its Quickshell foundation, plugin architecture, configurable coding-agent default, and window-position saving as a deeply customizable Linux environment. I see a path toward something my daughters might actually want to use: a computer built around the things they want to accomplish without requiring them to become computer enthusiasts first. My hope is they eventually will of course, love computers like I do but maybe this is a path.

There are plenty of unresolved questions. A computer that learns you also needs clear boundaries around what it remembers, what it changes, and when it should ask. Personalization that cannot be inspected or corrected will eventually become another source of frustration.

The personal computer has mostly been personal because one person owns and configures it. Agents could make it personal because it understands how that person works.

I have already wiped a Framework laptop to try Quattro with this in mind. I want to see what happens when the computer stops asking my daughters to learn it and starts learning them.

Consider a contractor preparing an estimate for a job that looks routine.

The estimating software knows the expected labor and materials. The CRM knows the customer has been with the company for years. The schedule shows an opening next Tuesday. An old estimate suggests what the work should cost.

Then the owner looks at it.

The owner remembers that access to the building is difficult, the usual crew struggled with similar equipment last year, and this customer values finishing quickly more than getting the lowest possible price. The old estimate is relevant, but one of its assumptions no longer holds.

Every system contains part of the answer. The owner connects those parts, decides which ones matter, and makes the call.

For better or worse, the owner is the reasoning layer.

Most business software records what happened. The customer requested a quote. The last job took forty hours. The invoice was paid. The crew is available.

Those records are useful, but they do not explain what should happen next.

Memory helps, but retrieving an old estimate is only the first step. Someone still has to decide whether the previous job is actually similar, which conditions have changed, and whether the old decision should apply again.

Workflow automation can execute a predefined rule. If an estimate exceeds a threshold, require approval. If an invoice is overdue, send a reminder. Those rules work when the business already knows how to describe the decision in advance.

The harder work lives between the rules.

It appears when two reasonable priorities conflict, when an exception may be justified, or when the written process does not capture what an experienced person sees. That is where the business relies on judgment.

A system of reasoning would bring together the current state of the work, the judgment the company has accumulated, and the constraints of the moment. It would help determine what should happen next.

That does not mean making every decision automatically. In fact, a system that just brings valuable insights and records to the owner is a valuable "haystack reducer" in and of itself. I could make the argument that this is part of a system of reasoning, with the owner as the ultimate reasoner.

The useful unit in a "system of reasoning" is more than the answer. It includes the reason, the conditions under which that reason mattered, and the authority the system had to act.

When the owner changes the estimate, that correction should become more than a one-time override. The business should retain what changed and why. When a similar job appears later, the system should bring that context back without assuming the situations are identical.

Agents could make this practical for smaller companies.

Large companies can employ analysts, operations teams, managers, and process designers to turn experience into repeatable systems. In a small business, the owner often does that work while also selling, hiring, managing customers, and keeping the work moving.

An agent can gather context across the systems the company already uses. It can follow a decision from the initial facts through the recommendation, correction, and final outcome. Over time, it can help the business apply more of what its people have learned without requiring someone to stop and write a new process manual after every unusual job.

The reasoning still needs boundaries.

People must be able to see where it came from, correct it, limit who or what can use it, and retire it when the business changes. Otherwise, an exception made for good reasons in one situation can quietly become a bad rule applied everywhere.

A small business should be able to turn the judgment of its people into a system without reducing that judgment to a checklist.

That would let the company become more consistent without becoming rigid. It could depend less on the owner being present for every ordinary decision while bringing the difficult decisions back to the people who should make them.

The owner is the reasoning layer today. The opportunity is to help the business carry more of that reasoning itself, so the owner can spend less time reconstructing routine context and more time on the decisions only they can make.

Most companies are organized around a particular set of constraints. Information moves slowly. Software can only follow predefined paths. People are needed to carry context between systems, departments, and each other. Workflows grow around those limitations.

Some of those workflows protect something real. They encode judgment, accountability, safety, or a legal requirement. Others exist because they were once the least bad way to coordinate the work.

Adding an agent to every step can preserve all of those assumptions without asking whether they still make sense.

The better starting point is the job.

What outcome are we trying to produce? What context does the work require? Where does human judgment matter? What can an agent execute consistently? What should remain deterministic software? What authority can the system earn over time?

People remain unusually good at setting intent, building trust, navigating ambiguity, and making decisions when the stakes are human. Agents bring sustained attention, recall, and the ability to apply a growing set of capabilities across the company. Software gives both of them reliable tools and controls.

When people and agents work from the same context, capabilities can move across the company more consistently. A correction made in one job can improve the next. A useful skill does not need to remain trapped inside one department. People spend less time reconstructing what happened and more time making the decisions that actually require them.

This is the direction we are taking with Genesis. It starts with a job, learns how the business works, builds what the work needs, and takes on more as it earns trust.

An agentic company is not defined by how many agents it has. It is defined by whether the company can bring its full intelligence to the work and deliberately use the right aptitude for each part of it.

The knowledge is there. It lives in the owner, experienced employees, customer relationships, old estimates, handwritten notes, and the exceptions people simply remember.

But experience does not automatically become institutional memory.

A technician finds the cause of an unusual equipment problem, but the next technician never hears about it. An owner adjusts an estimate because of a risk that is not obvious from the job description, then has to rediscover the same reasoning months later. A customer preference lives with one employee until that employee leaves.

Large companies try to solve this with operations departments, process manuals, training programs, and expensive systems. Those mechanisms can work, but they require people whose job is to turn the work into documentation and then keep that documentation current.

A small business should not have to become a bureaucracy to remember what it knows.

Agents can change the economics of institutional memory because remembering can become part of doing the work.

When someone corrects a decision, the system can preserve the correction and why it mattered. When a job produces an exception, that lesson can be connected to the relevant customer, equipment, or situation. When similar work appears again, the useful context can return at the moment it is needed.

This is not the same as recording everything. A pile of transcripts is no knowledge, wisdom, nor memory. The useful unit is the decision, the reason behind it, and the conditions under which it should matter again.

The memory also needs boundaries. People should be able to correct it, see where it came from, decide who can use it, and let outdated knowledge expire. Otherwise the system replaces forgotten context with confident folklore.

Done well, this makes the people in the company more capable. Experienced employees stop repeating the same explanation. New employees begin with more of the company's accumulated understanding. The owner becomes less of an information router without becoming less important to the decisions.

The business also becomes future proof. Its operating knowledge can survive turnover, growth, and the passage of time without being flattened into a manual nobody reads.

This is part of what an agentic company should make possible. The company should retain what its people learn without reducing their judgment to a checklist.

The goal isn't to just remember everything (although that's possible with agents). It is to stop relearning the same lesson.

A customer asks an unusual question. Someone makes a judgment call. The work gets done. But the lesson often disappears into a meeting, a message, or the owner's head.

An agentic company should work differently. Every completed job should leave the business more capable than it was before.

That is the part of the self-improving company idea I think is the part of the future of companies. The interesting difference between now and the last few thousand years is the never-tiring, intelligent agent that can make this come to pass. It turns the company’s experience into context, skills, and systems that can be used again.

At The Agent Company, that is the direction we are taking with Genesis. It starts with one job, learns how the business works, builds the tools it needs, and takes on more as it earns trust.

Each correction should become owned context. Each repeated task should become a reusable skill. Each exception should sharpen the boundary between what the system can handle and what still needs a person.

The goal is not a company without people. People set intent, exercise judgment, and handle the moments where trust, emotion, or real-world ambiguity matter most. The system should carry more of the repeatable work and bring the hard decisions back to them.

And the intelligence it creates should stay with the business. Otherwise the company is only renting leverage instead of building it.

An agentic company should not just finish today's work. It should be better tomorrow because the work happened.

Technical freedom is the ability to build without asking permission. Business freedom is the ability to run and grow a company on your own terms. National freedom means shaping our own future while preserving each person’s liberty to pursue theirs.

These may sound like different ideas. To me, they are the same pattern at different scales. And you need some type of infrastructure to make each real.

We started Agentuity to give builders (and agents) the tools needed to create the agentic future, easily.

Now we are building The Agent Company on top of Agentuity. Its first product, Genesis, learns how a small business works, builds the tools it needs, and takes on more as it earns trust. The knowledge and systems it creates stay with the business. That gives a young entrepreneur who wants to grow the tools and ownership to compete with companies many times their size.

That matters because small businesses are the lifeblood of America. They spread ownership and opportunity across more people and places. AI can help them take on more, grow on their own terms, and allow them to keep what they build.

The same principle applies to the country. Our freedom in the future will depend on our ability to build in AI, space, and the other systems shaping what comes next.

Infrastructure is not only about scale. It decides who gets to act.

Who gets the ability to build, compete, and remain independent?

The answer should be more of us.

a16z describes AI-native companies running smaller, flatter, and with less capital. Stripe sees more solo operators reaching meaningful revenue, with AI filling capability gaps that once required a team.

The obvious conclusion is that AI makes it easier to start small.

The more interesting one is that it may make it easier to stay independent.

A wave of retiring owners has made small businesses attractive targets for private-equity rollups. Their advantage is not only capital. It is the operating machine: finance, marketing, sales, systems, and a repeatable playbook for growth.

That worries me. Independent small businesses are a cornerstone of the American economy, yet they have long been underserved by technology. A young owner eager to grow can rarely afford the kind of site-selection study a PE-backed firm can commission. But much of the analysis behind that advantage can now be done with AI.

AI can put more of that leverage in the hands of an owner. Not by adding a chatbot to the business, but by helping redesign how the work gets done. A small company can gain the operating discipline of a much larger one without recreating all of its overhead.

America's small-business ecosystem spreads ownership, opportunity, and resilience across more people and places.

Helping the next generation of owners use this leverage to stay independent and win is the part of the AI cycle I find most interesting.