Start-up energy, inside a grown-up company

I recently spent a session with a successful edtech company, walking through how a fully autonomous operation runs a business. Not slides about what AI might do. The actual system: the agents, the gates, the morning board, a request followed from the moment it arrives to the moment a person presses send.

We looked at how they work today and at where they are heading. I am not going to name them or describe their internals. What I can share is what I showed, what I argued, and the thing I think matters most for any established company looking at this.

What I showed

SGAF is a governance product for UK schools and academy trusts, and I run it alone. The departments an edtech company normally staffs exist in my business as agents: research, outreach, meeting preparation, support, product, content, data quality and finance. Around a dozen run the business day to day.

The shape is the same everywhere, and it is a governance shape, not a technology one. Delegate, assure, account. Six stages: set direction in writing, classify what arrives, let a specialist execute, demand proof before anything counts as done, keep a record anyone can check, and put a named person at the approval. I did not need a new model for governing agents. I already sell one to governing boards.

I showed a case end to end. A message arrives. It is classified and routed, with a written reason for the choice. Anything uncertain, anything sensitive and anything involving money goes to a person before any bot acts. A specialist drafts. I send. The record shows every step and why.

Then I showed the honest scorecard. Every process scored against the six stages, with roughly three quarters of the model in place at the time of the demonstration. Strongest at the human ends and the proof. Weakest where work has to start itself, and in finance and onboarding. "Round the clock" turned out to mean a handful of always-on triggers and a scheduled routine, not a night shift. I showed that slide deliberately, because a demonstration that only shows what works is a sales pitch.

The hard part has moved

The thing I most wanted them to take away is that the hard part of building software is no longer the build. It is the governance around the build.

In code, the gates come free. Twenty years of industry effort gave us tests, pull requests, preview builds and a merge button. An agent writing code lands inside a system that already demands proof.

Everywhere else there is no test suite. Customer support, marketing, outreach, finance, HR. Nothing stops an agent from simply sending the thing. So you write the gates yourself: limits, proof and sign-off as policy and culture rather than tooling. Extending that across a whole company is the actual work, and it is the work most organisations have not started.

Two companies, two starting points

Here is where a new company and an established one diverge, and it is worth being plain about it.

A lean start-up can build this way from day one. The three barriers that used to stop a founder, cost, skill and time, have moved. A product this size used to need a developer, a designer, somebody on support and somebody on data, which is a payroll. Now it is a monthly software bill. I do not write the code; I describe what it must do and check what comes back, and knowing the domain turned out to be the part that mattered. The work carries on while I am at my day job. None of that moved because I got better. It moved because the work could be delegated and still be checked. A new company can design every function with the gate in from the start, because there is nothing to retrofit.

An established company does not get that. It has capable teams, mature processes and a culture that works. Adopting this is a change programme in a complex environment, with roles to respect and systems to integrate. And it is happening under pressure from the board to show a return on the AI investment, which is exactly the pressure that produces the wrong behaviour: bolting a model onto an existing process, measuring the speed, and calling it impact.

The failure mode is approval fatigue. Too many yeses become rubber-stamping, and a rubber stamp is not oversight. The gates are the product. Everything else is just speed.

Start-up energy, in a place that is allowed to be wrong

What I argued for is start-up energy inside the company, and the specific thing that makes it safe.

I build in one place and run the business in another. The workshop is a separate environment where every change gets its own branch and its own preview. Agents get room there: try an approach, bin it, try another. Being wrong is cheap, so being wrong is allowed. The business is the other side, with real customers, real data and real money, and nothing arrives there that was not built in the workshop, tested there and approved on the way out. The workshop can be loose precisely because the boundary is hard.

An established company can do the same. Carve out a workshop with a small team and genuine latitude. Let them play with the way the business could work, not just the way the code could. Put the boundary where it is expensive to be wrong, and make the gates explicit there. Measure the gates, not the velocity. Culture beats tooling, decisions about people need more care than any of this, and one founder with bots is not an enterprise. But the pattern transfers.

Why I trust play

I am not asking anyone to take this on faith, because it is how my own expertise was built. Almost everything serious I run started as something fun.

A health coaching loop I built for myself taught me how to make a model's output trustworthy by surrounding it with deterministic checks. A spare Raspberry Pi watching three websites every minute taught me how an outage should travel through the agent system to my phone, and that chain now watches the production sites. A netball app for my wife taught me to design for the job as it is actually done.

None of those had a stakeholder. All of them found a constraint that became a rule in the system that pays the bills. I have written about why I play first, and the short version is that you notice more when nothing depends on it.

The four questions

I closed with the questions I think a board should ask about any piece of work an agent touched, because they are the same four a governing board has always asked.

Who set the limit, in writing, before the work started? What is the proof, produced by the work itself rather than written up afterwards? Where is the record, findable later by somebody who was not in the room? Who signed, a person with a name, not a team and not a process?

The question was never whether AI can do the work. It is whether you can answer those four about it. Human-led, AI-run.

If you are starting a company, put the gates in on day one; they cost nothing yet. If you are running an established one, build the workshop first and give it start-up energy, then let the gates decide what crosses into the business.