« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes
Phase 00 — The Platform Mental Model: Five Layers, Budgets & Two-in-a-Box
Answers these JD lines: "Own the end-to-end technical architecture of the AI & Agentic Platform's five-layer stack: Action Gateway, Agent Kernel, Control Plane, Knowledge Foundation, and the Users and Channels layer" · "shared accountability for platform availability, performance, cost, security posture, and architectural evolution" · "operate in genuine two-in-a-box with the existing Platform Product Owner".
Why this phase exists
Every later phase builds one mechanism. This phase builds the frame those mechanisms hang on — and it is the phase that decides whether you sound like a senior engineer or like a principal architect in the first ten minutes of an interview.
Three things go wrong when the frame is missing:
- People promise availability they cannot deliver. Five layers at "three nines each" is not three nines — it is 99.5%, 3 h 36 m of downtime a month. If you have not multiplied the chain, your SLO is a wish.
- People argue about reliability instead of computing it. An agent taking 20 steps at 95% per-step reliability succeeds 36% of the time. That number ends the "let's add another tool" conversation in one line, and no amount of prompt engineering moves it.
- People treat cost as a finance problem. It is an architecture problem: the scratchpad grows quadratically, a 30% failure rate multiplies effective cost by 1.43, and a cache hit rate is a design parameter with a dollar value.
And one organizational thing: two-in-a-box is a real operating model with real mechanics. Shared accountability without shared instruments is just two people blaming each other after an incident. The instrument is the error budget — a number both owners can see, that converts "are we reliable enough?" into "have we spent 43.2 minutes yet?".
Five ideas do the load-bearing work here, and the lab builds every one:
- The five-layer stack is a defence ordering, not a diagram. Each layer denies a different class of bad action, and no layer trusts the one above it. Knowing which layer stops what is the difference between a picture and an architecture.
- Availability composes multiplicatively in series and through failure probabilities in parallel. Serial depth is the enemy; graceful degradation is how you shorten the chain without deleting a layer.
- An error budget is a shared currency. \( 1 - \text{SLO} \), allocated across layers, spent by incidents, and burned at a measurable rate that decides whether you page or file a ticket.
- A latency budget must be written before the design. Every component gets an allocation, and the headroom line is the fallback line — a fallback that does not fit the budget is decoration.
- Cost per successful action is the unit economic. Not cost per token, not cost per request. It couples quality to money and is the sentence that gets an evaluation programme funded.
Concept map
- The five layers: Users & Channels → Control Plane → (Agent Kernel ‖ Knowledge Foundation) → Action Gateway → bank estate. Cross-cutting: model layer, identity layer, infrastructure backbone.
- Defence ordering: identity → policy → contract → quota → evidence. The first layer that can deny should deny, and each layer denies independently.
- Availability: series \( \prod A_i \); parallel \( 1-\prod(1-A_i) \); downtime tables; the difference between a dependency and a degradable dependency.
- Error budget: \( 1-\text{SLO} \); allocation across layers; burn rate; multi-window multi-burn-rate alerting; the error-budget policy that governs the two-in-a-box relationship.
- Latency budget: per-component allocation, serial tail compounding, parallelizable stages, fallback feasibility.
- Reliability of a loop: \( p^n \), retries \( 1-(1-p)^r \), the three levers (reduce
n, raisep, make failure recoverable). - Cost: per-action token math with cache tiers, quadratic scratchpad growth, cost per successful action.
- Two-in-a-box: shared on-call, shared roadmap, error-budget policy, decision rights, and the written artifacts (ADR, ORR) that make shared accountability auditable.
The lab
| Lab | You build | Proves you understand |
|---|---|---|
| 01 — Platform Reference Model & Budget Calculator | a five-layer platform model with composed availability and degradation, an error-budget allocator with multi-window burn-rate alerting, a latency-budget checker that validates fallback feasibility, a loop-reliability model, a cost-per-successful-action calculator, and an admission pipeline that reports which layer denied and why | that platform architecture is arithmetic plus an ordering of defences — and that you can produce both on a whiteboard under pressure |
Integrated scenario (how this shows up at work)
Week one. The Platform Product Owner tells you Wholesale Banking wants to launch a "payment investigation" agent, and Group Risk has asked what SLO the platform offers. The CTTO's office wants a number by Thursday.
The junior answer is "99.9%, like our other services." The principal answer takes twenty minutes with a spreadsheet and comes back with something an auditor can read:
"The request path crosses six components in series. At the availability each one currently demonstrates, the composed number is 99.10% — 6 h 28 m a month, which is not an offer. Two changes fix most of it. Retrieval degrades gracefully: if the reranker or the graph store is down we still answer, just less well, so they stop being serial dependencies — that takes us to 99.50%. A second model provider with tested, budget-aware fallback takes us to 99.66%, after assuming 20% common-mode correlation because they share a region. The action path cannot beat the core banking system's own 99.7%, because it is genuinely serial and cannot degrade — money either moves or it does not — so it lands at 99.36%. The offer is therefore: 99.5% on advisory answers with a plan to 99.9%, 99.3% on actions, a p95 of 3 s, and a published degradation ladder. The error budget at 99.5% is 3 h 36 m a month and we split it 40% to the model layer, 30% to integrations, 20% to the kernel, 10% to everything else, because that is where last quarter's incidents actually landed."
Every number in that paragraph comes out of this lab.
Deliverables checklist
-
Lab 01 green under
LAB_MODULE=solution pytestand under your ownlab.py. - You can draw the five layers from memory and name what each one denies.
- You can compute composed availability for a chain, and explain why a degradable dependency is not a serial one.
- You can derive the error budget for any SLO and window, and say what burn rate pages you.
- You can write a latency budget that leaves room for exactly one fallback, and show it.
- You can state cost per successful action for a given design and show the quality lever.
- You can explain two-in-a-box as an operating model with instruments, not as a job title.
Key takeaways
- Serial depth is the enemy of availability. Five nines-and-a-half layers make a two-and-a-half-nines platform. Shorten the chain or make links degradable.
- A degradable dependency is not a serial dependency. This is the single highest-leverage architectural move available to you, and it is why the degradation ladder is designed in daylight.
- The error budget is the shared instrument of two-in-a-box. It converts a values argument into arithmetic that both owners can act on.
- Headroom is a design output, not a leftover. If the budget has no headroom, the system has no fallback, and the first provider blip becomes an SLO breach.
- Optimize cost per successful action. Quality is a cost lever; that framing funds evaluation work that "reduce token spend" never will.
- Know which layer denies. "Defence in depth" is a slogan until you can name, for a given bad action, the specific layer that stops it and the two behind it that would have.