Every tool held a piece of the business. None could say what was wrong.

01 Problem

The problem

The usual answer to running a small business online is a separate tool for each job - one for the site, one for customers, one for bookings. Each is right about its own slice. The owner is left to join them up and work out what is actually wrong.

I had built the same fragmentation into my own studio. Site scans lived on disk under a name, prospects lived in a database under an id, and nothing connected the two - so pitching one business meant seven screens.

02 Evidence

How I knew it was real

• When I joined scans to prospects by deriving the link instead of storing it, only 6 of 11 scans attached to a business at all.
• The client portal showed four lists that were the same work at four different stages, so the owner had to assemble the story themselves.
• My own operator surface was a list of doors: four screens, and none of them a view of a customer.
• A lead search did not record which offer sent it, so the same 277 businesses were attached to two different offers, and both were told they had prospects.
• 73 audit findings sat in files on disk, where no screen could read them.

03 Decision

What I set out to change

Make the business the object everything hangs off - one identity from stranger to client - with agents as the workforce around it, and every autonomous step stopping where a person should decide.

What I deliberately left alone

• Autonomy, for now. Nothing starts work by itself, on purpose: running cost is not metered yet, and autonomy without a budget is worse than none.
• Treating a stranger like a client. What can be read about a business in public, once, and what a client has connected and consented to are two modes that are never mixed.
• Acting on a signal by itself. The brain triages and escalates; a person decides.

The choices worth arguing with

1. Chose The business is the object; agents are the workforce around it.

   Over Agents at the top, which is how most competing products are organised.

   Because With agents at the centre, 'what is happening with this business?' becomes a join across agent runs instead of something you can simply read.

2. Chose Every screen is derived from stored rows and keeps no copy of its own.

   Over New tables for findings and decisions, one for each new surface.

   Because Each copy is another place to look - and the second answer to the same question is the one that rots.

3. Chose The boundary between clients is built from foreign keys, in one shared database.

   Over A database per client, or access policies tied to a login nothing uses.

   Because Five databases are five things to patch. A policy that never fires is dead code that looks like a control, which is worse than no control, because somebody trusts it.

4. Chose An agent may never write a fact - refused at the write, not asked for in the prompt.

   Over Trusting the prompt, or a toggle in the agent's settings.

   Because Once a model's confident sentence is stored as a measured one, nothing downstream can tell them apart again.

04 Build

What I built

Every business is one record, from the first scan to a signed-in client. A site read writes what it found as typed knowledge - fact, claim or observation - each with the page it came from. Analysts are given only the keys they declared, and write inferences that must cite them; a judgement citing evidence it was never given is thrown away, and the refusal is kept.

For connected clients, the fleet's findings become signals. A person triages them, and an escalation starts a workflow that parks at human gates, is checked by a verifier that did not do the work, and records its outcome as memory the next analysis reads.

The operator's view is a map of this: every business a node, what Evara can do for it beneath, and each action a person can take being the same gated action the old screens called - never a second copy of the gate.

05 Validation

How I tried to break it

• One salon's customer offered another salon's opening

  Refused by the database itself: the offer cannot exist when the two businesses differ. The hole was demonstrated on the live database before the fix was written.

  Broke, then fixed · 1 Sep 2026

• A public form choosing which business it writes to

  The page mints a signed handle. An id from a browser is never authority.

  Broke, then fixed · 1 Sep 2026

• An analyst citing evidence it was never given

  The judgement is thrown away, and the refusal is kept.

  Held

• An agent whose settings say it may write facts

  Still refused, at the write.

  Held

• Two fictional salons attacking each other

  45 checks held, 0 breached - after two real holes were found and closed.

  Held

• The system map and its data drifting apart

  A test fails if the organism diagram and its ontology describe different systems.

  Held

What did not work

• I built the operator's map in 3D, passed a 60 fps gate, and deleted it the next day. It is drawn flat now, and the 3D scene went with no copy kept beside it.
• My own notes claimed a knowledge-write gate that was never true of the shipped code. The functions exist and nothing calls them, so today nothing constrains what kind of knowledge an agent records - and the notes now say so.
• A demonstration salon's settings became every business's default, so every real service a salon offered was refused. It was found before a real salon used it.
• Nothing starts work on its own yet, and running cost is unmetered. Today the brain delivers legibility and gates, not autonomy.

06 Outcome

What changed

45 / 0 red-team checks held / breached

Two fictional salons attacking each other on the live database, September 2026.

6 of 11 scans that attached to a business once the link was derived

The first join of scans to prospects, 2026-08-11 - the number that made the case for one record.

23 of 29 parts of the system working

The canonical map as of 2026-08-14: 3 partly built, 3 not built.

1,872 / 1,881 tests passing

The last full recorded run, 2026-09-01. The nine failures are in the studio's visual prototype, not in the brain.

What the connection bought is legibility and a boundary. A business reads as one thing across the line from prospect to client; a finding carries its lineage back to the page it came from; and every place the system could act on its own has a named, enforced stop.

What it has not bought yet is autonomy. Nothing starts work by itself - deliberately, until cost is metered - and the lead chain still does not follow a business past the moment I contact it.

What I measure next

• What running it costsModel calls, fleet runs and API quota, metered per business. Only build jobs record spend today.
• What reaches a personThe share of findings routed to act, computed from signals - named as a number to watch, not yet computed.
• Whether a second sale happensA client who bought one thing accepting a second offer in another category - the stated test of the whole idea.

07 Learning

What I learned

The same failure kept coming back: two versions of one truth. The fix that worked every time was deleting one and deriving everything else from the other.

The gates that hold are the ones placed at the write, or at the moment of execution. The gaps still open are functions that exist and are never called.

Checks against the live system found what the test suite could not. The access rules were perfect and irrelevant to the boundary that mattered.

A note is a claim, and an unchecked claim ages into a fact nobody re-examines.

What I would change next

• Meter cost before switching on any autonomy.
• Decide which registry owns an agent's permission to write, then wire the gate that is currently only declared.
• Keep the map and the notes in the same commit as the code. They have already slipped once.