Yehuda (Udi) Levy

Principal Architect and Developer · Pearland, Texas · https://udsterleads.com

I build systems that do real work without me in the room, and then I build the parts that make that safe. Most of my code is now written by agents. My job moved to the part they can't own: the world they work in. That means deciding who owns what, what they may do alone, how they ask me, how a finished job gets noticed, and what counts as proof.

How I Think and Build with AI

Start from the outcome, establish what's true, keep control of anything irreversible, shape it for the experience, and make the knowledge outlive the session. I run it as a loop, not a checklist: start loose, look at what comes back, tighten with one specific correction.

The five-station loop: Outcome, Truth gate, Control gate, Shape it for the experience, PersistBlack and white diagram of the five stations from left to right. Two small correction loops sit under Truth gate and under Shape, and a dashed return line runs from Persist back to Outcome so the next session starts smarter."this is good, but...""way too many words"next session starts smarter1. Outcomewhat must exist2. Truth gateevidence or [check]3. Control gateirreversible waits4. Shapesimplest to act on5. Persistbecomes a skill
  1. 1. Outcome. I open with what has to exist when the work is done, and who it's for.
  2. 2. Truth gate. A conclusion has to be earned. "How can you be sure?" "Not just kinda but do." "Do not make assumptions." Absence of evidence isn't evidence of absence, so unknowns stay visible as [check].
  3. 3. Control gate. Research first, ask me one question at a time, plan, review, then act. Agents run freely on reversible work; anything irreversible waits for my approval.
  4. 4. Shape it for the experience. Cut it down to the simplest thing that still lets someone act, with the detail underneath. My name never goes on AI-sounding writing.
  5. 5. Persist. Every good investigation becomes knowledge or a skill, filed in the right place, so the next session starts smarter.

The rules the agents work under

  • One owner per kind of thing. Every kind of request has one owner that holds its file, its format and its memory step. Route first, then work.
  • One door per risk. Actions go through one approval tool, memory through one memory tool, releases through one ship script. One door is one place to check, log and change.
  • The tool decides, the agent classifies. The agent names what kind of thing it's doing. A table I own answers, and an exit code says what happens next. Agents branch on numbers, not on a feeling that something is fine.
  • Doubt fails closed. No rule means ask. An unreadable rule means ask. When two rules fit, the stricter one applies. Only my own message in my own chat is a yes.
  • Nobody grades their own work. Builder, tester and reviewer are separate sessions. The tester never sees the builder's transcript.
  • Quiet doesn't mean done. Owed work stays owed until it's acknowledged, and a sweep tells me if it sits.
  • Attention is the scarce thing. Do the work first, then ask once: one thing, recommended choice first, a picture if it's visual, paced through my day.
  • A correction becomes a rule. It's dated, in my words, in the file the agent reads every turn. Every claim carries its evidence or a [check].

Selected Systems and Work

Multi-Agent Orchestration, gate, udi-hub, and the me app

An always-on agent on its own server takes anything I send, hands it to the one skill that owns that kind of thing, passes long work to sub-agents so it stays reachable, and only interrupts me for real decisions. Builder, tester and reviewer run in separate sessions where the tester sees only the ticket and the live system, never the builder's transcript. Every finished sub-agent, approval and tap is owed work until acknowledged; a plain-code sweep runs on a timer without spending model tokens when quiet, waking the agent only when something waits. Across my active repositories, the agent runs parallel sub-agents, merges reviewed pull requests, writes most of the commits on main, and ships locked builds while its pipeline refuses any go-live attempt that fails a gate.

  • gate (action authorization): Before anything leaves the box or can't be undone, the agent asks one Python tool (standard library only) that answers Auto, Ask, Refuse, or Hold by exit code from a plain-markdown policy table across every action kind. Adversarial review found working exploits in the first version, mostly the agent finding a way to become its own approver; every exploit was fixed and pinned in the test suite, and deliberately reintroduced holes were each caught by a test. Most checks in the first month came back Ask on purpose.
  • udi-hub (shared memory): Every AI agent I use reads and writes the same shared hub of tools and curated memories across my sources through one door that checks a policy table on every call. The policy folder is read-only to every agent, and the tool separates keeping raw text from letting a model learn a fact, storing safe entries, holding sensitive ones for my yes, and refusing what crosses a boundary.
  • the me app (attention pacing): It queues and ranks decisions by deadline, value and my time, sending one card at a time with a preview and one tap to answer, steered by saying "slower", "break", or "more". Pacing rules are pure functions covered by a full test suite and mutation checks, holding back low-priority card pushes until a quiet window.

TuckABook (tuckabook.com)

Live since July 2026

Families make illustrated, narrated storybooks starring their own people, and a team of AI agents on my server writes the code, watches production and ships releases, with my yes as the only gate. Cast first: each person (or pet) becomes a locked character sheet before any book is drawn. Every page is drawn from the locked sheets plus a style plate and palette, a second model checks for drift, swapped faces or blended characters, and words are lettered on top so they are spelled right, editable, narrated, readable by a screen reader and printable.

Work is split across bounded agent roles (Board, Ops, Prod, Dev, Ship) and MCP tools so agents test the app on the same path a family uses. Every AI call logs which model actually answered so silent fallbacks surface immediately, and a ship guard refuses to deploy while any family is mid-drawing, shipping continuous releases from the agent's server on my yes without rollbacks.

A major airline: maintenance technology and an AI toolkit

Principal Architect and Developer · 2020 to now

I sit between architecture and delivery in the maintenance-technology organization with no direct reports, and I lead through evidence, technical judgment, tools that make other people faster, and decisions framed clearly enough for leadership to act on. Over the last year I turned that seat into an AI-assisted way of working that peers across teams adopted, from engineers to directors.

  • Team AI toolkit: I built a shared, versioned toolkit of agent skills and read-only integrations (observability, CI/CD, source control, tickets, databases, the office suite) that is read-only by construction, runs with the user's own permissions, and requires that every claim carries its evidence or a [check]. Peers across teams adopted it.
  • Enterprise migration scoping: An enterprise HR-platform migration changed field formats that a fleet of apps might depend on, and nobody knew which would break. I wrote the rule first: never call an app "no impact" because no code matched; check every layer (data, identity, integrations, databases, files). I verified the first few by hand, then ran the rest with parallel sub-agents while one orchestrator made every rate-limited call one at a time, challenged my own HIGH findings, and corrected classification errors in a leadership report; other portfolios adopted the method.
  • Truth gate in production incidents: When recurring database timeouts persisted after scaling up the database, I proved with A/B tests that small serverless CPU allocations were starving the TLS handshake while the query itself was fast; I cut the handshake from seconds to a fraction of a second in infrastructure code with a rollback plan. Repeatedly in production investigations this year, the key move was correcting a louder conclusion.
  • Architecture and delivery leadership: I served as technical lead for a holiday-freeze release incident remediation (shipping a batched fix to production in days), built the production foundation for a new API gateway that a fleet of apps migrated onto, and led discovery and architecture for a maintenance scheduler rebuild, alongside code reviews, mentoring and enablement sessions on agentic engineering.

Tabula Rasa (tabularasa.bot)

Students prove they understand a subject by teaching a blank AI, fact by fact and rule by rule, until it can pass an interview graded against the teacher's rubric. Instead of trusting a prompt paragraph to keep the bot blank, I built a live evaluation suite: taught questions it must answer, untaught ones it must refuse, and attempts to talk it out of its rules. A model change ships only after that suite passes. Every Server Action is covered by an authorization sweep test that calls it as the wrong person and checks it refuses and writes nothing.

The Arc

Why it matters: the operator years are why I start from the outcome, not the technology.

  • 2013 to 2019: I worked as a business operator, built a marketing team from scratch, and then founded and ran my own marketing-technology company.
  • 2018: I taught myself to code, with mentors.
  • 2019: I took my first developer job working in Python, Django and React.
  • 2020: I joined a major airline as a contractor working on planning software.
  • 2021: I became a full-time employee and senior developer.
  • 2023: I became a principal architect and developer.
  • 2025 to now: I serve as an architecture and cross-team technical lead, running agents at scale at work and at home.