How we work

Start from the goal. Benchmark it. Decide on the evidence.

The name comes from dendrology, reading a tree's history in its rings. We read any problem or process the same way: what the record shows, not what anyone remembers, and the trends running through it. Everything below came out of that habit, one measured gap at a time.

01 · Approach

Three habits, applied to everything.

They apply to an engagement, a pull request and a hardware purchase alike. If a change can't show its before and after, it doesn't stay.

  1. 01

    Start from the goal

    Business objectives are the requirements

    Every piece of work names the objective it serves. Work that can't is parked, which is what keeps scope from creeping.

  2. 02

    Benchmark it

    The baseline is the evidence

    Measure before anything changes and the same way after. Answers cite their source, reviews point at the line, and nothing is done on the author's word.

  3. 03

    Decide on the evidence

    Keep what moves the number

    Change one thing, measure again, and drop what didn't help. Decisions come from the data, not the demo.

02 · The loop today

The loop runs itself. People step in where they're worth most.

AI now explores code and writes it faster than any person, so spending engineers on that legwork wastes the thing they're best at. On a live product the loop runs from a customer email to production on its own. Human time goes to three moments: answering the business questions, giving the go on sensitive work, and choosing when customers see it. That's where domain knowledge and experience change the outcome, and every stage leaves a record you can check.

Agents run every stage. People step in at three points.

  1. 01 · agents

    Intake

    Customer emails and bug reports are read, triaged and turned into planning records.

    Human inputAnswer the business questions

    Anything that needs a business call goes to a decisions register, with the name of whoever owes the answer.

  2. 02 · agents

    Discovery

    A read-only planner explores the code, finds the root cause and writes the failing tests.

  3. 03 · agents

    Refine

    The work is cut into small units, each with a brief and acceptance tests.

    Human inputGo on sensitive work

    Billing, pricing, permissions, security, migrations and new features wait for a person's go. Everything else flows.

  4. 04 · agents

    Build

    A foreman dispatches units to builders, overnight if needed. The builder can't edit the tests.

  5. 05 · agents

    Review

    A different model reviews every pull request until nothing of medium severity is left.

  6. 06 · agents

    Merge

    Merged automatically once review passes and CI is green.

  7. 07 · agents

    Release

    Promoted from dev to UAT to production, with new features behind flags.

    Human inputChoose when customers see it

    Features ship switched off. A person decides when they go live.

  8. 08 · agents

    Verify

    The real flow is walked in a browser and the changelog is written and checked.

  • 454pull requests merged in twelve days
  • 0.6hmedian from opened to merged
  • 6production releases
  • 0reverts

The gate exists because green tests are not correct code. One independent review found seven bugs, including a privacy leak, in code that had already passed type checks, the build and 118 unit tests.

03 · Beyond the vanilla session

Why experienced engineers doubt agents, and why that's fair.

Many senior engineers formed their view of AI by cleaning up after it: an invented endpoint, a confident rewrite of code nobody had read, a pull request that passed its own tests and broke something else. Most of that came from vanilla sessions, with no memory and nothing grounding them in the real system. First impressions are hard to shake, and that one was earned.

The models aren't the difference now. The tooling around them is. Give the same model memory, a map of the code and a gate it can't talk its way past, and it becomes accurate and consistent. The record shows it: 454 pull requests in twelve days on a live product, and no reverts.

The problemVanilla sessionWith the scaffolding
MemoryStarts blank every sessionA team brain and turn-by-turn session capture
Knowing the codeGuesses from the files it happens to openRepo maps and a grounding pack before it plans
Past mistakesRepeats themGotcha notes it reads before it starts
TestsWrites its own until they passWritten first by a different context, and frozen
ReviewMarks its own homeworkA different model reviews every pull request
Product decisionsFills the gap with a guessStops and asks, through a decisions register
ReleaseWhatever merged is liveEarned through dev and UAT, behind flags

04 · For teams

The Agentic Delivery Flow.

The same stages and gates as the solo loop, with one deliberate difference. A person approves every pull request, because on a team trust is shared and a surprise lands on someone else. It is in trial with an engineering team, and it is voluntary: engineers keep what works for them. That is the leadership style behind it too. Lead by example, share what we know, and change things with the team rather than to it.

  1. 01

    Shape

    Epics are shaped and gaps found before refinement, so the meeting goes on decisions.

  2. 02

    Plan

    The engineer builds the plan and agrees the tests. The agent does the research.

  3. 03

    Build

    Builders and reviewers work in small slices inside the same gates as the solo loop.

  4. 04

    Ship

    A person reviews and approves every pull request before it merges.

05 · How it came together

Ten pieces, one loop.

None of this was designed in one go. Each piece closed a gap the previous one exposed, and together they became a delivery loop that runs from a bug report to production.

  1. Team brain and Repo Matrix

    A searchable memory and a mechanical map of every repo.

    Gap closed: Agents started every session blind.

  2. MCP-first access

    One set of memory tools any agent or teammate can call.

    Gap closed: Memory was tied to one person's setup.

  3. The independent review gate

    Nothing is done until a different model reviews it and the end-to-end test is green.

    Gap closed: Passing tests were being mistaken for correct code.

  4. Resumption-first memory

    Sessions saved turn by turn and built for picking work back up.

    Gap closed: Agents lost track of where they had stopped.

  5. The first overnight run

    Four features shipped unattended while I slept.

    Gap closed: The loop still needed me at the keyboard.

  6. Grounding packs

    A fixed factual brief handed to the agent before it plans.

    Gap closed: Agents planned without facts they didn't know to search for.

  7. The Drawing Office and the Yard

    A read-only planner writes failing tests and a blueprint. A foreman dispatches headless builds. 88 builds across ten projects in twelve days.

    Gap closed: I was choosing and driving every task.

  8. Model routing

    Each job goes to the cheapest model that can safely do it.

    Gap closed: Running everything on frontier models cost too much.

  9. Always-on builders

    Builders moved to a dedicated server with a dispatch queue.

    Gap closed: Builds depended on my laptop being awake.

  10. The Agentic Delivery Flow

    The same loop as a team method, with a person approving every pull request. In trial with an engineering team.

    Gap closed: The tools were being used as isolated helpers.

06 · Ideas we've built

Named, built, and written up.

Each of these started as a fix for a real delivery problem, ran in production, and has an article explaining how it works.

Grounding and memory

  • Grounding packs →

    A fixed brief built before the agent plans: the files, contracts and gotchas it would not know to search for.

  • The Repo Matrix →

    A mechanical scan of endpoints, schema and dependencies that agents check before they suggest code.

  • Triple-validated retrieval →

    Hallucination checks when knowledge is compiled and again when an answer is served, with every claim traced to a source.

  • Resumption-first memory →

    Sessions saved turn by turn and designed around picking the work back up, so nothing is lost to a crash or a full context window.

  • Gotcha files and ADRs →

    The bugs and decisions a team keeps rediscovering, stored where an agent finds them before it repeats them.

Delivery and people

  • Closed build loops →

    An agent works a backlog overnight, an independent review gates every pull request, and a person makes the merge. Four features shipped in one night.

  • The Drawing Office and the Yard →

    Design and build split across different models and headless agents, with defined handoffs between them.

  • Planning is a review

    Agents do the discovery legwork. The engineer builds the plan and agrees the tests, so their time goes on judgement.

  • Pre-refinement

    Tickets shared and shaped before the meeting, so refinement time goes on decisions instead of reading.

  • Beyond Sprints →

    A workflow playbook for teams where agents do most of the typing.

Inference, cost and compliance

07 · Infrastructure

Our own metal, routed by cost.

Background work runs on hardware we own, so there is no meter running on it. Interactive work uses frontier models where a person is waiting and quality matters most.

  1. 01

    Local inference

    An NVIDIA DGX Spark serves the resident model for background jobs, tuned for concurrency rather than single-stream speed.

  2. 02

    Always-on builders

    A dedicated build server runs the agent fleet, with one user and one bridge per account, so client work never shares a login.

  3. 03

    Model routing

    Each job goes to the cheapest model that can safely do it: frontier, local, or no model at all.

Let's have a chat.

No pitch and no audit. Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat