Skip to content

ai transformation · agent fleets · proven output

Your company, rebuilt around AI.

I come in, map where the hours go, and replace the slow parts with agent workflows that spec, build, verify and ship. Or I point the same fleet at one big piece of software and hand you the code with the proof attached.

./see_the_loop ./book_a_call
5
phase loop
100%
changes verified
0
vibes shipped
fleet · ship-feature
  1. workflow run ship-feature --agents 6
  2. spec grilled JBA-127 scope ok, blast radius: 4 files
  3. orchestrator split into 3 units, 0 shared writers
  4. agent:api [wt-1] failing test → green
  5. agent:ui [wt-2] failing test → green
  6. agent:data [wt-3] failing test → green
  7. review 2 findings
  8. verify 1 confirmed, 1 rejected, fix applied
  9. belt lint ✓ types ✓ test ✓ build ✓ drive ✓
  10. merged decision log: 14 rows

ls ~/offers

Two ways to hire me

One is a job: you need software built. The other is a change to how your company builds software at all. Same engineer, same loop, different scope.

./hire

Hire me to build it

The classic engagement. You have a product, a feature or a rewrite and you want a senior engineer to own it end to end. I write the code, and I bring the agent fleet and the belt with me, so it lands faster and arrives with the proof attached.

Good fit for

  • A product or feature that needs shipping
  • Front-end heavy work in TypeScript, React or Electron
  • A rewrite or migration nobody wants to start
./email_me

./transform

Bring me in to rebuild the pipeline

The other kind. I come into the company, find the work being done by hand, and replace it with an automated AI pipeline like the one on this page: agents that spec, build, verify and ship, with a belt that checks every change. Then I hand it to your team and leave.

Good fit for

  • Product and engineering orgs of 5 to 50
  • Teams stuck at "we tried Copilot"
  • Founders who want an AI-native operating model
./see_the_loop

cat workflow.md

The loop

Five phases. Every engagement runs them, whether the job is a company or a codebase. Each phase ends in something you can hold.

  1. 1 discover
  2. 2 spec
  3. 3 build
  4. 4 verify
  5. 5 handover

01 $ discover

Discover

Two weeks inside the company. I sit with the people doing the work and map where hours go, where decisions get made, and where the same problem is solved by hand every week.

artifact An AI opportunity map with a costed first target

  1. 1.Interview every team that touches the product
  2. 2.Trace one real request from customer to deploy
  3. 3.Rank the bottlenecks by hours lost per week
  4. 4.Pick the first three things AI should own

02 $ spec

Spec

Nothing gets built from a vague ticket. Every unit of work is grilled before an agent sees it, and the architecture is sketched as types and signatures before code locks in the wrong shape.

artifact A spec an agent can execute and a human can audit

  1. 1.Grill each ticket: scope, acceptance test, blast radius
  2. 2.Sketch types, boundaries and module shape first
  3. 3.Run competing design candidates and pick a base
  4. 4.Write the failing test that defines done

03 $ build

Build

A workflow script fans the spec out to a fleet of agents. Each one works in its own git worktree on one bounded unit, and an orchestrator merges the results in dependency order.

artifact Reviewable pull requests with a decision log per change

  1. 1.Orchestrator splits the spec into independent units
  2. 2.Agents build in parallel, one worktree each
  3. 3.Competing candidates for anything with no precedent
  4. 4.Each unit ends in a checkable state before the next starts

04 $ verify

Verify

Done means proven. Every change runs the belt: lint, typecheck, tests, build and a live check of the running app. A second fleet of agents reviews the diff and adversarially verifies each finding.

artifact A green belt and a review trail you can rerun

  1. 1.CI belt on every pushed head
  2. 2.Multi-agent review, then a verify pass on each finding
  3. 3.Typed AI judgments for anything a rule cannot express
  4. 4.A verification skill drives the app the way a user does

05 $ handover

Handover

The point is that it keeps working after I leave. The team gets the skills, the workflow scripts, the verification suite and the memory the agents built up, plus the training to run it.

artifact A team that ships with AI without me in the room

  1. 1.Skills and agent instructions committed to your repos
  2. 2.Pairing sessions until the team runs the loop alone
  3. 3.Decision trail and memory files handed over
  4. 4.A 30-day check-in with the numbers from discovery

workflow run --agents 6

Multi-agent orchestration

One orchestrator, a fleet of agents, a second fleet that checks the first. A workflow script decides who does what and in which order. The script is deterministic. The agents are not, so the script never trusts them.

Orchestrator fans work out to agents, review and verify check it, merge lands it. orchestrator agent:api agent:ui agent:data review verify merge

  • orchestrator

    Splits the spec, owns the merge order

  • agent:*

    Builds one bounded unit in its own worktree

  • review

    Reads the diff, reports findings

  • merge

    Only a green belt lands

typesafe · system one

AI answers your code can branch on

Most "AI features" are a prompt and a regex. I build with TypeSafe's System One models instead. You ask one narrow question about some state and get back a typed answer with a probability. No prose to parse, no hallucinated JSON, and a threshold you tune on your own data.

Choice one of a set, with a distribution

Which team owns this incoming support ticket?

  1. billing 81%
  2. onboarding 12%
  3. infra 5%
  4. no match 2%

→ route(ticket, answer) if confidence > 0.7, else queue for a human

Noul probability a condition holds

Does this pull request change public API behaviour?

  1. yes 93%
  2. no 7%

→ p > 0.5 adds the api-review label and blocks auto-merge

Score position on ordered levels

How complete is this spec against the acceptance test?

  1. missing 3%
  2. partial 21%
  3. complete 76%

→ expected level below "complete" sends the ticket back to grill

Rules, lookups and maths stay in code. The model only answers the questions code cannot.

done means proven

What "fully checked" means

An agent saying "done" is not evidence. Every pushed head runs the belt, and nothing merges on a red step. The review fleet reads the diff, a verify fleet tries to knock down each finding, and a scripted driver clicks through the running app.

Every decision an agent makes goes in a log with the evidence behind it. You can audit a week of unattended work in an afternoon.

belt · every pushed head

  1. lint style and dead code
  2. typecheck no casts, exhaustive variants
  3. test behaviour through the public entry point
  4. build the real artifact, not "it compiles"
  5. review agent fleet reads the diff
  6. verify each finding checked adversarially
  7. drive verification skill clicks through the app
  8. log one row per decision: what, why, evidence

ls ~/engagements

Shapes of an engagement

2 weeks

Audit

The discover phase on its own. I map the company, cost the bottlenecks and hand back a plan you can run with anyone.

→ Opportunity map and a costed first target

3 months

Transformation

The full loop, embedded. One team first, then the pattern rolls out. Ends when the team runs it without me.

→ An AI-native engineering loop your team owns

4 to 8 weeks

Build sprint

A fixed scope built by the agent fleet, verified by the belt, delivered as reviewable pull requests with a decision trail.

→ Working software and the proof it works

./book_a_call

Start with the audit

Two weeks, one opportunity map, a costed first target. If the numbers don't justify the next phase, you'll have the plan anyway.

info@joe-lloyd.com