# Agents in Orbit: Workflows, Not Autopilot

Eduardo Simon & Javier Casal, Flywire | AI Engineer NYC 2026 | 18:53

Source: https://www.youtube.com/watch?v=rAUyRDOFyHU
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/agents-in-orbit-workflows-not-autopilot
Published: 2026-10-12
Tags: agents, evals, security, workflows

## TL;DR
- Orbit keeps predictable workflow logic in code and calls a model only when a task needs judgment.
- Flywire restricts each model step by network access, tools, skills, MCP servers, output schemas, timeouts, and concurrency controls.
- The adoption path starts with a useful skill, then turns a proven recurring task into a reviewed background workflow with human approval.

## Summary
Eduardo Simon and Javier Casal explain how Flywire built Orbit, an internal platform for putting model calls inside deterministic engineering workflows. A YAML definition lives in a repository and receives the same merge request review as other code. The workflow handles triggers, data fetching, classification, repository operations, and posting results. A model is used for reasoning, with permissions limited to what that step needs. Flywire runs Orbit on its existing Victoria platform and AWS infrastructure because payment, personal, and health data require strict boundaries. The platform supports code review, translation updates, dependency fixes, ticket triage, production investigations, and bulk repository changes. The speakers describe separate orchestration, runtime, and session components, along with timeouts, rate limits, locks, structured outputs, and isolated evaluation of model steps. They report substantial usage, while acknowledging that execution success does not prove answer quality. Human review of merge requests remains part of the operating model.

## Key ideas
### Flywire treats AI infrastructure as part of its payment compliance boundary
[00:00](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=0s)
Flywire processes payments for education, healthcare, travel, and business services, with customers in more than 240 countries. Eduardo Simon says compliance, privacy, and security are core requirements because the company handles payment details and personal data. Its roughly 400 engineers work across Java, Ruby, Go, Python, .NET, and PHP. Most systems run on Victoria, Flywire's internal platform built on GitLab and AWS, which gives Orbit an existing deployment and governance path.

### Orbit puts model judgment inside code-reviewed workflows
[02:58](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=178s)
Orbit was created after engineers had already built skills, MCP servers, and an early code review bot. Its central design is to keep repetitive procedural work in deterministic code and call a model only when reasoning is needed. A workflow is defined in a YAML file stored in a repository, so engineers and coding agents can read, write, and review it through the normal merge request process. Flywire chose to build Orbit because execution could stay inside Victoria instead of sending sensitive context through a vendor review process.

### The code review workflow gives the model read access without write access
[04:17](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=257s)
Flywire's example starts when a GitLab webhook fires after an engineer mentions the review bot on a merge request. Deterministic steps fetch metadata, classify the risk tier, load previous findings, and clone the repository. The model then reads the code and returns a strict output schema, but it cannot modify files. Another deterministic step posts the findings back to the merge request. Human review and approval remain part of the process.

### Orbit supports event-driven, scheduled, and directly requested automation
[05:46](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=346s)
Workflows can start through Orbit's internal API or CLI, through webhooks from GitLab, Jira, Sentry, and AWS, or through scheduled jobs. Flywire uses these paths for code reviews, translation synchronization, feature flag cleanup, knowledge-base refreshes, production error investigation, ticket routing, and repository readiness checks. Orbit also handles bulk changes across repositories, including migrations, library updates, and deprecations. The team is building an MCP server so other tools can start workflows from places such as Slack.

### Separate orchestration, runtime, and session state make scaling easier to control
[08:29](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=509s)
Orbit began with orchestration and the agent runtime in one AWS ECS Fargate container. The architecture later separated orchestration, the runtime environment, and session state. This lets the components scale and allocate resources independently, while an error in one part does not kill the sandbox. Fargate provides elastic task scaling through Flywire's Victoria platform. Timeouts stop long-running agents, rate limits contain broken integrations, and locks prevent duplicate executions such as two runs for the same code review.

### Each model step receives only the access declared in its workflow
[11:04](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=664s)
Orbit uses the Claude Code agents SDK rather than building another agent harness. Flywire adds restrictions around the network an agent can reach, the tools it can call, the skills it can load, and the MCP servers it can use, including specific tools within a server. A code review step can read and search code but cannot edit or push changes. Shared skills come from a central repository published as an internal Claude Code plug-in marketplace, so engineers can use the same skill locally and in Orbit.

### Structured outputs let ordinary control flow handle model results
[13:10](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=790s)
Every LLM step returns data against a strict JSON schema. Later branches, error handling, and state transitions can then use validated fields instead of parsing free-form text. When a response fails validation, Orbit triggers a targeted retry or fallback pass. Flywire evaluates individual LLM steps by injecting historical state and context into a workflow node. New agents still usually enter production after checks on a few real cases, and golden datasets are versioned beside the code and run on demand.

### Usage is high, while answer-quality evaluation is still unfinished
[15:40](https://www.youtube.com/watch?v=rAUyRDOFyHU&t=940s)
Flywire reports more than 9,700 automated code review runs in the previous 30 days, with an average below three minutes per merge request. Other workflows opened dependency-fix merge requests, improved repository readiness, fixed Victoria linter issues, and resolved merge conflicts. Across these workflows, the team reports more than 11,000 executions with a 99% execution success rate. The speakers do not present that rate as proof that the answers are correct. Online evaluations are still being built, and complete sandboxing remains a goal.

## Notable quotes
- Eduardo Simon: "Instead of letting AI agents run freely in open-ended loops, Orbit pairs deterministic code with small LLM steps." (03:06)
- Eduardo Simon: "The model can read the code but has no permission to modify it and must answer in a strict output schema." (04:44)
- Eduardo Simon: "Everything predictable stays as code and that is what keeps the workflows reliable." (18:20)
- Eduardo Simon: "Start with the skill. Skill is cheap to write, easy to iterate on, and useful from day one." (12:30)

## Tools & references mentioned
- Flywire
- Orbit
- Victoria
- GitLab
- AWS
- AWS ECS Fargate
- Claude Code
- Claude Code agents SDK
- GitLab webhooks
- Jira
- Sentry
- MCP
- OpenTelemetry
- Slack
- Lambda microVMs

## Who should watch
- You are building internal agents for a regulated company and need model access to stay within existing infrastructure and review controls.
- Your team has useful AI skills or scripts but needs to turn a recurring task into a background workflow with ownership and human approval.
- You want practical design choices for permissions, retries, concurrency, evaluation, and model cost before running agents at larger scale.

## Editor's note

Eduardo Simon says Flywire's 99% execution success rate does not prove that Orbit's answers are correct, and online evaluations are still being built. Kitaru records each model call and tool result from a real run, then lets a reviewer turn what they found into cohorts of runs. Evaluators are checked against those human verdicts before they gate anything.

Written by the AIE Talks editors (the Kitaru team), not by the speaker.

## Related talks

- [Agents vs Workflows: Why Not Both?](https://aietalks.com/talks/agents-vs-workflows-why-not-both) (Sam Bhagwat, Mastra, 15:37)
- [From Copilot to Colleague: Trustworthy Agents for High-Stakes](https://aietalks.com/talks/from-copilot-to-colleague-trustworthy-agents-for-high-stakes) (Joel Hron, Thomson Reuters, 19:45)
- [Human-in-the-Loop Automation with n8n](https://aietalks.com/talks/human-in-the-loop-automation-with-n8n) (Liam McGarrigle, n8n, 1:19:22)
- [Redesigning How Software Gets Built With AI Agents](https://aietalks.com/talks/redesigning-how-software-gets-built-with-ai-agents) (Tariq Shaukat & Ali-Reza Adl-Tabatabai, Sonar, 19:12)
- [IT Admin for the AI Workforce](https://aietalks.com/talks/it-admin-for-the-ai-workforce) (Sarthak Aggarwal, Decawork, 16:17)
