Founder Fireside

Founder Fireside · 001

The company that runs itself

I keep thinking about the company that runs itself.

As a solo founder, I find this an extremely attractive sentence. It suggests that somewhere in the future, I might finish a cup of coffee while it still remembers being hot.

My proposed first experiment is to let an AI agent send one email on behalf of the business.

Corporate civilization advances cautiously.

There is a particular absurdity to building Humbleaf with the help of agents. They help me think through problems, write software, test assumptions, and explore directions I could hardly pursue alone. The company I am trying to build is already being shaped by the technology it is meant to serve.

Then we arrive at the send button, and the conversation becomes surprisingly serious.

An email leaves the workshop. It reaches another person under the company’s name. It can make a promise, disclose something, create an expectation, or start a relationship. A few ordinary sentences acquire consequences because of who appears to be saying them.

The agent may be perfectly capable of writing those sentences. I still need to decide what I am authorizing it to do.

Your next hire might be an agent. I suspect we will spend quite a while discovering what “hire” needs to mean.

With a person, delegation develops through conversation and experience. You explain the job, establish limits, notice misunderstandings, and gradually give them more room. You also expect them to recognize when something has changed enough to ask you again.

I want to make that relationship explicit enough for software to participate in it.

For the email experiment, the intended arrangement is deliberately small: this recipient, this message, within this window of time. Before sending, check that the action still matches the permission and that the permission has not been withdrawn. Afterward, keep a record of what was authorized and what actually happened.

The glamorous future of autonomous business apparently includes checking the envelope.

There is a reason to begin there. If I can make one responsibility clear enough to hand over, I can start learning what it takes to hand over the next one.

Approving every email forever would give me a faster typist and a permanent second job in approvals. The useful progression is toward standing rules for familiar work, with exceptions returning to a person. Each step should earn its place by doing something useful reliably.

That is what makes the executable company interesting to me. Work can move through it without requiring the founder’s attention at every junction. People can spend more of their time deciding what deserves to happen, and less time personally operating every mechanism that makes it happen.

But even a well-defined permission has a difficult relationship with time.

Imagine an agent preparing an approved follow-up. Before it sends, the prospect replies that they are no longer interested. The message, recipient, and sending window might still match the original instruction. The reason for sending it has disappeared.

The agent could execute yesterday’s good decision perfectly.

This is the uncomfortable possibility I keep returning to: a permission can remain valid after its consequences have become unacceptable.

That makes the ability to pause, withdraw, and reconsider part of the delegation itself. A company needs a way for changed circumstances to reach the machinery that acts on its behalf. Otherwise, yesterday’s intentions can keep working long after the people who held them have moved on.

It also raises another question: what should the company remember?

A sent message tells us something happened. I would like the business to retain the decision around it: who permitted it, what limits applied, what information the decision relied on, and what would have required another look.

I have started thinking of that as authority memory.

Over time, that history could help us see where our rules work, where exceptions repeat, and where a boundary needs to change. When we replace a model or rebuild a workflow, we should be able to examine the reasons behind earlier decisions. Each new action would still need to satisfy the rules and conditions that apply now.

For a small company, that possibility feels especially valuable. So much of the business lives inside the founder’s head: the customer exception, the reason a promise was limited, the detail that makes an apparently routine action sensitive.

Making some of that knowledge explicit could let a company do more without requiring its founder to be everywhere.

That is the ambition behind Humbleaf: agents doing useful work, with people able to set the terms, change them, and understand what happened.

“The company that runs itself” is an ambitious phrase. I want to earn it through responsibilities we can actually hand over. One useful action becomes a repeatable practice. Another follows. Eventually, perhaps, the founder can step away for an afternoon and return to work that progressed within the limits they intended.

The next question is what evidence would make me comfortable giving it a little more room.

For now, the future has been assigned one email.

I remain cautiously optimistic about the coffee.

Which action would you most like to hand over—and what would you need to see before letting it happen without checking every time?

Proof

See it in the Proof Lab

Redacted authority loop demonstrations.