Duolingo AI Agent Platform

How to run LLM agents as infrastructure rather than as demos — the orchestration, the guardrails, the evaluation, and the unglamorous work of getting the capability adopted.

Distilled from Duolingo's engineering blog, where a company running hundreds of microservices put agents into CI, into migrations, into QA and into chat. The reader here is assumed to be building something else entirely; every node ends in questions about your product.

This skill does not own trained models that make product decisions. Ranking, evaluation metric design and generation pipelines belong to the ML-in-production skill; this one owns orchestration, tooling and adoption.

Architecture — what an agent is, and how it runs

• [[references/separate-what-an-agent-is-from-how-it-runs]] — definition in a registry, execution in one shared platform, so a new agent takes minutes and a vendor swap is a parameter.
• [[references/model-an-agent-run-as-a-durable-workflow]] — every step one retryable unit with its own timeout, so a flaky call costs a step and not an eleven-minute run.
• [[references/standardize-the-integration-surface]] — the cost is variance in how integrations are built and run, not how many there are.

Guardrails — what the agent may touch, and when to stop

• [[references/constrain-the-blast-radius-at-the-platform-layer]] — enforce write scope and one auditable identity in the platform, because a prompt expresses intent, not permission.
• [[references/every-producer-needs-a-janitor]] — a retry cap, a staleness deadline and a cooldown, or the system re-attempts its own failures forever.