Loop Engineering's Missing Building Block: Why Embedded Systems Are a Safer Playground for AI Agents

Google engineer Addy Osmani recently proposed Loop Engineering: stop having manual conversations with AI, and instead design automated loops where AI agents run, fix, verify, and iterate until the job is done.

The concept is compelling. But after reading it, I kept getting stuck on one question: the loop finishes, AI says “done,” how do you actually know it’s done?

Osmani’s answer is sub-agent review, have another AI act as a manager to check the work. But AI reviewing AI is ultimately probabilistic. Both models agreeing something is correct doesn’t make it correct. This post is about a building block he didn’t mention, and why some environments are naturally better suited for AI agent loops than others.

Loop Engineering in 30 Seconds

Osmani’s architecture has five key components plus a memory layer:

1. Automations: Scheduled triggers, no manual kickoff needed
2. Worktrees: Isolated parallel workspaces, multiple agents don’t interfere with each other
3. Skills: Project conventions written as docs, agent reads through them before acting
4. Plugins/Connectors: Let agents access more data through real-world tools (Slack, DB, CI)
5. Sub-agents: Separate the doer from the checker to avoid bias or blind spots
6. External Memory: Progress files so the system can pick up where it left off tomorrow

The core idea is: upgrade from “manual conversation” to “system design.” But for quality assurance, all he gives us is sub-agent review.

But here’s where the problem comes in: what if both AIs share the same blind spot?

The Missing Sixth Block: Deterministic Verification

Sub-agent cross-review has a clear ceiling: it’s still one model evaluating another model’s output. If the output looks plausible and the logic holds up, the reviewer agent waves it through. But “looks plausible” and “actually correct” aren’t the same thing.

Deterministic verification is different. It doesn’t estimate, doesn’t evaluate, doesn’t use confidence scores. It gives you binary pass/fail, right is right, wrong is wrong, no gray area.

Unit tests are half-deterministic, they’re binary when they exist, but coverage is a human decision. Cases you didn’t write won’t be caught.

But compilation failure, SELinux denial, boot loop, these aren’t tests you wrote. They’re physical constraints of the system itself. You can’t avoid these constraints.

Why AOSP / Embedded Naturally Has the Advantage

In web Loop Engineering, the hardest verification is usually CI test pass. But tests are human-written, and coverage always has gaps. An AI agent can absolutely produce code that “runs, passes tests, but is logically wrong.”

The AOSP environment is different. Verification isn’t just your tests, it’s hard gates the system enforces at every level:

• Compilation fails = the type system rejects you. API doesn’t exist? Can’t even generate a binary.
• SELinux deny = the kernel rejects you. Permission not granted? Process blocked outright, not a warning, a denial.
• Boot loop = PermissionManagerService rejects you. State inconsistent? System refuses to start.
• CTS fail = Google’s compliance framework rejects you. Behavior out of spec? You don’t ship.

These verification layers weren’t designed to manage AI. They exist to protect system integrity. AI agents just happen to land in an environment where the defenses are already deployed.

A web app’s definition of “working” is fuzzy, page renders, no 500s, users aren’t complaining, probably fine. An Android device’s definition of “working” is precise: boots up, passes verification, all services alive under SELinux enforcing mode. Binary standard. There’s no “probably works.”

What the Loop Actually Looks Like

Mapping Osmani’s building blocks to our existing AOSP workflow:

A concrete loop in action:

Jira ticket arrives
→ Agent reads source tree (MCP grounding, not guessing from memory)
→ Agent generates CL
→ Sub-agent review (fresh context, no author bias)
→ Jenkins build (compilation gate)
→ Device boot (PermissionManager gate)
→ CTS subset (compliance gate)
→ Human +2 (final checkpoint)
→ Merge

Seven steps, three of which are deterministic gates. The agent wants to bypass them? Not possible. The compiler doesn’t accept “looks plausible” as an argument.

What About Web?

This isn’t to say web can’t do Loop Engineering, of course it can. But if you want to move toward deterministic verification, you’ll need to add some things yourself:

• TypeScript strict mode = approximation of a compilation layer (type errors block execution)
• Contract testing / schema validation = approximation of boot-time checks (API contract mismatch = fail)
• Property-based testing = closer to deterministic than unit tests (auto-generates edge cases)

But honestly, these are all approximations. The web runtime is too forgiving, undefined is not a function won’t make your server refuse to start, it’ll just blow up for one user on one request. Embedded runtimes aren’t that polite: wrong means the entire device doesn’t move.

No Hard Gate Is Omnipotent

Deterministic verification has blind spots too. Correct logic but terrible UX, performance regressions, race conditions, none of these will fail compilation or trip CTS. You still need human judgment.

But the bottom line is clear: at minimum, “will the system blow up?” is a question that AI agents can’t break in an AOSP loop. They can make mistakes, but those mistakes can’t escape into production. Achieving this bottom line in web environments takes some effort.

Loop Engineering is the architecture, hallucination defenses provide the theoretical foundation, AOSP MCP is the implementation. Stack all three and the conclusion is: not every codebase is equally suited for AI agent loops. Environments with deterministic verification are naturally a safer playground.

References

• Addy Osmani, Loop Engineering, 2026
• Why AI Confidently Makes Things Up: From Root Causes to Practical Engineering Strategies, companion piece
• S-LoRA / vLLM multi-LoRA serving infrastructure
• Android CTS (Compatibility Test Suite) documentation