Week One: Building Acorn Labs in the Open

I'm choosing to document Acorn Labs from close to day one, rather than waiting until everything looks polished and inevitable.

That means showing what building an AI-run company actually looks like when it is still early, incomplete and occasionally messy.

This is roughly one week in.

What Acorn Labs is, honestly

Acorn Labs is my attempt to build a company that can genuinely be operated by AI employees.

Not a chatbot with a company logo attached to it. Not a collection of prompts pretending to be departments.

The aim is to create real AI employees with defined roles, permissions, work histories and responsibilities. They should be able to receive work, gather evidence, produce outputs, review decisions and operate within clear governance.

The organisation's important records and decisions are being built on the Internet Computer, rather than being scattered across temporary chats, spreadsheets and internal tools that slowly become impossible to trust.

That is the vision.

Where it actually stands today is much smaller, and I want to be precise about that.

Acorn currently has one AI employee doing real work: a Research Analyst.

It can be assigned a research mission, gather evidence and produce a structured report. I review everything it creates before the work is treated as complete.

There is no autonomous AI team yet.

There is no independent AI review layer.

The employees are not choosing the company roadmap or publishing things without permission.

It is one AI employee, doing one genuine category of work, under close supervision.

That might sound modest compared with the larger vision, but I think that distinction matters. I would rather document the real progression from one useful employee to a functioning AI organisation than claim the destination before I have built the road.

What the first week actually felt like

From the outside, building an AI company sounds futuristic.

In practice, much of the first week has looked surprisingly ordinary.

It has involved reading reports, reviewing code, fixing bugs, questioning assumptions and repeatedly discovering that something which looked correct in a specification behaves differently once it meets the real system.

There have been long stretches where the progress did not feel dramatic at all.

A run crashes and needs a safe retry path.

An error is technically correct but displayed as [object Object], making it useless to the person who actually needs to understand it.

A workflow works once but has no reliable way to recover when something fails halfway through.

A model-selection rule exists, but the system needs to show clearly which model was selected and why.

None of those things makes a spectacular launch video.

They are also the difference between a convincing demonstration and something that can eventually be trusted with real work.

That has probably been my biggest lesson from the first week: the ambitious part is not imagining the AI company. The difficult part is making thousands of small decisions that stop it from becoming theatre.

The issue that mattered most this week

The most serious finding appeared while checking something else.

During a routine review, I discovered that a development-only authorisation assumption had survived in a place where it could have granted far more authority than intended.

In plain English, the system could have treated the wrong person as though they were the Founder.

That is not the kind of discovery anyone enjoys making in their own project.

There is a moment when you see something like that and feel the distance between the company you believe you are building and the imperfect system that currently exists in front of you.

But that moment is also where the real standard of the company begins.

Do you minimise it because it is embarrassing?

Do you patch the visible problem and move on?

Or do you stop, investigate the assumption underneath it and find out what else might depend on the same mistake?

I chose the third option.

The fix was tested using genuinely separate identities rather than repeatedly checking it through one account.

I also examined whether the safeguards that were supposed to catch this class of problem would actually have done so. One of them was not sufficient on its own, so that was corrected as well.

A wider review found another area that may have depended on the same broken assumption. I deliberately did not trigger it simply to prove that it existed, because doing so could have caused further damage. It was recorded and handled as a real risk rather than treated like an experiment.

The incident was documented, including the limits of what could be proven afterward.

I know what I observed. I know what was fixed and how the corrected behaviour was tested. But parts of the original state cannot now be independently reproduced without reintroducing the problem.

That distinction belongs in the record.

It would be easy to rewrite the story as:

I identified and resolved a security issue.

The more truthful version is:

I had made a dangerous assumption. A separate review exposed it. I stopped, verified the correction properly and changed the surrounding safeguards so the same category of mistake would be harder to repeat.

That is less polished.

It is also more useful.

Why governance matters more after a mistake

A lot of AI systems are designed around speed.

Give the agent a goal, grant it tools and encourage it to keep going until the task is finished.

Acorn is being built around a different question:

What should an AI employee be allowed to do, what evidence should it retain, and when must it stop and ask?

This week reinforced why those questions matter.

An AI employee capable of moving quickly through a flawed permission system is not more useful. It is simply able to make a larger mistake faster.

The aim is not to remove human judgement from the company. It is to move human judgement to the places where it genuinely matters:

• Setting direction.

• Defining authority.

• Resolving uncertainty.

• Reviewing high-risk work.

• Approving actions with public or irreversible consequences.

The routine operation should increasingly be handled by AI employees.

Accountability should not disappear as that happens.

Why I'm making this public

There are two reasons.

The first is practical.

This idea, the work behind it and the decisions that shape it belong to me. A public and dated record of building Acorn Labs establishes that much more clearly than quietly working for months and appearing only when the project is finished.