Skip to main content
bash TV

Agents in Orbit: Workflows, Not Autopilot — Eduardo Simon & Javier Casal, Flywire

AI Engineer

148 views12 Oct 2026

YouTube

More than 9,700 code review runs in 30 days came from a workflow that lets the model read code but never modify it. Eduardo Simon and Javier Casal describe Orbit, Flywire's internal platform for putting model steps inside deterministic engineering workflows. A YAML definition goes through the same merge request review as other code, declares the tools and access each step can use, and runs on the company's existing deployment infrastructure. The predictable work stays in code; a model supplies the judgment. Human review of merge requests remains part of the process as the platform expands across roughly 400 engineers. Code review, translation updates, dependency fixes, ticket triage and bulk repository changes show the range of tasks this pattern supports. The architecture separates orchestration, execution and session state, then adds timeouts, rate limits and locks against duplicate runs. Per step restrictions cover network access, tools, skills and MCP servers, while structured outputs drive subsequent branches. The speakers are candid about the remaining work: new workflows initially receive a few real case checks, golden datasets run on demand, online evaluations are still being built and full sandboxing is a goal. Their reported execution success rate does not establish answer correctness. The practical adoption path starts with a useful skill, proves the recurring task and then turns it into a background workflow with explicit ownership and review. Speaker info: Eduardo Simon: - https://github.com/EduardoSimon - https://www.linkedin.com/in/eduardo-simon/ Javier Casal: - https://github.com/jacarui - https://www.linkedin.com/in/jacarui/ Timestamps: 00:00 - Flywire's platform team and payment context 1:58 - From organic experiments to Orbit 3:35 - Build versus buy on existing infrastructure 4:17 - A YAML workflow and restricted code review 5:46 - Triggers and engineering use cases 8:29 - Separating runtime and orchestration 9:21 - Limits, locks and execution environments 11:04 - Per step access and shared skills 13:10 - Structured outputs and evaluation gaps 15:40 - Reported runs, adoption and the roadmap

Join the discussion

Sign in to join the discussion

Sign in