From Prototype to Enterprise Production: Extending Andrew Ng's Three Loops

In a late-June 2026 letter, Andrew Ng described building a typing-practice app for his daughter over a weekend — the coding agent working on its own for about an hour, even opening a browser repeatedly to check its own work — as the concrete example of his three nested loops for 0-to-1 AI product building: the agentic coding loop (minutes), the developer feedback loop (hours), and the external feedback loop (days to weeks). We wrote about the loops themselves elsewhere — their clocks, failure modes, and the telemetry each needs — in our companion on operating loops at scale. This post is about a different edge of Ng's framing, the one enterprise readers reportedly raised, per an explainx.ai chronicle of the letter: what happens to the outer loop when the product is not a weekend app but an enterprise system. Ng's letter is candid that the external loop is "friends, alpha testers, production with A/B tests." An explainx.ai chronicle reports that enterprise readers argued that, in regulated environments, the external loop should also encompass policy, governance, audit, and accountability, not only consumer experiments. That observation is the seam this post lives in. The three-loop method captures a useful distinction, and it does not stop working at the enterprise door — but the outer loop acquires requirements there that a weekend build never faces, and meeting them is the difference between a prototype that demos and a product that ships inside a company. The back half maps those requirements to documented mechanisms; the candid boundary, as always, is that infrastructure supports the method rather than replacing the judgment at its center.

1. The Framework Holds; the Outer Loop Changes at the Door

Start by giving Ng's framing its due, because this post depends on it being correct. The three loops describe something real: the inner agentic loop now writes and verifies code fast enough that the human's job moves up the stack to product decisions (the middle loop), and the whole thing is only as good as the external signal that validates the vision (the outer loop). Ng's weekend app is the perfect illustration precisely because it is small — the outer loop is his daughter using the app and him changing his mind about cat costumes and the parent login flow. Nothing about that is trivial to build, but the outer loop's obligations are light: no one audits the typing app, no compliance owner signs off on it, no auditor asks who approved a change. Now move the identical method into a company. The inner loop is unchanged — the agent still writes and tests code every few minutes. The middle loop is unchanged in shape — a human still steers on an hours cadence. But the outer loop transforms: "ship to users" now means shipping to customers, under policy, with accountability, and the external feedback that matters includes not just "do people like it" but "does it satisfy the constraints the business is answerable for." This is not a criticism of Ng's framing; it is the enterprise instance of it that enterprise readers, per the explainx.ai chronicle, flagged, and it is where a build stops being a build and starts being a product.

2. Graduation Is an Outer-Loop Problem

The reassuring part, for any team that has fallen for the three-loop method on a prototype, is that graduating to production does not ask you to change how you build — though governance is a major part of the transition, not the whole of it: teams still need conventional production engineering (deployment, reliability, capacity, rollback, incident response, security, application-level testing), with the control plane addressing the governance and model/tool-traffic layer of that larger system. The inner loop — spec, agentic iteration, verification gates, capped spend per run — is the same discipline whether the output is a typing app or a claims processor. What changes is everything around the loop, and it changes because the outer loop's new obligations reach inward. An agent that ran under your own credentials on your laptop now needs an identity of its own, because "who did this" must have an answer that isn't "the developer's key." An agent whose weekend spend was your personal subscription now needs a budget with an owner, because someone is accountable for the line item. An agent that saw only your test data now handles real user data, which means what enters and leaves it must be inspected. And an agent whose every action was visible in your terminal now runs somewhere others must be able to review, which means a durable record. None of these is a build-loop concern; all of them are outer-loop concerns in the enterprise sense — the policy-governance-audit dimension of the reported enterprise-governance observation — and many can be enforced through surrounding infrastructure, while the agent and application still own task design, data minimization, tool semantics, and business logic. That is a large part of why graduation is tractable. Once an application's model and registered MCP traffic is integrated through the relevant gateways, teams can centralize many traffic-level controls rather than reimplementing them independently in every agent. Integration still requires credentials, endpoints, policy attachment, agent registration, metadata, and tool routing.

3. The Three Loops, Graduated: Where TrueFoundry Fits Each

Take Ng's loops one at a time and add the enterprise requirement each acquires, mapped to documented mechanism. The inner loop stays put — deliberately. The agentic coding loop with its verification gates and per-run spend caps is the part you keep exactly; if it runs in a managed runtime, the Agent Harness supplies orchestration, state, tool execution, and step-level observability, now visible to more than one person; the application still defines the specification, tests, verification criteria, and conditions for stopping. The middle loop becomes evaluation and staged rollout. Ng already recommends evals when the same failure repeats; in production that instinct becomes infrastructure — gateway telemetry feeding a connected online or offline evaluation system (the evaluation pattern) — with the scorer, sampling policy, calibration, regression detection, and promotion logic remaining an adjacent workflow the team implements or integrates — and virtual-model weights directing a controlled share of traffic to a candidate target, widened or restored by deliberate configuration without changing the model name callers use, the mechanics our routing analysis details. The developer's steering feedback, in other words, gets a safety rail: change the spec, ship to 5% of traffic, watch the evals, widen or revert. The outer loop acquires its governance dimension. This is where that reported governance observation becomes configuration: model-account access control governs which users, teams, and applications may call approved models, while for agent-level attribution on MCP Gateway and Agent Gateway traffic each independently governed agent presents a registered Agent Identity, with its Agent Registration and associated policies defining who may call it, whom it may act for, and which downstream resources it may reach; budgets assign spend to an owner and, when enforcement is enabled, impose a hard limit — warn-only mode provides notifications without blocking traffic; configured gateway policies can inspect model requests and responses, as well as registered MCP tool calls that traverse the relevant gateways — each MCP tool invocation is evaluated separately; this does not cover arbitrary application-side tools, and output guardrails require a completed non-streaming response — protecting the real user data the prototype never saw (guardrails docs); and the Metrics Dashboard provides aggregate visibility into spend, volume, errors, latency, routing, and guardrail outcomes, while Request Traces and Request Logs provide the request-level evidence "accountability" concretely means — logging configuration separately determines whether request and response bodies are retained and redacted; cost, token, latency, and request metadata remain recorded. Ng's context-advantage point remains a development-loop responsibility: teams encode user needs, domain constraints, compliance requirements, and product intent through specifications, prompts, datasets, evaluations, and review. Separately, Agent Harness can pause sensitive tool calls until an explicit approval decision arrives — an execution checkpoint, not a substitute for authorization or upstream context engineering. For sensitive actions that require explicit review, an approval policy creates a human checkpoint before the tool executes at the consequential step, the pattern our task-based access analysis develops. The method is unchanged; the outer loop simply grew teeth, and the teeth are documented.

‍