Interview talking points

The 3-minute Sentinel walk (§1). End on the thesis sentence: "Architecturally it's an orchestrated pipeline with an evaluator gate and a human authority boundary — the design assumes LLM output can't be trusted raw, and manufactures trust through checking." Then stop and let them pick a stage to drill into — you win every drill-down.

"Layered, and mostly not with prompts. In Sentinel: the action space is constrained by construction — the system can only produce PRs, never push or deploy, so the worst case is reversible. The analysis stage's access runs through MCP servers, which gives a permission-scoped, auditable seam. Then an adversarial reviewer screens outputs, and a human approves at the merge — the irreversibility boundary. Prompt-level guardrails exist but I treat them as UX, not security; 'can't' has to live in code and permissions."

"A standard protocol between LLM apps and integrations — hosts run clients that connect to servers exposing tools, resources, and prompts over JSON-RPC. It solves the M×N integration problem, like LSP did for editors. In Sentinel, production-log analysis goes through MCP: the integration is decoupled from agent logic — independently testable, swappable, permission-scoped — and the host mediates every call, so there's one choke point for auth and audit. In practice it turned a bespoke integration into a reusable, governed component."

"By assuming it, not preventing it. Mechanistically, models optimize plausibility, not truth, so I design so hallucination gets caught: ground the model in real data — Sentinel's analysis reads actual production logs via tools rather than relying on recall; constrain outputs to verifiable artifacts — a fix PR can be diffed, reviewed, and tested; then verify downstream — adversarial review plus a human gate. For anything structured, schema validation with a repair loop. The question I ask isn't 'how do I make it never wrong' — it's 'what's the blast radius when it's wrong, and who catches it.'"

"Tiered, like a test pyramid for probabilistic outputs. Deterministic checks first — schema validity, does-the-output-meet-contract, and for code, the best grader there is: does it apply and do checks pass. Above that, judged quality on curated cases. Two things I care about specifically: prompts are behavior, so prompt changes get regression-checked like code changes; and production feedback is the best eval source — in Sentinel, every human rejection at the approval gate is a labeled failure case, which is a free, continuously-growing eval set drawn from real traffic."

(Note: describe your eval philosophy in terms of what your system's architecture gives you — the gate-as-labeled-data point is grounded; don't invent specific eval-suite sizes or scores.)

Pick from the field guide (file 03 §8) and speak to the mitigation shape your system embodies:

"The failure class I respect most is cascading error — an early wrong conclusion, like misidentifying the faulty component from logs, silently invalidating everything downstream. Unchecked loops compound that. It's the core reason Sentinel is a staged pipeline with checks at stage boundaries rather than one long agent run: errors fail at a stage, visibly, instead of propagating into a confident wrong fix. And the adversarial reviewer exists precisely because generation checking its own work grades generously."

"Direct: the attacker is the user, jailbreaking through the chat. Indirect — the one that matters for agents: instructions embedded in content the system reads. My system's threat model is squarely indirect: it ingests GitHub issue text and production logs, both attacker-influenceable — a crafted issue could try to steer the fix generator. There's no reliable prompt-level fix, so the mitigations are architectural: least-privilege access, output constrained to PRs, adversarial review, human approval before merge. That's the 'lethal trifecta' logic — untrusted input plus privileged access is only safe if the action channel is gated, so we gate it."

"Structurally. The gateway gives one seam: token accounting per call, budgets and timeouts per call class, retries that respect rate limits, and fallback routing. On the prompt side: context discipline — tool outputs trimmed at the source, stable prompt content ordered first so prefix caching pays, tight output caps since decode is the expensive, serial direction. And Sentinel's work is async pipeline work, which buys freedom — no user is staring at a spinner, so we can trade latency for cost and reliability in ways an interactive product can't."

"The goal is resolved incidents, not autonomy. We put the human at the one irreversible step — the merge — and automated the expensive part: investigation and drafting. That division is why the ~70% reduction is real and safe: the system compresses toil; the human keeps judgment and accountability. I'd expand autonomy the boring way — per action-class, earned by track record and evals, never by optimism. And the gate has a second job: every approval or rejection is labeled feedback on system quality."

Honest self-critique reads senior — and each gap should come with a mechanism:

"A few things I'm clear-eyed about. First, human review capacity is the structural bottleneck — at 100+ PRs a month it works because per-item review cost is low, but scaling volume means triaging: auto-classifying low-risk fix categories for lighter review while keeping full gates on risky ones. Second, evals — I'd invest in a systematic regression suite mined from gate rejections, so prompt and model changes are gated by data rather than judgment. Third, richer verification between generation and review — more execution-based checking, since 'does it run and pass' is the cheapest, most honest grader for code. The theme: the architecture is right; the next wins are in measurement and graduated autonomy."