STAR + system design pack

Lived stories from my master bank (Aug 2026). I pick one or two that match their problem. I do not tour ten projects. Later I add a charter win. I don’t write a new STAR library per logo.

Numbers I actually say (don’t mash into one vanity total):

P vs O: Lucid EDI, Kafka, payments, Lucid RAG/governance decisions are P. Public AegisAI, Enterprise RAG, sentinel-brief are O. I never say those GitHub binaries ran inside Lucid.

How I pick (10 seconds)

STAR 1 — Supply-chain EDI AI platform (Lucid) — lead story

Best for: almost every Staff+ AI / platform / founding loop. This is the one I keep cold.

S: Lucid had 20,000+ suppliers — native and non-native — locked into SAP + TrueCommerce EDI. Over $10M a year in licensing. Non-native formats TrueCommerce couldn’t handle meant painful manual work. Most orgs just renew the contract.
T: This was an architecture problem dressed up as a vendor-cost problem. We didn’t own the supplier integration layer. I owned the proposal, architecture, and delivery of an in-house platform that kills the TrueCommerce dependency and onboards every supplier type.
A: Discarded “find a cheaper vendor.” Bet: AI absorbs the format complexity that was paying the license.

Two RBAC-gated UIs (rehearse — this is not yet muscle memory):

• Internal: GSM, AP, MRP/material planning, transportation — exceptions and workflow.
• External: every supplier org. Packed and on a container → they submit shipment details → both sides track transit → transportation verifies receipt → invoicing, and the supplier sees that journey end-to-end.

This is not a chatbot with tools. Stack I actually shipped (LOCKED 2026-08-13 — you confirmed router + shared context + Kafka role):

RBAC UIs (internal GSM/AP/MRP/transport · supplier portal)
  → 3 LangGraph orchestrators (Onboarding · Releases · Shipments)
       each: ROUTER (supervisor) → specialists
             + model router (cheap classifier vs stronger reasoner per node)
       shared StateGraph context: supplier id, parsed EDI, exceptions, HITL flags
  → shared RAG / vector store (all three retrieve; not a private index per agent)
  → Kafka topics = durable handoff between orchestrators and backend microservices
       (SAP adapter, portal, notifications) — graph run is in-process LangGraph
  → 34 specialists total, multi-model

1. Supplier Onboarding — first contact → go-live, native and non-native. Onboarding team 200 → 25. HITL only on true exceptions.
2. EDI Releases — outbound DELJIT/DELFOR demand signals. Material planners still send Saturday-night releases by design — human judgment stays in the demand loop. (CONFIRM: that manual step sits inside this orchestrator vs upstream.)
3. EDI Shipments — inbound. Parses 84,000-parameter JSON across supplier formats without a per-supplier schema mapping — that’s why TrueCommerce could die. Validation agent checks ASNs against DELJIT releases and flags wrong qty / mismatched PO / bad part number to the supplier portal and SAP at the same time. No silent failures. Exceptions go to the right queue with context.

CONFIRM before a stack drill: which vector product (don’t say Qdrant unless that’s Lucid P); which models sit behind the model router; exact Kafka topic names. RAG contents still CONFIRM (format specs vs historical exceptions vs SAP schema).

Organizational conflict: SAP directors pushed back — vendor relationships, skepticism at 20k-supplier scale. One month of architecture + POCs, VP sign-off. SAP teams stayed unsupportive in implementation. I reduced the SAP surface to invoice generation and kept shipping.

R: TrueCommerce fully replaced. $10M licensing gone. $7M annual net after platform costs. 20,000+ suppliers migrated, including previously unsupported non-native types. Onboarding 200 → 25. We own the integration layer.

What I’d say (~60s):

Lucid was paying over ten million a year to TrueCommerce for EDI on 20,000+ suppliers, including formats the vendor couldn’t handle. I didn’t shop a cheaper translator. I treated it as “we don’t own our supplier layer.” We built an in-house platform: two RBAC UIs — internal GSM/AP/MRP/transport and a supplier portal — and three LangGraph orchestrators, 34 specialists. Each orchestrator is a router to specialists, plus a model router so a cheap classifier doesn’t spend a frontier model. Specialists share graph state for the case and a RAG layer over vector stores — not 34 private brains. Kafka is the durable backbone between those graphs and the microservices — SAP, portal, notifications. Inbound parses huge per-supplier JSON without a mapping table per partner — that’s the bet that killed the license. Outcome: TrueCommerce gone, ten million licensing eliminated, seven million net, onboarding 200 to 25. SAP directors hated it. VP signed; I still had to shrink the SAP surface to invoices to ship.

What I’d do differently:

Lock SAP-team commitments before implementation, not after VP approval. “Approved” is not the same as people who didn’t choose the direction helping you.

Follow-ups I keep cold

“What was YOUR architectural call?”

Replace TrueCommerce entirely — not a cheaper vendor. LangGraph, not a rules table: each supplier is a stateful graph. A router sends the case to the right specialist; a model router picks cheap vs strong per node. Shared graph state plus RAG over vector stores so the next specialist isn’t amnesiac. Kafka between the graphs and the microservices so a SAP post isn’t trapped in process memory. Suppliers change EDI specs; the graph diffs snapshots. A static table and a new vendor couldn’t.

“Walk the architecture — router, agents, RAG, Kafka.”

Three in-process LangGraph orchestrators. Each has a supervisor router onto specialists — 34 total, multi-model. Context is the StateGraph object for that supplier case, plus a shared vector-backed RAG layer all three retrieve from. Writes are serialized per supplier ID so they share context without trampling it. Kafka is not the graph runtime — it’s the event backbone: durable handoff to SAP adapters, the portal, notifications, and between orchestrators when the work has to survive a process restart.

“Walk the three orchestrators.”

Onboarding is go-live. Releases are outbound demand. Shipments are inbound ASNs and exceptions. Same router pattern, same shared RAG. 34 specialists across the three — not one mega-agent.

“34 agents — how do they not step on each other if they share context?”

They should share context — parsed EDI, exceptions, HITL flags — or you get 34 amnesiacs. What they must not share is concurrent writes on the same supplier. Supplier ID is the partition key. The orchestrator serializes mutations. RAG is read-mostly across orchestrators.

“Why Kafka if LangGraph is already stateful?”

Graph state is for one case in flight. Kafka is for the rest of the platform — microservice boundaries, retries, consumers that aren’t in the graph process. If SAP is slow, I don’t hold a Python worker hostage. Dual-write/cutover story for the bus itself is STAR 2.

“Which vector store / which models?”

I’ll name the Lucid product and model SKUs only if they’re CONFIRM-filled. Spoken default: vector store behind the shared RAG layer; model router = classifier/extractor vs heavier reasoner. I won’t guess Qdrant or a lab model name onto Lucid.

“What does a supplier see?”

Their own portal, not the internal UI. Submit packing/shipment, track transit, see invoicing after receipt. Validation flags land there, not only inside Lucid.

“Supplier misses the 24–48h ASN SLA?”

It becomes a relationship problem. Procurement and the account manager get on a call. Contractual penalties for production impact. The SLA has teeth. I don’t pretend the agent fixes politics.

“What broke in production?” — this is also my failure story

A malformed ASN passed schema validation and SAP accepted the transaction but never created the inbound delivery. Silent. Caught 18 hours later in reconciliation. Fix: the agent polls SAP for inbound-delivery creation within five minutes of EDI receipt and escalates if it’s missing. Schema-valid is not business-valid.

“10→2 vs 200→25?”

200→25 is onboarding on this platform. 10→2 is a different workflow confirmation — I don’t mash them in one sentence. Evidence bank.

STAR 2 — Kafka: Confluent → AWS MSK

Best for: Amazon/Microsoft/infra loops; “influence without authority”; “you’re not just the LLM guy.”

STAR 1 already uses Kafka as the EDI event backbone. This STAR is owning the bus — Confluent → MSK — not a second unrelated Kafka. If they ask “so you just migrated a vendor?” I point at the agents that sit on it.

S: Event backbone on Confluent at ~$1M/year, compounding as we scaled. Business case was obvious. Organizational case wasn’t.
T: I owned the proposal, the risk plan, and execution to MSK.
A: Infra director’s position was legitimate: production is stable, sales pipelines sit on this, disruption beats savings. I didn’t argue. I built evidence. Parity in dev. Parity in staging under load. Dedicated pre-prod — same partition count, same consumer groups, same throughput patterns — four weeks before production. Known gap: custom Confluent SMT plugin had no MSK equivalent — rebuilt as Lambda, logged, not handwaved. Staged cutover with dual-write and consumer-lag monitoring. Political move: brought the infra director into pre-prod so he could see the data. He became the internal presenter.
R: Full MSK in production. $1M+ annual. Zero cutover incidents. Infra director presented the results.

What I’d say (~60s):

We were on Confluent at a million a year, and that was going to compound. The infra director was right to worry — this carries sales pipelines. I didn’t win a meeting. I stood up a pre-prod that matched partition count, consumer groups, and throughput, ran it four weeks, rebuilt a Confluent SMT as Lambda because MSK didn’t have it, then dual-wrote with lag monitoring. He sat in pre-prod, saw the data, and presented the win himself. Zero incidents. Million-plus a year. I’d bring the skeptic into the risk plan earlier next time — faster than converting him after.

Hardest technical problem — category LOCKED, mechanics VERIFY:
I confirmed the category is partition rebalancing during dual-write. The paragraph below was drafted from Kafka fundamentals + the documented cutover (matched topology, phased consumers, dual-write). I will not rehearse it as autobiography until I correct it against what I actually changed.

Draft to verify: Confluent and MSK didn’t rebalance identically. Default eager assignor meant a consumer restart paused the whole group. We were restarting consumers in phases onto MSK — stop-the-world rebalances and duplicate-processing risk in the window we were trying to prove clean. The intended fix is cooperative-sticky so one join/leave only moves that consumer’s partitions. If that’s not what I did, I say the real fix, not this paragraph.

“What if pre-prod had failed?”

Stay on Confluent that quarter. Pre-prod was a decision gate, not theater. “You were right, here’s what we still have to fix” was a real option.

STAR 3 — Lucid global payments (Stripe / regional rails / GIB)

Best for: commerce, multi-market, “business enablement,” Adobe/Gusto-shaped loops.

S: Lucid had no global payments platform. One rail does not work everywhere — regulation, banking, buyer behavior. Deals were dying in the Middle East because there was no way to close.
T: Own architecture and implementation of a multi-rail platform for EU and Middle East.
A: Pattern from Volvo: global commerce dies at payments if you assume one gateway. EU: Stripe as base, market methods as first-class types — Klarna + Giropay (DE), iDEAL (NL). Different settlement, failure modes, compliance. Middle East: Stripe doesn’t operate there. GIB (Gulf International Bank) as the rail — not a cute adapter; it unlocked a sales channel with no prior close path. Unified gateway abstraction: adapters behind one interface so product/eng don’t care which rail is live. Led 9+ seniors across US/India/APAC on this work — independently true, not copy-paste from Volvo. If a panel notices the same shape: “different company, similar team shape.” Resume also has Chase ACH — US rail; I don’t drop it just because this story is EU+Gulf.
R: Rails live. GIB enabled Gulf car sales that had no payment path. Middle East sales went from losing deals at checkout to a working experience.

What I’d say (~60s):

Lucid couldn’t close Gulf deals because the payment rail didn’t exist, and EU isn’t one Stripe checkout either. I didn’t bolt a second gateway into the happy path. Adapters behind one interface — Stripe plus Klarna/Giropay/iDEAL in EU, GIB in the Gulf where Stripe isn’t a thing. Chase ACH on the US side. Product doesn’t switch on country in the core flow. I’d start banking and compliance earlier next time — GIB’s regulatory track added time I should have parallelized from day one.

CONFIRM before a payments deep-dive (don’t invent): per-rail retry/failure semantics; fallback if GIB is down mid-sale; currency/settlement reconciliation across Stripe, GIB, ACH.

STAR 4 — Governance before side effects (Lucid P + public O)

Best for: Adobe/Genentech/Gusto/Nvidia safety rooms. Same pitch as always — this is the deep dive.

S: EDI grew to 34 agents across three orchestrators, then more agents around procurement and knowledge. Each team grew its own access control, logging, and escalation. No consistent audit. Compliance couldn’t answer “what did the agent do, why, who authorized it.”
T: Shared control plane for every agent: invisible to developers, auditable by compliance, reusable for new agent types without a rewrite.
A: Discarded the agent-builder — chat UI with tools bolted on. Lucid design: policy evaluation before irreversible writes; HITL with a full context packet; signed audit; registry so an agent declares capabilities before it ships. Early miss: ~8% of new non-native supplier types hit HITL from misclassification. Every escalation became a labeled example; uncertainty threshold moved; ~2.3% within six weeks. Trained three engineers to write policy; within six weeks they authored without me in the loop.
O (separate sentence): Public AegisAI is the inspectable encoding of that pattern. sentinel-brief uses the same gateway idea on one irreversible send — personal production, not Lucid. I do not claim the GitHub binary ran inside Lucid.

R: Side effects cannot bypass policy. Three people write policy independently. Compliance can reconstruct an action. Reuse is the point — not a snowflake per agent.

What I’d say (~60s):

Once you have 34 specialists writing to SAP and a supplier portal, “the graph said so” is not a control plane. I refused another agent builder. Allow, deny, or a human — then a signed audit. Early on, about eight percent of new non-native suppliers went to HITL because classification was jumpy. We treated those as labels, not shame, and it dropped to about two percent. Lucid is that production decision. If a panel wants to click the pattern, the public gateway is O. Not those binaries inside Lucid.

“How is this different from logging?”

Logging records what happened. Policy decides whether it is allowed to happen. If the gate says no, it doesn’t run.

“OPA / gateway down?”

Fail closed on irreversible writes. Reads can degrade. I don’t give writes a free pass because Redis was sad.

STAR 5 — Access-aware RAG (Lucid P + public O)

Best for: knowledge, leaks, citations, compliance.

S: Internal knowledge — docs, policies, runbooks — was unsearchable. Keyword search couldn’t enforce “not everyone sees every document.”
T: Retrieval that is accurate and structurally authorized. Citations compliance can trust. Not a post-filter.
A: Discarded retrieve-then-filter — it demos well; Tenant B is already in the candidate set. Access-before-ranking: permission scope first, then hybrid dense + BM25, then generate. LLM-as-judge checks citations actually support the claim before we serve.
R (P, from master bank): citation accuracy up 3 points on that judge vs baseline; 99.6% uptime; first AI path in the org to pass compliance review without a redesign; search time hours → minutes.
O: Public Enterprise RAG is the inspectable Strict/JWT + decline path. Demo vs Strict labeled. I don’t invent P95s off the free-tier demo.

What I’d say (~60s):

Vector DB is implementation. Access control is architecture. Retrieve-first means the wrong document is already in the candidate set — and often the cache. I filter by principal, then rank, and I want a decline when the corpus doesn’t support the answer. Lucid: citation accuracy moved, compliance signed the design without a rewrite. Public spine is the same principle under a Strict principal. Not a claim that demo is Lucid’s production index.

“Doesn’t access-before-ranking kill recall for power users?”

It can. I raise k for broad principals and take a bit of latency. That’s the trade — tracked per permission tier, not wished away.

CONFIRM: 3-point / 99.6% windows and whether “first to pass compliance” is speakable with legal. If a panel smells demo SLOs, I drop to architecture + decline path and offer provenance offline.

When they ask leadership — Volvo ecommerce (0 → 6 markets)

Use when: OEM rooms, Java/Spring, “tell me about building a team,” mentoring. Not my AI lead story.

S: Volvo had no in-house ecommerce. Buying a car online wasn’t a product yet. HQ engineering in Sweden, spec-driven, distributed.
T: Lead two teams (9+ seniors) from scratch and scale internationally.
A: Spring microservices + React. ~15-minute purchase journey, real-time prequalification, payments. Mentored nine interns, 100% converted.
R: Live in six markets. Contributed to 20% revenue increase, ~10% of Volvo global sales — “contributed to,” not sole causality. Also cost −20%, test time −80%, heap −60%, bugs −30% — I pick one or two tied to a decision, not the whole shopping list.

What I’d say (~45s):

Volvo had no in-house ecommerce. I led two teams, Spring and React, a fifteen-minute purchase path, six markets. Mentored nine interns, all converted. We contributed to a twenty percent revenue lift — I’m not going to pretend I personally moved global sales. Java/Spring here is real history, not a keyword.

OPEN — do not invent: one named Sweden-HQ disagreement (position, resolution, metric). Without it this is my most-quantified story and my weakest under “hardest cross-cultural conflict.” Honest line until I fill it:

I don’t have a named HQ fight I’m willing to defend on this call. I won’t make one up. I can talk distributed spec-vs-delivery tension and how we shipped market by market — or pick Lucid SAP-director conflict, which I can walk.

When they ask a live agent I own — sentinel-brief (O)

Personal production. Not Lucid. Best for “scrape → summarize → email” JDs and “show me something that runs.”

Six-node graph: fetch → diff → write_brief → eval → gateway_and_email → archive. Nine allowlisted sources. Snapshot diff — only net-new items. Eval rejects low-signal runs (min deltas, citations, structure). email.send is the only irreversible side effect. Langfuse spans. Nightly cron. Demo: sentinel-brief.vercel.app (canonical alias may be sentinel-brief-ruddy — I confirm the live URL before a screen).

Honesty: write_brief is still a structured template; LLM synthesis is next. Governance and eval shipped first because those are what you can’t retrofit.

What I’d say (~40s):

I got tired of nine tabs every morning. There’s a nightly agent that diffs nine sources, refuses to send if the eval gate fails, and the only thing that can leave the box is email — and that goes through a gateway. Reads are autonomous. The send is not. It’s personal production, not Lucid. Happy to walk the eval checks.

Honest gaps — don’t fake a STAR

Roadside Assistance / telemetry (Lucid) — resume bullet is real. Full STAR is not. Usable today:

My depth is the cloud side — consume live vehicle telemetry (location, battery, fault) and trigger roadside service. I did not build the device-side MQTT/TCU stack; that’s a dedicated connectivity team. I’ll ramp that faster than it looks because most of the seat is the cloud half.

Unified communications chat / RSA partner integration — confirmed real, no numbers or decisions captured. I say “I can take that offline” rather than invent retries and SLOs.

Follow-ups after any STAR

“What did you discard?”
STAR 1: cheaper EDI vendor + a rules table + one mega-agent that owns RAG and tools. STAR 2: argue the infra director in a meeting. STAR 3: one global Stripe checkout. STAR 4: agent builder. STAR 5: retrieve-then-filter.

“What would you do differently?”
STAR 1: SAP commitments before VP theater. STAR 2: skeptic in the risk plan on day one. STAR 3: banking/legal parallel from day one. STAR 4/5: deny-path evals in CI before the happy path looked good.

“Was that you or the team?”

I owned the architecture call and the ADR. Delivery was we. Savings are we-delivered / I-led-architecture — then provenance if they press the number.

“10→2 staffing” if they saw it on the site — evidence bank Q3. Don’t mix with 200→25.

Full graded versions: Behavioral calibration. CONFIRM rows: evidence bank.

FDE tilt: same STARs. Discovery/wedge language from fde-deployment/, not a sixth identity.

System design 1 — Multi-tenant agent platform (P0)

1. Short board: Multi-tenant isolation
2. Principal depth: Deep path → graded ai-system-design/09

System design 2 — Agent gateway / tool authorization

What I’d say first (~45s):

I’d start by naming the irreversible tools — refund, publish, CRM write, deploy, SAP write / supplier-portal mutation. Those don’t bypass a gateway. Allow, deny, or approve, then a signed audit. Fail-closed if the gateway is unreachable. I will not add HITL after the demo lands.

Agent proposal → Gateway SDK
  → AuthN/Z (principal + tenant)
  → Policy engine (allow / deny / approval_required)
  → HITL queue if required
  → Execution broker / tool
  → Signed audit + trace export
  → Optional FinOps meter

Trade-offs: fail-open vs fail-closed; in-memory registry vs Postgres; sync policy vs cached bundles.
Prod call: fail-closed for irreversible tools. HITL on writes. Audit always.
What I’d refuse: “we’ll add HITL after the demo lands.”

System design 3 — Enterprise RAG

What I’d say first (~45s):

I’d start with where authZ sits relative to retrieve. If they retrieve first, that’s the bug. Filter by principal, then hybrid rank, then decline when the corpus doesn’t support the answer. I won’t invent P95s off a free-tier demo.

Query + Principal
  → Access filter (tenant/clearance) BEFORE rank
  → Hybrid retrieve (BM25 + dense / RRF)
  → Cross-encoder rerank
  → Optional graph expand
  → Context assembly + citations
  → Generate OR decline-to-answer
  → Eval spans + golden suite

Prod call: Strict JWT. Decline when unsupported. CI adversarial cases.

System design 4 — Eval-gated ship path

What I’d say first (~45s):

I’d start with what false confidence looks like on this path — fluent wrong, retrieval miss, unauthorized tool, schema-valid EDI that SAP didn’t actually post. Golden fixtures, scorers, a CI gate that can fail the merge. A dashboard nobody pages on is vibes.

System design 5 — 0→1 wedge (Founding / FDE muscle)

What I’d say first (~45s):

I’d start with constraints — identity, data, tools — then score a wedge. At Lucid the wedge was EDI cost, not an “agent platform” brand. LangGraph router + shared RAG + Kafka to the microservices came because the wedge needed them — not because I wanted a stack slide. One workflow, HITL on the irreversible write, then expand only after the gates pass.

What I ask them

What irreversible actions will agents take in the first 90 days?

Where does retrieval sit relative to authorization today — honestly?

What evals actually gate a production ship vs a dashboard nobody pages on?

What’s the biggest failure you’ve already seen from an AI feature here?

If they can’t name a scary write, I ask about refunds, publish, CRM, deploy, or an ERP post anyway.