ai innovation engineer · redondo beach, ca
I take business value in whatever form it shows up — a prototype, a Figma file, a ticket, a meeting transcript, a freeform prompt — and then loop teams of agents to merge code, specs, learnings, and e2e tests to main. I keep the human decisions in a few named gates, and the agents own everything between them. Loop and graph engineering is where I am investing most right now.
I build the systems that engineering teams use to ship production software with AI agents, and I want what they ship to be spec-covered, test-proven, and compliance-aware. Most of the conversation right now is about which model you use, but in my experience the thing that decides whether an agent produces something you would actually merge is the engineering you put around the model.
The last year has been an arc for me. It started as prompt engineering, which for me meant ablation studies, evaluation harnesses, and working out which parts of a prompt were actually load-bearing. It became context engineering, where I wrote behavioral specs across the full Claude Code toolkit (CLAUDE.md, Skills, Rules, Hooks, Memory). Now it is loop and graph engineering: a pipeline that takes the work in whatever form it arrives, whether that is a prototype, a Figma file, a ticket, a meeting transcript, or a freeform prompt, and turns it into a versioned requirements catalog, then turns that catalog into a dependency-wired ticket graph, and then turns the graph into parallel agent lanes that build, verify, and ship, while a human decides at only a handful of named gates.
Every run of the pipeline leaves behind four durable artifacts rather than only the code, and those four are code, specs, learnings, and end-to-end tests. The specs include non-functional catalogs I promoted out of a real threat model, so there is a security baseline, a HIPAA overlay, and a PHI-handling catalog. I think this is where agentic engineering and vibe-coding part ways, and I have spent the year on the engineering side of that.
The highest business value and most complex product feature I have shipped recently is the one I demonstrated at AI Meetup #3. The prompt pipeline ingested a product designer's prototype and planned a Linear epic of 45 dependency-wired tickets, which agent lanes then drained in about 35 operator-paced hours. We authored 114 requirements before a line of code was written, opened around 92 PRs across 3 repos, finished with 111 of 111 e2e scenarios green, and reverted nothing. Eight human decisions steered all of it. That is the shape I am after: concentrate the judgment in a few places, automate the span between them, and let every run leave the system a little smarter than it was.
This is what I have learned about how much engineering it actually takes to let agent teams ship production software, and about where a human still has to decide.
"I spent far less time on the loop itself than on the graph, the gates, and the memory around it. That surrounding machinery is where the real engineering lives, and it is what lets agents ship software you would actually merge."
agentic loops & graphs — self-improving systems
Every principle below is in service of the same goal. I want human judgment concentrated into a few named gates, the span between those gates automated, and every run leaving the system smarter than it found it.
I author requirements before a line of code is written, and I give each one a permanent, immutable ID. When a requirement is superseded I tombstone the row with a pointer to its replacement rather than delete it. The point of all this is that every ambiguity has an address, so an agent can go read the requirement instead of inventing the behavior itself.
I write tickets as thin vertical slices and wire them together with blocked-by edges. Once the graph exists, readiness is something you can compute, so the loop derives the ready set from the graph and nobody has to hand-order the work. Laid out by build depth the columns become build waves, and the tall columns are where running lanes in parallel actually pays off. The critical path sets the floor.
Most agentic workflows I have used either interrupt you constantly or never stop at all, and I wanted a third path. So I concentrate every human decision into a few named, high-leverage gates: scope, epic approval, drain start, and PR merge. Each ruling lands in a durable artifact, which means no stage downstream ever has to ask you the same question twice.
I treat autonomy as a dial running from L0 (assisted) to L3 (auto-merge), and it has hard ceilings the agent is not able to raise for itself. Heavy-risk changes, which for me means models, migrations, auth, money, and sensitive data, cap at human-merge no matter what. And any run that authored a new requirement never auto-merges at all.
Every run leaves four artifacts behind: code, specs, learnings, and e2e tests. The learnings are captured before ship and then applied automatically by future planning runs, so an afternoon I spent debugging becomes a head start for the next session. Over time the things the system got wrong turn into the rules it works by.
I have learned not to trust a green I did not personally observe. The lanes report their results, and then the lead re-runs every gate, reads the diff, drives the live app, and queries the database directly for ground truth. Each check gets exactly one verdict, and I do not let "not run" stand in as one.
I never let a subagent return prose that something downstream has to re-parse. Every fan-out defines a JSON schema and the harness retries until the output validates, so orchestration is always consuming typed data. A pleasant side effect is that disagreement between agents becomes something you can type.
I put spawn budgets, 3-strike root-cause rules, round caps, token reserves, and broken-baseline hard stops on everything. Budgets are the contract that makes a multi-agent system debuggable at all. Without them you have no way to tell the difference between an agent making progress and an agent that simply kept trying.
I treat a prompt as a hypothesis and test it like one. Ablation testing shows me which components are actually load-bearing, cross-model validation shows me whether a finding generalizes, and LLM-as-judge lets me scale the evaluation. This Level-3 prompting discipline is where the whole arc started for me.
A systematic approach to making AI agent development reliable
A methodology and toolkit I built for making AI coding agents reliable at scale. Across four projects the delivery time came down measurably, from 8 weeks to 6 to 4 to 3, and I attribute that to friction-driven context refinement, hierarchical CLAUDE.md specifications, and autonomous verification loops.
impact
This is where I learned how much systematic context management does for agent reliability at scale. Putting behavioral constraints in CLAUDE.md lets you encode your values as persistent rules instead of repeating them in every prompt, and friction-driven refinement ends up working like reinforcement learning at the level of the workflow. Any team scaling AI coding agents in production can use this directly.
An AI persona dialogue system, paired with prompt ablation research
An open-source platform for multi-persona philosophical dialogues, paired with a systematic piece of prompt engineering research. The ablation study asks which components of a system prompt are actually load-bearing and which are decorative when you ask a model to embody a famous historical figure, and I validated the findings across Haiku, Sonnet, and Opus.
impact
A research contribution to prompt engineering: for well-known personas, minimal prompts work about as well as elaborate ones, and that holds across model capability tiers. Even Haiku produces a recognizable Nietzsche from nothing more than "You are Friedrich Nietzsche." I think this matters for prompt optimization, for context-window efficiency, and for how teams reason about what their system prompts are actually buying them.
Agent-in-the-outer-loop research over microtonal scale space
A Karpathy-style research harness pointed at an aesthetic domain. Erv Wilson spent his life searching for musical scales that serve melody and harmony at the same time, and this is an attempt to automate that search. A deterministic Python inner loop exhaustively scores scale families such as Combination Product Sets and Moment-of-Symmetry generators, and a Claude agent runs the outer loop, proposing hypotheses, writing pre-registrations before any code runs, executing batch sweeps, and filing verdicts in a public lab notebook. The subject matter is microtonality, and the engineering discipline behind it is the same one I use to make AI agents reliable in production.
impact
This showed me that the agentic-research pattern carries well beyond the SDLC. Frozen verifiers, pre-registration, and receipt-graded claims turn an aesthetic search problem into something you can falsify. I worked at Erv Wilson's side from 1995 to 2005, building his scale designs into software as he drew them, and this harness is a computational continuation of the search he ran by hand across thousands of diagrams. Decades of listening are what validate whatever the classifier finds.
Production work, written up in terms that travel outside the company that paid for it.
The highest-value and most complex feature I have shipped so far, followed all the way through: the pipeline ingested a product designer's prototype, decomposed it into a versioned spec, and planned a Linear epic of 45 dependency-wired tickets, which parallel agent lanes drained in about 35 operator-paced hours. I presented the whole thing publicly as "Agentic Loops and Graphs" at Planet DDS AI Meetup #3.
The funnel started with parallel readers mapping the prototype against the shipped specs, and they surfaced something I had not seen, which is that the prototype quietly bundled three separate initiatives. The highest-leverage human decision of the entire project was the scope gate right there, where I deleted roughly two epics of accidental scope before any code existed. From there we reconciled 122 requirement candidates against the shipped catalogs, which turned up 19 conflicts that were all resolved and 6 product questions I had to rule on myself, and then we authored 114 requirements with permanent, immutable IDs, all before a single line of implementation.
Then the spec was minted into 45 thin, vertical, end-to-end slices wired together by blocked-by edges. Once that graph existed, readiness was something the loop could compute, so it derived the ready set directly from Linear and nobody hand-ordered the work. Laid out by build depth the columns of the graph are waves, and every slice in a column became buildable the moment the wave before it merged. The tall columns are exactly where two lanes ran in parallel, and the critical path set the floor on how fast any of this could go.
Every lane ran the same nine-step spine: pre-flight, sync real data, implement with a file-domain-isolated strike team, verify against the running app, multi-lens review, fix every finding, iterate until clean, capture learnings, and honor the autonomy dial. I tiered verification to risk rather than to whatever was convenient, so the drain lead re-ran every gate personally, read every diff, drove the live app through browser automation, and queried the database directly for ground truth on the write paths. We finished with 111 of 111 end-to-end scenarios green. The defects had already been caught upstream in each lane's own QA loop, so by the time we reached the final gate it was really acting as confirmation.
The human budget for all 45 tickets came to eight decisions: a scope gate, a reversal blessing, six product rulings, the ticket-mint authorization, the drain gate, pacing, and a set of mid-build product questions that I recorded for a PM rather than letting an agent decide them. Every one of the roughly 92 PRs was approved and merged by a human after the artifact-level gates. I am happy to give agents autonomy over execution, and I am not willing to give them autonomy over judgment.
// the drain, replayed — sanitized interactive record
This is the real 45-ticket dependency graph from that Linear epic, laid out by build depth, so every column is a wave and each slice in it became buildable the moment the wave before it merged. The tall columns are exactly where the loop ran lanes in parallel, and the critical path of 22 hops is the floor. Click a slice to trace what it waited on and what it unblocked. I have scrubbed the identifiers and titles, but the topology, the risk tiers, the verification depth, and the merge timeline are all real.
44 of the 45 slices shipped and merged. The one exclusion, S-09, was ruled human-owned at the drain gate and was deliberately wired to gate nothing. The gaps in the timeline are me pacing the work, and because the loop is reconcile-first, resuming after a gap costs nothing.
// outcome
What I came away with is a repeatable pipeline rather than one lucky run: prototype to spec to ticket graph to drain, with human judgment concentrated into eight named gates and every merge backed by verification somebody actually observed. The loop itself was the smallest part of the work. The graph, the gates, and the memory are where the engineering is.
The engine underneath the drain: 13 compound commands, 6 spec commands, and a deterministic debate engine, all sharing one build spine.
Two pipelines share one engine, and the triage front door in front of them accepts the work in whatever form it arrives — a prototype, a Figma file, a ticket, a meeting transcript, a freeform prompt. Small work runs a single lane to a PR, and big features go through the spec-decomposition funnel and end in an epic drain. Whether a lane is running solo or as part of a drain, it runs the same spine: real-data sync, a file-domain-isolated strike team with a QA loop, live verification against the running app, multi-lens read-only review, fix-every-finding iteration, and learnings capture before ship.
Before anything executes, the plan has to survive an argument. The debate engine runs a 3-lens reviewer panel covering correctness, coverage, and consistency, and each reviewer traces the requirement through the codebase before it is allowed to read the plan. Then an author agent validates every blocker against real code. All of this is deterministic workflow code with severity gates, round caps, token reserves, and a formal dispute-escalation path, and when the disagreement is genuine that path hands it to the human rather than resolving it automatically.
Everything runs under budgets and stop conditions: spawn caps, a 3-strike rule keyed on root-cause tags rather than raw failure counts, broken-baseline hard stops, and an operator-owned-decision rule that stops the loop and hands back whenever a genuine product call comes up. Subagents never return prose. Every fan-out is schema-validated so that orchestration is always consuming typed data.
// outcome
The same engine serves supervised daily work and unattended epic drains, and what changes between them is the throttle rather than the guarantees. It fails closed. If a budget is exceeded or a schema does not validate, the workflow halts and escalates instead of quietly degrading.
I surveyed another team's prompt suite, found five patterns that travel, adopted them into a different greenfield codebase, and wrote up the playbook.
Prompt engineering is converging across teams, and as far as I could tell nobody was harvesting the parts that travel. So I surveyed a brownfield team's suite, roughly 6,800 lines with 21 slash commands and 5 subagent templates, and I read it the way you would read another engineer's library, asking what is generalizable and what is load-bearing on their particular context.
Five patterns travelled: risk-driven mode selection, file-domain isolation between subagents, task-log files as durable phase contracts, active-fixer review agents, and frontmatter-registered subagents. I adopted all five into a different team's greenfield suite, and then I wrote a teammate-facing report so that other AI engineers could pilot the same patterns without having to redo the archaeology themselves.
// outcome
One engineer's archaeology lifted the capability of several teams. The skill underneath it is pattern extraction across codebases, and what it really takes is knowing which conventions survive translation into a new codebase and which ones were only scaffolding for the old one.
Every run leaves the repo richer than it found it. Code is only one of the four outputs, and the other three are the ones that make the next run smarter. That is what the word "compound" is doing in compound engineering, and I think it is also where agentic engineering and vibe-coding part ways.
The change itself, built to a plan that was debated first, then QA-looped, reviewed through multiple lenses, and verified against the running app with live browser drives and direct DB reads before any PR opens.
Versioned requirement catalogs with permanent, immutable IDs, where a superseded row is tombstoned with a pointer to its replacement rather than deleted. They are consulted at write time, checked at the review gates, and snapshotted at ship. Alongside them sit the non-functional catalogs: a security baseline, a HIPAA overlay, and PHI handling.
A grep-able catalog of solved incidents, captured before ship and applied automatically by future planning runs. The debugging I did in one session becomes the head start for the next one, and over time the things the system got wrong become the rules it works by.
Playwright tests annotated to the requirement IDs they cover, audited continuously and snapshotted at every ship, so that the requirement catalog stays something you can actually test against.
The same spec machinery extends to security and compliance. I ran a STRIDE threat model on a healthcare AI product and promoted its findings into three living non-functional spec catalogs: a security baseline covering secrets, auth realms, tenant isolation, transport, and log hygiene; a HIPAA overlay that expresses the technical safeguards as engineering controls; and a PHI-handling catalog covering the 18 identifiers along with logging, URLs, proxying, retention, and de-identification. The gaps in our live posture then became a prioritized, requirement-cited backlog that the loop can drain, with every ticket mapped to the specific rule it violates and the file it lives in. The pipeline checks these catalogs at its review gates, which means the compliance posture is maintained as we build instead of being rediscovered during the next audit.
Three talks at the Irvine AI meetup, where I am one of the hosts, held at Planet DDS headquarters. The series tracks the same arc as the work itself, running from prompt engineering to context engineering to loop and graph engineering.
A live demonstration of Compound Learnings, which is the recursively self-improving part of the prompt pipeline. The learnings are captured before ship and then applied automatically by future planning runs, so the debugging from one session becomes the head start for the next one.
How to get from fuzzy inputs to versioned functional requirements, and how to treat end-to-end tests as first-class artifacts that live in the repo instead of as an afterthought. This is the talk where I make the case that a requirement catalog should be infrastructure rather than documentation.
Prototype to specification to dependency graph to agent-executed tickets, walking the full drain from end to end. This is the talk behind the case study above, and it covers how much engineering it actually takes to let agents ship production software, and where a human still has to decide.
// attendance figures are my own estimates rather than gate counts
Not everything I make is engineering infrastructure. This is what the same tooling produces when the deliverable is an educational interactive instead, with an original design system, dataset, interactions, and source discipline, built end to end with AI coding agents.
The Sierra as a routing surface — an interactive field atlas for Tioga Pass
A ridge decides where water goes, ice can overrun that decision, and infrastructure can rewrite it altogether. This atlas traces how the Sierra routes ice, water, electricity, and people around Tioga Pass, from the Tioga-age glaciers that overran the crest, to the Lee Vining conduit that gives Mono Lake its one artificial outlet, to the morning climb out of a terminal-lake town straight up against gravity.
Switchable ice / water / engineered / history / personal-route layers over a schematic oblique field model, with nine sender → payload → receiver traces and a date-controlled Mono Basin operating timeline.
An evidence drawer with 21 primary or authoritative sources. Where a claim is still only topographic inference I mark it visibly as unverified, and there is one published interpretation shown rejected and crossed out right on the map.
Keyboard-accessible map nodes, reduced-motion mode, skip links, and a fully responsive layout, all inside a dependency-free static page that runs offline.
It is a different medium with the same epistemics. Like the research harness above, every claim here is graded by the strength of its receipt, so it is either cited, marked as inference, or rejected on the record.
"I want the judgment concentrated in a few places, the span between them automated, and the learnings compounding from one run into the next."// agentic loops & graphs — what I took away
The discipline keeps moving, and I have watched the question change under me. Prompt engineering was asking "what do I say?" Context engineering was asking "what does the agent know?" Loop and graph engineering asks what the system does while I am not watching, and what it leaves behind when it is finished.
"Agent loops" usually get sold as a prompt, where you point an agent at the repo, walk away, and something magical happens. What actually runs one is a dependency graph, a versioned spec, named human gates, an autonomy dial, and isolated parallel lanes. I spent very little of my time on the loop itself and almost all of it on the machinery around it, and that machinery is where the engineering really lives.
There are two dials here, and I see them confused often. Level-3 prompting is a design-time discipline, where you shape how an agent reasons before it decides rather than only what it does. The autonomy dial (L0–L3) is a run-time policy about how far a pipeline may proceed without a human, and it has hard ceilings the pipeline cannot raise for itself. The first one governs the quality of an agent's thinking and the second one bounds the blast radius of an agent's actions, and you really do need both of them.
A pipeline that produces only code is not finished yet. Mine produces four artifacts on every run — code, specs, learnings, e2e tests — so each run leaves the repo richer than it found it. The rhythm I keep coming back to is to find the bottleneck, give the agent eyes and hands so it can see what it is doing, encode what it learned, and let all of that compound.
Designing the prompts, and designing the systems that hold them.
CLAUDE.md · Skills · Rules · Hooks · Commands · Memory
System prompt design, evaluation suites, and full-stack context engineering across the complete Claude Code toolkit. Behavioral specs, capability modules, constraint systems, automation hooks, and persistent memory, all orchestrated so that agents execute reliably.
plan → work → review · file-domain isolation · JSON schema enforcement
Multi-phase workflows with subagent teams. File-domain isolation, hard tool-call and retry budgets, JSON-schema-enforced outputs, risk-driven mode selection, durable task-log contracts between phases. Registered subagents with frontmatter, restricted tools, and active-fixer contracts.
any intake → decompose → reconcile → author → tickets · immutable requirement IDs
Turning any intake — prototypes, Figma files, PRDs, tickets, meeting transcripts, freeform prompts — into versioned requirement catalogs before any code is written, using parallel-reader decomposition, reconciliation against the shipped specs, permanent immutable IDs with tombstoned supersession, and requirement ↔ e2e coverage audits snapshotted at every ship.
JSON Schema · output contracts · typed disagreement
The prompt populates a schema, and the schema is what I treat as the artifact. Enforcing JSON schemas on subagent output makes multi-agent disagreement something you can type, and it means nothing downstream has to parse anything.
iterative agent calibration
Converting the friction in a conversation into persistent context, and building what I think of as "compressed histories of agent failures" out of the project learnings.
agent failure studies · constraint design
Studying how agents fail so that I can understand why they fail, and then converting those failure patterns into behavioral constraints that head off whole categories of errors.
steelman prompts · challenge loops
Building structured disagreement into agent workflows, so that an agent has to argue against its own conclusion before it is allowed to present it. This is L3 behavioral engineering.
The infrastructure agents work inside of, which for me means local CLI, MCP, and parallel orchestration.
slash commands · registered subagents · output design
Designing the workflows engineering teams use to ship AI features safely: slash commands, registered subagents, output design treated as a first-class concern, and schema-bounded contracts. What I build here are the loops and graphs the agents run inside of.
dependency graphs · computable readiness · parallel lanes · autonomy dial
Looping N parallel agent lanes over a blocked-by ticket graph until the epic drains, with readiness derived from the graph itself, a reconcile-first resume that makes a mid-drain context wipe cost nothing, per-slice verification tiered to risk, and an L0–L3 autonomy dial with hard ceilings the agent cannot raise.
Puppeteer · Chrome DevTools Protocol
Giving agents a way to see and interact with the UI. I have found that local CLI tools carry far less overhead than MCP for autonomous debugging workflows.
port management · CDP integration
Spinning up isolated worktrees for parallel AI agents with deterministic port allocation, so that agents start up and keep working reliably by design.
Remote MCP · tool exposure
Exposing tools to agents as MCP servers, using Figma Remote MCP for design integration and custom CLI tools for validation and verification.
launchd · perl · structured prompt pipelines
Health-check pipelines delivering structured notifications via launchd-scheduled diagnostics. Multi-line prompt substitution via perl + env vars. Self-locating data files for scripts deployed outside the repo. Autonomous PM-style workflows.
What ships the AI features once the agent's work is done.
React 19 · Next.js · Vite 7 · TypeScript
Building responsive and interactive user interfaces with modern React features, Next.js for optimal performance, and Vite for fast development.
FastAPI · Python 3.12 · Node.js · ASP.NET Core
Creating robust server-side applications with FastAPI microservices, async programming, and clean architecture.
asyncpg · asyncio.gather · SQLAlchemy AsyncSession · Celery
asyncpg, asyncio.gather concurrency-safety, and the SQLAlchemy AsyncSession lifecycle. I know the asymmetries that matter in production, such as what SQLite tolerates that asyncpg crashes on, where Loguru quietly swallows extra= kwargs, and when a bound async session can and cannot be shared.
PostgreSQL 16 · SQLAlchemy 2.0 · Supabase · SQL Server
Designing and implementing efficient database schemas with async ORMs, migrations (Alembic), and secure data management.
Pydantic / SQLAlchemy / FastAPI / React / TypeScript
Production root-cause work across Pydantic, SQLAlchemy, FastAPI, React, and TypeScript. I build multi-layer defenses for schema invariants (Alembic clamp, DB constraint, Pydantic, and a read-time helper), keep the backend and frontend parsers at parity (snake_case ↔ camelCase, JSON-escape normalization), and take migration safety on existing rows seriously.
Tailwind CSS 4 · Radix UI · Storybook · Figma Code Connect
Crafting beautiful and intuitive user interfaces with modern design principles, component libraries, and bidirectional design system sync.
pytest · Vitest · React Testing Library · MSW · Playwright
Comprehensive testing strategies covering unit tests, integration tests, API mocking, and Playwright e2e suites annotated to requirement IDs, with coverage audited against the spec catalog rather than only against line counts.
STRIDE · HIPAA technical safeguards · PHI handling
Threat modeling promoted into living non-functional spec catalogs — a security baseline, a HIPAA overlay, and PHI-handling rules — enforced at the pipeline's review gates and tracked as a requirement-cited backlog. The idea is to maintain the compliance posture as we build instead of going digging for it during an audit.
Dispositions, which is how I think about engineering teams and not only about code.
survey · identify · encode
I survey other teams' prompt suites and tooling, work out what travels and what is specific to that team, and encode the shared parts into reusable tooling. The skill underneath it is knowing which patterns survive contact with a different codebase.
loops and graphs for the SDLC itself
I build the loops and graphs engineering teams ship AI features inside of, and I treat the SDLC itself as a product surface: multi-agent workflows, subagent contracts, output design, and schema-first prompts.
decomposition before polish
I treat the presentation of an agent's output as a design decision that follows from how the work was decomposed, rather than as a layer of polish applied at the end. What the agent says is determined by how the work was broken up, so the structure of the prompt is really the user interface.
creator's default ↔ engineer's default
I am comfortable in both modes — the "creator's default," which is conversational, exploratory, and narrating, and the "engineer's default," which is state machines, budgets, schemas, and silence until there is a result. Most of the skill is knowing which mode a task calls for.
University of California at Riverside
// open to member-of-technical-staff roles · AI labs · agent orchestration
