Judgment is a harness property

In April 2026, I had a business idea, and I wanted to experiment with AI. Since then, I have been running a company where most of the workforce is AI agents. It is no longer a thought experiment.

Tablia is a reservation platform for restaurants, responding to all of the needs of restaurateurs: booking widget, back office, guest notifications. And it's already live in production. But how does it work?

The engineering runs through a pipeline of eight Claude agents that I designed and operate: a PM, a designer, a staff engineer, a QA, a builder, three independent reviewers, and a vision QA. In nine weeks, that pipeline shipped 25 runs. Seventeen of them were fully autonomous: I launched them at night and read the results in the morning.

I wrote this article to explain the thesis I had in April 2026, right before starting this project, and most importantly, how the first 3 months validated and surpassed even what I thought was possible.

Judgment is the true bottleneck.

The models' raw reasoning is excellent: in 25 runs I can barely point to a failure I would call a failure of intelligence. Every failure that hurt was a failure of judgment: an agent deciding without using the context that the organization provided, not verifying its own output, or quietly deciding something that was not its to decide.

My favorite example could be described as embarrassing. But it is the one that really confirmed my gut feeling: judgment is truly the bottleneck of an AI workforce in a company. My landing page shipped with a fixed 56px side padding at every screen width. On a 390px phone, that left a 183px column of text, about 25 characters per line. Three automated guards were watching that page. All three stayed green, because all three asserted the same thing: no horizontal overflow. A too-narrow column satisfies "no horizontal overflow" perfectly. Any human sees the problem in one second. The checks passed, and the page was wrong.

That is the gap. A system can be intelligent and still have no judgment, because judgment is not in the model. It is a property of the model plus everything you build around it: the context it can reach, the ways it can test its own work, and its awareness of the limits of its mandate. In other words, judgment is a harness property.

My harness stands on three pillars.

Pillar 1: Context

How can we define human judgment? Where does it come from? I won't pretend I'm an expert in the subject, I'm not a philosopher, only a humble engineer experimenting with AI. So for me, and for this AI workforce, I went with 3 assumptions: Judgment comes from experience, memory and learned conventions. But what does it mean concretely? The company's memory is a documentation tree, and I treat it as infrastructure. Today it holds 111 decision records, 120 tracked actions, 113 processed conversation memories, 26 feature briefs and 24 acceptance-test files. Every decision, every product motivation, every convention, every task lives there, not in my head or in a chat scrollback.

And this infrastructure is not RAG fodder with a lot of documents in it. The actual point is that the tree is curated, indexed and versioned. Every folder has a README that indexes its contents in one line per entry, so an agent reads the index first and opens only what it needs (progressive disclosure). The index of decision records alone is dense enough that an agent can route to the right record without opening a single file. The standing rule is blunt: never load everything.

Keeping the tree alive is the real challenge. I decided to address it with a two-step loop: after every working session, a command saves the conversation with my inputs preserved verbatim: the instruction literally says my inputs are gold and must not be paraphrased, because they are the alignment signal everything else derives from. A second command then integrates that raw memory into the structured docs.

Pillar 2: Verification

An agent with context can decide like the organization would. But most agents do not decide, they execute a decision that was made before they have to work, whether by me directly or by agents that have other specific roles. And so, to execute well, they need a way to verify their own work.

So the feature-development pipeline runs eight phases: spec (a PM and a designer iterating), technical specifications & implementation plan, QA acceptance tests, SWE build, SWE review, vision QA, deploy, and finally a documentation phase. Three of them exist purely for verification: acceptance tests, review, and vision QA.

The acceptance tests are scenarios, written by the QA agent before a single line of the feature exists. Each scenario carries a layer tag which can be end-to-end, backend integration, frontend or backend unit, and an anchor to the exact spec section it verifies. The builder's job is to make the authoritative scenarios pass. The balance is integration-first, end-to-end for the critical paths, unit for pure logic. The builder iterates on the affected scenarios, and the full corpus runs once, as the exit gate. Note that, unlike in most engineering organizations, QA is not at the end of the lifecycle here. It's actually at the very beginning: It writes its tests before development starts.

At the review step, three AI reviewers read independently the same diff in parallel through three different lenses: non-regression, feature-completeness, staff-engineer scrutiny. An aggregator deduplicates their findings and promotes severity when two independent lenses flag the same surface. Each lens hunts a different class of problem and this system aims to catch multiple natures of error that a single reviewer could miss. Vision QA has the same shape: it triangulates every suspected defect across three evidence sources: screenshot, accessibility tree, and specs. Then, it emits defects that have a confidence score above 80/100.

Verification has a real cost, and it grows in the development pipeline. At some point the end-to-end suite consumed 45% of the builder's wall time as it accumulated at each iteration. To reduce it I created an ephemeral test stack enabling parallelization. The full corpus now runs in 2 minutes 18 seconds with four workers, against roughly ten minutes before, booting in 11 seconds warm. Verification you cannot afford to run is verification that stops happening.

Pillar 3: Escalation

For me, it is the least discussed part of judgment. It is built by confronting the choices you make when the instructions run out. That is what escalation is for.

A fully autonomous run of the pipeline has no human gate, and there is always ambiguity left in a prompt. The naive options are to pause on every ambiguity (goodbye night runs) or to let the agent decide everything (goodbye alignment). The mechanism I use instead: every unresolvable product micro-call is built with a documented default, tagged for me, and queued for post-run ratification. The run does not stop, and the decision is still human-arbitrated in the end.

There is a paradox here that I did not expect: an agent that escalates well is actually more autonomous, not less. Documented defaults are what buy the night runs, because I can trust that whatever crossed a line is waiting for me, documented, instead of shipped silently.

What should carry over to any organization, in my opinion

Transposed to any other organization, I believe four patterns survive:

1. Write decisions where agents read them. Context infrastructure beats prompt-stuffing, and an index an agent can route through beats a pile it must swallow.
2. Give every agent a verification loop proportional to its blast radius and also make the loop cheap enough that it actually runs.
3. Make escalation a first-class output: documented defaults plus a ratification queue. It is what buys real autonomy.
4. Verify outcomes, never checkmarks.

Intelligence is abundant now. What will separate organizations is the judgment they build around it.

What is the next bottleneck?

Intelligence plus judgment buys you product building. So what is left? Acquisition. It requires earning the trust of other humans which is to my knowledge a problem AI has not solved yet. It also explains why I do not have thousands of customers at this point. So stay tuned for the next part of my AI journey: building an acquisition pipeline the same way…

Ciao 👋