AI engineering · site reliability · incident leadership · Minneapolis-St. Paul
Lito Zarate Biala

Optimistic Systems Thinker. Site Reliability Engineer & Creative Agentic Builder.

I get to the heart of an issue: find the bottleneck under the symptom, fix it at the foundation, and prove the core of the business runs better.

The same fix has to land in every room: engineers, executives, and customers, each in their own language. At Wells Fargo I lead site reliability and incident management for the banking systems that cannot go down, and I bring AI into that world the only way it can be brought: governed, human-reviewed, and measured, with a sign-off before anything touches production. AI built to pass a bank's safety checks, not slip past them. My whole career asks one question: how do we know this is actually working? So I built six open-source projects that test AI judgment, memory, safety, and incident operations. If a measured number drifts, the build fails. And every front page says where the design loses.

Three minutes? an eval report with every miss named · a published correction · a flip test, true by construction

Portrait of Lito Zarate Biala

Six projects, one question

These six projects aren't a pile of demos - they're a stack. Each layer answers a different form of one question: how do we know it works - and that it's safe to run? Every one runs in seconds with zero API keys (nothing to sign up for or pay for), and every one ships a click-through tour you can hand to any stakeholder.

Safety

skill-tripwire

A tripwire for poisoned skill files. Agents now load skills, tool descriptions, and config files shared online - and a poisoned one carries hidden instructions the model obeys - prompt injection, delivered as configuration. This scans for the shapes with no honest place in a config file: invisible characters, download-and-run one-liners, over-broad shell grants, read-and-exfiltrate lines. It fails closed, ships as a CLI and an MCP server, and states its own limits in numbers.

A million randomized inputs: 0 crashes, 0 hangs, 0 false alarms on 450,360 synthetic benign files (fixed seed, reproducible; bounds false alarms on generated text, not in the wild)
Static detection is a triage floor, not a boundary. Its catch rate is an upper bound (one person wrote the rules and the samples); every miss is named in the report, and a corpus written by someone else is the top open item
Memory

wiki-memory-lab

This AI keeps its memory in a wiki of plain-text pages anyone can read. It checks an index and pulls only the pages it needs, adds to old pages before making new ones, and must write a reason before deleting anything. A paper trail for what your AI believes.

Pulling only the pages it needs costs 0.61× of loading everything
With a small, constantly-used set of notes, loading everything wins (1.27×)
Evaluation

agent-mutation-lab

I test AI code reviewers the way you'd test a proofreader: plant one known mistake, mix in clean copies, and only count a catch at the planted line - crying wolf scores zero. New: nine copies dealt independent synthetic errors climb at exactly the rate the arithmetic predicts, a mechanism demo rather than a model result, while a copycat control stays flat.

Caught 9/10 planted bugs at the planted line, within two, with 0 false alarms
One blind spot left in on purpose, so the scorecard shows a real miss
Judgment

adversarial-chambers

A courtroom for AI claims: one AI argues, a second's only job is to attack, a third judges - nobody plays two roles. Every rejected claim gets a written cause of death. And the flip test cross-examines the judge itself: change only the judge's standing instruction, and see if verdicts change.

Flip test on two scripted judges, true by construction: evidence-led 0/8 flipped, agreeable 3/8 - exactly the ambiguous cases. Proves the instrument lights up, not that any real judge passes
Case study, clearly labeled (not a benchmark): 3 of 4 real verdicts flipped on one instruction change
The improvement loop

memory-repair-lab

The AI never changes - its notebook does. Every miss gets filed as a labeled note about what went wrong, every fix names the miss it repairs, and progress is graded on an exam sealed before work began. A sugar-pill arm (same effort, fake fixes) checks the gains are real.

Sealed-exam recall: 8/10 → 10/10. Sugar-pill arm on the same budget: unchanged
Published on purpose: an arm that teaches to the test - and pays for it in tokens
Operations

oncall-router-mcp

The first ten minutes of an incident are eaten by three questions: who owns this, who do I wake and by when, and what does the runbook say to try first. This answers them to an AI assistant as MCP tools - plus the one most tools get wrong, where we stand on the clock, measured from when impact started rather than from when somebody opened a ticket. It reads one local file. No network, no keys.

Five tools over one local file: owner, escalation path, first move, the impact clock, and a timeline review - zero runtime dependencies
No live integrations, by design: it does not read your incident tool, your rotation, or your monitoring - you feed it one file

Every number above regenerates from scratch on each repo's automated build, on Windows and Linux - if a fresh run disagrees with the published claim, the build fails. (skill-tripwire's million-input figure is fixed-seed reproducible rather than run on every build - a million scans is too slow for CI - but a smaller run of it is gated there.) The bundled agents are deliberately simple scripts, so these numbers prove the measuring instruments, never any AI model's intelligence. No number on this page comes from a live model; the instruments are built so a live-model run can be published the same way, with its caveats, and the first one is: skill-tripwire's pre-registered live-judge study sits in that repo's eval folder as a partial run with every id named, and none of its numbers appear here.

Want the guided tour? Every project explained the way I'd brief a decision-maker - precise analogies (sealed exam envelopes, sugar pills, smoke alarms), a working vocabulary for terms like best-of-k and unhobbling, and the questions I'd genuinely love to be asked about each project.

Take the tour →

⚔️ Play the portfolio - AI Quest: SEV-1

An 8-bit adventure where AI engineering is the magic and the final boss is a major outage. Recruit a roster of eight and field every one of them at once - four of the companions are projects from above, the rest are their own people - spend the reps you earn down one of three growth roads, and run the incident bridge that takes down the five-headed Hydra. Clear everything and a post-credits finale opens: THE GRAND STAGE, a live industry exercise where the team is measured, not crowned, WORLD CLASS. The balance came out of a simulator you can run yourself: the ledger shows which numbers are checkable from this repo and which are only asserted.

The game ships its own test suite - the title screen runs every check live in your browser, so the count is shown, never quoted - which only tells you they passed. So I broke it on purpose: 250 real defects, seeded one at a time, to find out whether the tests would notice. Then I wrote seven guards to close the gaps that found - and measured them against a second batch of 107 defects sealed before those guards existed. On the gaps they were pointed at they scored 55%. On the sealed batch, 5.6%. The hardening did not generalise, and the sealed envelope is the only reason I know it. The ledger carries that result, a correction to an earlier version of this number that compared training-set performance against a held-out score, the confounds I can name, and all 151 defects still uncaught. You can re-derive every figure in your own browser from the mutation lab.

> THE SEV-1 HYDRA rises!
> You cast FIVE-WHY… the root cause is exposed!
> Grade: S - think you can beat it?
▶ PLAY NOW

one sitting, and the game times and grades your run · saves at the inn · gear, shops, a growth tree & a roster of eight · speedrun grading · plays on your phone · one static file, no sign-ups, no downloads.

How I work

The habits are the résumé. These are the rules every project above obeys - the same instincts that keep a bank's critical applications reliable, pointed at AI.

Every claim is re-tested on every change.

Each published number ships with how it was measured and its honest caveat in the same row, generated from data - never typed by hand. If a fresh run disagrees, the build fails loudly.

Losses publish above the fold.

The case where the design loses, the deliberate blind spot, the flipped verdicts - leading with the boundary is what makes the rest of the page believable.

Every deletion carries its reason.

Kill ledgers, prune records, repair citations: an unrecorded decision gets re-argued in a month by someone who never saw it die. Audit trails are a product feature, not paperwork.

Demos run where the customer is.

Every project installs with nothing, runs in seconds without API keys, and carries a walkthrough a stakeholder can click through - because the room where engineering meets the customer is where systems earn trust or lose it.

Hard things get explained simply.

Recipe boxes, smoke alarms, courtrooms, sealed envelopes: if I can't explain the system to the person who depends on it, the system isn't finished.

The challenge set comes from outside.

A catalogue I wrote measures my imagination, not the tool: skill-tripwire publishes its catch rate as an upper bound for exactly that reason, and a corpus written by someone else is its stated top open item. The same rule sealed the game's second batch of defects before the guards existed.

Background

I'm a technology leader at Wells Fargo - 12+ years of leadership, 5+ years across site reliability and incident management for critical banking applications: monitoring built to catch trouble before customers feel it, root-cause discipline, platform work through cloud migrations, and distributed teams across the US and India. Regulated industry, real stakes, enterprise reality.

The AI chapter started inside that reality, not outside it: I lead governed GenAI delivery for incident operations, built hands-on (Python, Streamlit, TypeScript, and agentic tooling: Claude Code, Codex, Devin) with evidence trails, fail-closed behavior, and human sign-off gates on the road to production. Then I took the same discipline public: the six projects above, measured, auditable, and honest about where they break. I run my own knowledge system the same way - a markdown wiki my AI agents read and write as long-term memory, which is where the memory projects came from.

Before engineering leadership: a psychology degree and years managing a busy bar - which is to say, translating between systems and the humans who depend on them has always been the job. I like the room where the demo has to run, the question has to land, and the system has to earn its keep in someone else's environment - and years of incident bridges have made ambiguity, discovery under pressure, and honest push-back my home turf.

Now
Vice President, Lead Digital Platform Services Manager, Wells Fargo - site reliability & incident management
AI at work
Governed GenAI for incident operations · human-in-the-loop by design · risk-gated road to production
Focus
AI agent evaluation · LLM observability · agent memory · multi-agent orchestration
Foundation
SRE & incident management · observability (Splunk, Grafana) · platform engineering & cloud migration · ITIL
Training & courses
Anthropic Academy: Claude Code in Action · Introduction to Model Context Protocol (2026) · Splunk Fundamentals 1-3 & Cloud Observability
Education
Data Analytics Boot Camp, University of Minnesota · B.A. Psychology, Metropolitan State University
Building with
Python · Claude Code & Claude API workflows · GPT-5.6 via Codex · GitHub Actions CI