How AI capability becomes something a company keeps.
Every participant builds on their own repository from day one, so what they leave with is running: their own orchestrators, their own micro-tools, their own setup.
That is what we measure an engagement by, and it is why the method carries on past the workshop into the four stages below. Everything here follows from that.
Two principles
Bottom-up
We start with the people who actually do the work, not with strategy decks. That means engineers, and it can mean product, sales, HR and operations too.
You choose the scope, we tell you the trade-off
Some companies run this for engineering only. Others run every role at once. Both are real choices and we deliver either. What we will not do is let you make that choice blind: Stage 5 is the honest reason we recommend the wider one.
Five stages, from a first setup to capacity you can spend.
Each stage is worth doing on its own, and each one makes the next possible. Most engagements begin with the workshop and the cohort, and how far you go after that is your decision.
Build your own setup.
Four consecutive days, delivered in person. Each participant works on their own repository throughout, so nothing is theoretical.
Day by day
The user-invokable layer
Commands, memory, MCP servers, and the first real, reusable skills.
The system layer
Subagents, safety hooks, and a first orchestrator running on the participant's own project.
Orchestration as a craft
A multi-level orchestrator with self-correcting loops, fanned out across parallel git worktrees.
Company scale
Plugins, a private marketplace, governance, and AOF.
Every primitive we teach runs through the same loop, which is the difference between this and a tutorial. Participants finish the four days with a system they can audit, break and repair, rather than one they trust on faith.
The Hands-on Loop
After every primitive, a 10 to 15 minute cycle. You see it work, not a slide about it.
Run it
Kills slideware. You see it work, not a slide about it.
Verify it
Kills AI-magic. You prove the output line by line.
Bound it
Kills I-don't-trust-it. You set the limits and gate-checks.
Debug it
Kills when-it-breaks-I'm-stuck. You own the failure path.
What participants build
Participants leave with two kinds of thing, and a company needs both of them before it feels a difference.
Orchestrators
Reusable, predictable systems that take over a defined part of someone's work. Not a one-off script, but something that runs again and can be handed to a colleague.
Micro-tools
Small, bounded surfaces over whatever a person deals with daily. Tickets, documentation, schemas, Word documents, spreadsheets, logs. Anything where the mental cost of reaching into raw material is high enough that people simply do not.
Together, these two are what actually raises the technical competence of a company.
The same curriculum is available self-paced for organisations that need to reach more people than a room holds.
See the self-paced optionHow much your team actually learns
Real anonymized results from one of our workshops, based on a PRE vs POST skill assessment.
Each column is one participant, measured before and after. Representative anonymized sample from one 2-day workshop, run for every workshop.
Apply it to real work.
The workshop ends with everyone holding a setup they built and know how to extend. The cohort is for teams who want us alongside them while they point it at ten weeks of real work.
A cohort runs for 10 weeks with a specific team, in small groups. Small on purpose, so everyone gets real attention on the problems they picked. Multiple cohorts run in parallel, so headcount is not a constraint.
Two meetings per week
The session
A longer meeting where participants present what they built that week.
The standup
A short check to catch anyone who is blocked or needs help.
Participants set their own challenges
We advise and steer, but we do not hand out assignments. People choose what in their own work is worth automating, which means they choose problems they actually care about, and the results are immediately useful.
Presenting is the mechanism, not the ceremony
When someone shows a working tool to the team, two things happen. The rest of the team sees what is possible and raises their own ambition, and the builder gets feedback that improves the next iteration. This is what makes the effect compound rather than plateau.
The whole cohort is tracked on our own platform, augmented.club: progress, challenges, and what each person has shipped.
At the end of 10 weeks there is a checkpoint where results are evaluated against the metrics in Stage 3.
From one laptop to the company.
By this point every engineer has their own setup, tuned to the way they work. Stage 3 is how the good ones travel, on a promotion path that is deliberate and staged.
The promotion path
At each step, the question is the same: did this actually help?
We measure three things
Performance
How much time did this give back?
Cost
What does it consume in tokens?
Quality
Is the output good enough to rely on?
Measured with observability tooling, Langfuse and OpenTelemetry, so the answer is a number rather than an impression. Token spend is tracked the same way, per team.
As things mature, skills stop being invoked by hand. They become autonomous agents connected to the tools a company already uses: Slack, ticketing, CI.
AOF, the Agentic Operations Framework.
AOF is our answer to what happens when there is suddenly a lot of this.
What it covers
Ownership and versioning
Every orchestrator and skill has an owner and a version, so nothing is anonymous infrastructure.
Promotion gates
The staged path from personal to company-wide, with an explicit bar at each step.
Risk levels on actions
Actions are classified, and the classification decides what an agent may do unattended.
An approval floor
Below a defined line, a human signs off. The line is set by you, not by us.
Budgets as blast radius
A token budget doubles as a safety limit, since it caps how far a runaway agent can get before it stops.
Evidence as a by-product
Audit evidence is generated by running the system, not written up afterwards as paperwork.
The unglamorous, permanent part
Orchestrators need maintenance. Regular cleanup, retirement of what no longer earns its place, and improvement along the same three axes: performance, cost, quality.
The earlier stages produce capability that holds on its own. AOF is what keeps it holding once there are fifty orchestrators instead of five, and once the people who wrote them have moved on.
We do not claim this is a solved problem. It is how we see it working well in practice, and we are building it in the open as we go.
The question we hand back.
Here is the part most vendors leave out.
If you speed up engineering alone, the bottleneck moves.
It lands on product, on sales, on customer onboarding, wherever the next constraint sits. The engineering gain is real and largely invisible, because the organisation cannot absorb it. This is why we recommend building across roles rather than sequencing them, and why we say so before you scope the engagement rather than after.
On the engineering side
Throughput protections come with the territory: automated quality and safety checks, agents that review pull requests and summarise for a human what genuinely needs attention versus what can simply be approved.
The larger question is organisational
Freed capacity can become:
- More features
- Faster delivery
- Smaller and more autonomous teams
- Fewer layers of coordination
People whose routine work is automated tend to become more T-shaped, capable across several functions rather than deep in one. Engineers in particular shift toward orchestrating and improving systems rather than producing code directly.
What a company does with that capacity is its own decision. We deliver measurable capacity. We do not tell you how to reorganise around it.
Nothing you build is stranded.
We build on Claude Code because it is currently the strongest harness for this work. It is not a dependency.
Skills, prompts, context files, and MCP servers are portable, and configuration can be migrated by script to other harnesses such as OpenCode. What needs re-validating after a switch is behaviour, since a different model responds slightly differently to identical configuration. The method and the artifacts survive.
Start with a free diagnostic call.
Thirty minutes, no pitch. We map your team, your goals, and how much of the arc makes sense for you.
Book a free diagnostic callGet your team orchestrating AI systems while others are still vibe-coding.
After a free 30-minute skills map, we take your developers to multi-level orchestration and secure, parallel delivery, at the quality standard you already expect. No pitch.