The method
How it works
Four weeks. Two sessions a week. One architecture problem that grows with you. You'll finish with a reference architecture you designed yourself — and the confidence to defend it in any review.
Here's exactly what that looks like, and why it works when longer courses often don't.
The method
Ultralearning, adapted for architecture
The cohort is built on ultralearning — a set of principles from Scott Young's research on how people pick up hard skills faster than traditional programmes allow. I didn't invent ultralearning. I adapted it to a domain I've lived in for two decades: designing distributed systems that have to work.
Four principles do most of the heavy lifting.
Directness — you learn the real thing, not a proxy
No toy problems. Every exercise is a constraint pulled from a real production agent system — the kind of problem I've actually debugged. If it wouldn't show up in a post-mortem, it doesn't show up in the cohort. That sounds intense, but it's actually the part that makes this easier: you're not learning abstractly and hoping it transfers. The transfer is built in.
Drill — you get strong at the parts that feel weak
Most courses move everyone through the same material at the same pace, which means half the room is bored and half is lost. Here, when you notice "I can design memory layers but eval harnesses are a fog" — we spend time on eval harnesses. The structure is designed to find your weak spots and give you reps on exactly those.
Tight feedback — you find out quickly, in a good way
Every artifact you produce gets critique the same session you produce it. Peer review first, my review second, your revision third — all inside three hours. The short loop is what makes the learning fast. It also makes it kind: you don't sit for a week wondering if your design is okay. You know by dinner.
Retrieval under pressure — you practice the real move
You design from a blank page, explain it to other senior engineers, and revise when they spot something you missed. That sounds uncomfortable, and it is the first time. It also turns out to be the single most effective way to make knowledge stick — far more than re-reading or note-taking. By week three, most participants tell me the "designing live" part has become their favourite.
The four weeks
What you'll build, week by week
Foundations and your first architecture
We start with the decisions every agent system hinges on: control flow, state boundaries, failure modes, basic orchestration. By Friday you've sketched a first-pass architecture for your assigned problem. It won't be perfect — no first draft is, mine included — and that's exactly what we want. The gaps are what the rest of the cohort is for.
Memory and state
This is where most agent systems quietly fall over in production. Short-term versus long-term memory, what belongs in vectors versus structured stores, how context windows leak cost, retrieval strategies that survive scale. You'll extend your Week 1 architecture with a real memory layer and talk through the trade-offs you chose. By the end of the week, the fog around memory design usually lifts entirely.
Tool use and orchestration
Choosing tools, running them in parallel versus sequence, handling silent failures, and the patterns for multi-agent coordination that don't turn into distributed-systems nightmares. Your architecture grows a tool-use layer, and we stress-test it against failure modes from real incidents. This is often the week participants say "oh — this is the part nobody explained before."
Evaluation and production hardening
The part most courses skip. Offline evals, online evals, drift detection, the observability surface you'll want at 3am, and the governance hooks that help security sign off. You leave with an architecture you could hand to a team on Monday — and the vocabulary to explain every choice you made.
Inside a session
What a session actually looks like
Sessions are three hours, not one. That's deliberate — an hour is enough to lecture at you, not enough to do real design work together. Three hours is enough for you to build something, get it critiqued, and improve it, all in the same room.
Sprint opener
Quick review of what you produced between sessions, plus one real-world failure mode I'll walk you through — usually pulled from a post-mortem relevant to the week's topic. No slides. More like "let me show you something weird that happened."
Design block
The central problem of the session. You design — on a shared whiteboard, in a doc, sometimes alone, sometimes in pairs. You're not following along. You're building. I'm there the whole time, circulating, asking questions, nudging when someone's stuck.
Walk-through and critique
You explain your design to two other senior engineers, and they explain theirs to you. You'll spot things in each other's work that none of you would have seen alone — that's most of the value. I join in, ask questions, point out what's working, flag what isn't. Nobody's trying to "win." Everyone's trying to ship better architecture by the end of the hour.
Revise and commit
You make revisions on the spot, or you write down the specific change you'll make before next session. That commitment is tracked — gently, not scarily. It's how we keep momentum between sessions without anyone feeling chased.
Between sessions, plan for about 4–6 hours of focused work — revising your artifact based on the critique. It's not busywork; it's where the learning consolidates. If your calendar genuinely can't hold that right now, it's worth waiting for a cohort when it can. The method only works if the time is there.
A glimpse inside
Week 3, Tuesday
To make this less abstract — here's what a typical Tuesday of Week 3 might look like.
The problem
Design the tool-use layer for an agent handling customer support escalations. Latency budget: 3 seconds end-to-end. Five tools of varying reliability. Non-negotiable: no single tool failure brings down the loop.
Sprint opener
I walk through a real incident — a misconfigured retry policy on a CRM lookup that took down an agent fleet for 40 minutes. Concrete, not theoretical. You'll see exactly what the fix looked like after.
Design block
Everyone designs the tool-use layer from a blank page. Some choose parallel-first with fallbacks. Some go sequential with aggressive timeouts. Someone usually proposes a hybrid with a reliability-weighted router. There's rarely one right answer — which is the whole point.
Walk-through
The reliability-weighted router looks elegant until someone notices the routing logic itself has no eval — a single point of failure. The parallel-first designs hold up better, but cost twice as much in LLM calls, which matters for this latency budget. These are exactly the trade-offs you'll be making in your own work.
Revise
Everyone leaves with a revised design and one specific thing to test before Thursday.
That's one session. There are eight.
Honest expectations
Why four weeks is enough (and what "enough" honestly means)
Let me be straight with you: four weeks won't make you an expert in every corner of agentic systems. Nobody can honestly promise that — not in four weeks, not in four months.
What four weeks will do is give you a defensible mental model of how production agent architectures actually work, a reference design you built yourself, and the judgment to know which corners of the space you still want to go deeper on — plus the skill to do that deepening on your own, without needing another course. That's what ultralearning really buys you: not completeness, but a foundation strong enough that you keep learning fast on your own afterwards.
And the cohort doesn't fully end at week four. There's a 60-day support period afterwards — a private channel, fortnightly group office hours, and the rest of the alumni. Most of the real integration into your day job happens in those 60 days, once you're applying the work to your own systems. You won't be on your own when it matters most.
Who this is for
Staff engineers, principal architects, and senior engineering managers with at least five years of shipping production systems, who now need to design and defend agent architectures in their current role.
You don't need to already know agent systems. If you did, you wouldn't need the cohort. What you do need is solid footing in distributed systems — we won't be covering what a queue is or why eventual consistency matters. Everything past that, we build together.
Who this probably isn't for — yet
Engineers earlier in their career who'd honestly get more out of strengthening fundamentals first.
Anyone looking for a credential to list rather than a skill to use — the pace rewards people who want to do the work, not perform it.
People who prefer to learn alone at their own speed — the method is deliberately social, and the group is most of what makes it work.
If any of those describe you right now, that's completely fine. I'm happy to point you toward resources that'll serve you better at this stage. Just say so on the application.
What happens next
The application is three short questions: your current role, what you're trying to ship, and one architecture problem you've been wrestling with recently. I read every one personally.
If it's a fit, I'll send you a calendar link and we'll have a real conversation — no sales pitch. If it isn't a fit right now, I'll tell you honestly why, and usually point you somewhere more useful.
Either way, you'll hear back from me.