FIG. 00 — HOW WE BUILD

THE FIRM IS THE PROOF.

The only agentic system ARA can show you is its own.

Every consultancy says it can deliver AI now. Usually the proof is a client story you can’t check, and we don’t name our clients. So instead we’ll show you how ARA itself runs: one person, one AI orchestrator, and fifteen named specialists, set up the way we’d tell any client to set up theirs. None of it runs without a human in charge.

FIG. A1 — BOUNDED · THE ORG

Fifteen specialists, and not one of them chooses its own work.

ARA runs on one orchestrator and fifteen specialists. The specialists can’t pass work to each other because they don’t have permission to. Every hand-off goes through the orchestrator, so there’s always a record of who asked for what. Yes, that makes the orchestrator a bottleneck. We’ll take that in exchange for being able to trace every step.

Routing diagram: one orchestrator hub routing goals to fifteen specialist disciplines An index lists fifteen specialist disciplines, numbered 01 to 15, each tagged with the execution role it carries: seven builders, six authors, one reviewer and one control-plane engineer. To the left sits a single hub, the orchestrator, annotated "routes, never builds" and "a deliberate bottleneck". Three incoming goals — build the pipeline, design the identity, review and validate — each enter the hub and are then routed out along a single line to exactly one discipline: solution architecture, design and brand, and review and security respectively. A crossed-out dashed line between two specialists is marked "no spoke-to-spoke: no specialist holds the permission", meaning specialists cannot hand work to each other directly. There is no line anywhere between any two specialists; every hand-off returns through the hub. INTAKE FIFTEEN SPECIALISTS · ONE EXECUTION ROLE EACH 01People & orgAUTHOR 02ResearchAUTHOR 03Design & brandBUILDER 04StrategyAUTHOR 05Delivery & operationsAUTHOR 06Data scienceBUILDER 07Review & securityREVIEWER 08Solution architectureBUILDER 09Domain specialistAUTHOR 10Front-end engineeringBUILDER 11Applied AI architectureCONTROL PLANE 12EducationAUTHOR 13Platform specialistBUILDER 14Editorial & doctrinal reviewBUILDER 15On-device AI engineeringBUILDER The orchestrator ROUTES · NEVER BUILDS A DELIBERATE BOTTLENECK GOAL 01 BUILD THE PIPELINE GOAL 02 DESIGN THE IDENTITY GOAL 03 REVIEW & VALIDATE NO SPOKE-TO-SPOKE NO SPECIALIST HOLDS THE PERMISSION

←  SCROLL THE FIGURE HORIZONTALLY  →

FIG. A1 — TRY TO FIND A LINE BETWEEN TWO SPECIALISTS. THERE ISN’T ONE, AND THAT’S ON PURPOSE.

FIG. A2 — ACCOUNTABLE · THE CONTROL PLANE

What each agent can do is set in a file it can’t edit.

Each specialist has a file that spells out which tools it can use, what it’s allowed to do, and whether it works in its own separate copy of the code. Those settings lock in when the agent starts, so nothing it reads later can change them. Only one specialist is allowed to edit these files, and no agent, including that one, can edit its own. A check runs before anything else to enforce that, and if it can’t tell who’s asking, the answer is no.

We run 110 automated tests, all passing, to make sure each of these checks still does its job. Only one of the three checks actually blocks anything. The other two just measure, and one of them caught a permission rule that wasn’t holding up the way we thought it would. We made a written decision to live with that trade-off. If you’ve never measured a safeguard, you’re just hoping it works.

Control-plane diagram: capability declared per execution role, one blocking control and two measuring instruments Upper half: a table of four execution roles against four capabilities. Builders, seven specialists, may write, execute, and work in an isolated worktree, but not in the main tree. Authors, six specialists, may write only. The reviewer, one specialist, may write and execute in the main tree with no worktree. The control-plane engineer, one specialist, may write and execute in the main tree, scoped. Every setting is written in the agent's own definition file and locks in when the agent starts, so nothing it reads later can change it. Seven plus six plus one plus one equals fifteen. Lower half, an instrument bench: exactly one control and two instruments. Control 01, the agent-definition write guard, permits only one specialist to write an agent definition file and permits none of them, including that one, to write its own; it runs before permission rules are evaluated so no permission mode overrides it; an attempted write is shown arriving and being stopped. Instrument 02, the subagent spawn mode guard, only measures whether the permission mode held; its readout sits at "not holding", a result ARA measured, logged, and accepted in writing as a trade-off. Instrument 03, the prompted write guard, only measures whether a write was prompted; its readout sits at "not prompted". Neither instrument blocks anything. A suite of 110 automated tests passes with zero failures, and one test confirms that the advisory guard cannot block. DECLARED IN .claude/agents/<role>.md · LOCKED IN WHEN THE AGENT STARTS WRITE EXECUTE WORKTREE MAIN TREE Builders 7 SPECIALISTS Authors 6 SPECIALISTS Reviewer 1 SPECIALIST Control plane 1 SPECIALIST SCOPED FOUR EXECUTION ROLES. EVERY SPECIALIST CARRIES EXACTLY ONE. 7 + 6 + 1 + 1 = 15 ONE CONTROL BLOCKS. TWO ONLY MEASURE, ON PURPOSE. CONTROL 01 · BLOCKS agent-definition-write-guard.sh .claude/agents/ <role>.md NO AGENT WRITES ITS OWN DEFINITION. NOT EVEN THE ONE WHO WRITES THEM. IT RUNS BEFORE PERMISSION RULES ARE EVALUATED, SO NO MODE OVERRIDES IT. INSTRUMENT 02 · MEASURES subagent-spawn-mode-guard.sh DID THE PERMISSION MODE HOLD? NOT HOLDING HOLDING MEASURED AND LOGGED. WE ACCEPTED THE TRADE-OFF IN WRITING. THIS HOOK BLOCKS NOTHING. IT LOGS AND MOVES ON, BY DESIGN. INSTRUMENT 03 · MEASURES prompted-write-guard.sh WAS THE WRITE PROMPTED? NOT PROMPTED PROMPTED IT ONLY WATCHES. 110 PASSED · 0 FAILED WE TEST THE GUARDS AUTOMATICALLY. ONE TEST CONFIRMS THE ADVISORY GUARD CAN’T BLOCK.

←  SCROLL THE FIGURE HORIZONTALLY  →

FIG. A2 — ONE CHECK BLOCKS. THE OTHER TWO JUST MEASURE, AND ONE OF THEM TURNED UP SOMETHING WE DIDN’T LIKE.

FIG. A3 — GROUNDED · THE SELF-IMPROVING SDLC

We built our process to get better over time, then measured whether it actually does.

Every project starts with a conversation instead of a prompt. The goal gets written up as a plan with clear, checkable success criteria, and a person signs off before anything gets built. Each step has to meet its criteria before the next one starts.

Nothing goes to a client until it passes a required review, and the result gets written down. If the work is rejected, it goes back to whoever made it and has to pass review again. The reviewer writes up what’s wrong but never fixes the work themselves, and nobody ever reviews their own work.

Dial diagram: the build protocol as a loop that closes on itself, with the human approval point marked A measured dial with five stations set 72 degrees apart around its rim. 01 interview, scaled to size and never skipped. 02 approved plan, with numbered phases and an owner per step; this station is bracketed and marked "a person approves here", and it is the point at which a human has to say yes before anything is built. 03 small steps, one phase at a time with the result back before the next. 04 the review, required, returning a recorded verdict. 05 reuse, cite the library and log the citation. The arc draws station by station, and the final segment from reuse back to interview closes the loop. A chord inside the dial runs from the review back to small steps, marked "reject returns into the loop", because rejected work goes back to the specialist who produced it and has to pass review again. At the dial's centre sits phase zero, call the task. Below, the review's three verdicts are listed: approve, approve with conditions, and reject with remediation. As of 2026-08-06, forty-one library deposits and twelve captures exist, and every gated deliverable leaves a capture answering four fixed questions. The reuse counter reads one: the log's first entry was made on 2026-08-05, from the audit this page's fact check triggered, and one is too early to call a trend. ARA logs whether the next project cites a deposit. Only a citation counts as reuse, and ARA doesn't backfill the count. PHASE 0 Call the task WORKTREE · CLEAR · STAY 01 · INTERVIEW SCALED TO SIZE. NEVER SKIPPED. 02 · APPROVED PLAN NUMBERED PHASES · OWNER PER STEP A PERSON APPROVES HERE 03 · SMALL STEPS ONE PHASE. RESULT BACK. 04 · THE REVIEW REQUIRED · RECORDED VERDICT 05 · REUSE CITE IT. LOG THE CITATION. REJECT RETURNS INTO THE LOOP THE REVIEW RETURNS ONE OF THREE APPROVE APPROVE WITH CONDITIONS REJECT WITH REMEDIATION 41 LIBRARY DEPOSITS · 12 CAPTURES · 2026-08-06 EVERY GATED DELIVERABLE LEAVES A CAPTURE ANSWERING FOUR FIXED QUESTIONS. TOO EARLY TO CALL A TREND. REUSE EVENTS LOGGED 1 FIRST ENTRY 2026-08-05, FROM THE AUDIT THIS PAGE’S FACT CHECK TRIGGERED. ONLY A CITATION COUNTS. WE DON’T BACKFILL THE COUNT.

←  SCROLL THE FIGURE HORIZONTALLY  →

FIG. A3 — REJECTED WORK GOES BACK INTO THE LOOP. A REVIEW THAT NEVER SAYS NO ISN’T REALLY A REVIEW.

FIG. 04 — CONTACT

Ask whoever is building your agents to show you their version of this page.

hello@ara-data.com