Orkes Shift ‘26: How LinkedIn, Bumble and Twilio Run Workflows and AI Agents in Production

Engineers from LinkedIn, Bumble, Twilio and Orkes on running AI agents reliably inside real business processes.

---

Orkes Shift ‘26, our first-ever conference, filled Convene in Union Square from morning breakfast through happy hour. Engineers, architects and platform leads joined us. Many had run Conductor in production for years, and some were meeting the people behind it for the first time.

It felt like the right moment. Conductor started at Netflix in 2016 to orchestrate microservices at a scale few companies ever see. Ten years later, it runs over a billion workflow executions a day. Now we’re on the cusp of a new need: orchestrating AI agents and running them reliably in production, right alongside the workflows teams already trust.

If you couldn’t make it to San Francisco, here’s what you missed. And if you were in the room, here’s your chance to revisit the ideas worth taking back to your team.

We kicked off with Conductor’s story, from Netflix to the AI era

Jeu George, our CEO, opened the day by taking us back to where it all began: Netflix.

Netflix was already a giant back then, streaming in around 100 countries and 50 to 60 languages, with the work behind every title spread across many teams. When it started making interactive titles, first a run of kids’ originals and later Black Mirror: Bandersnatch, where viewers choose how the story unfolds, those projects needed a lot of testing. But a change could take hours to reach the live site, and the team needed to move faster. Conductor was being built for exactly this kind of orchestration problem, so they put it to work, and development sped up. Within weeks, nearly every team at Netflix had adopted it.

Jeu remembered walking the hallways and seeing developers with two monitors: “One was the IDE, the other was Conductor. That’s when we knew we had something.”

Netflix open-sourced Conductor soon after. Within the first three or four months, contributions were coming in from companies like GitHub, Tesla, JP Morgan and Swiggy, and the list kept growing. Today, Conductor sits behind processes most of us touch every day without knowing it. A few of the examples Jeu shared:

• About 8.5% of US home loan origination fees flow through processes running on Conductor, from document processing to mortgage applications.
• 70% of global chip foundry processes, covering fabrication, testing and logistics.
• 46% of EVs sold in the US, including vehicle management, payments, CI/CD pipelines and customer service portals.
• 45% of airline passenger boardings, from booking platforms to the data processing behind them.
• 37% of mobile subscriptions in India, including customer orders and device activation.
• 25 to 30% of UK retail mobile and broadband connections.
• 9 to 10% of US TV viewing time, from content acquisition and media encoding to streaming and ads.
• About a third of global sales of Ethernet switches and enterprise Wi-Fi equipment.
• 40% of online food deliveries in India, from orders to invoices. As Jeu joked, if Conductor goes down, India goes hungry.
• $11 billion in daily currency trades, including trade execution, compliance and risk management.

Conductor is now also the foundation teams build their AI platforms on, and Jeu explained why the fit is natural. AI agents and agentic workflows are long-running processes too, so durable state, retries and observability carry straight over. But agents also need things regular applications never did, like:

• Guardrails. We’ve all seen the stories about agents going rogue. Limits on what an agent can do have to live in the platform, not in the agent’s good intentions.
• Zero-trust credentials. You can’t ask an agent to do something and simply trust that it will. The platform has to manage its credentials and check its work.
• Explainability. Every run of an agent can be different, so you need to be able to explain, every single time, what it did and why.
• Replay. A regular workflow can be replayed step by step. Ask an agent to redo a task and it might take a completely different path, so replay has to work differently.

These ideas came up again and again throughout the day, especially in the fireside chat with Geo Varkey (which is toward the end of this article).

We rallied around one big idea: agents need production-grade orchestration

The hardest part about working with agents right now is getting AI agents and the business processes around them to behave as one reliable system. Agents are non-deterministic by design, but the processes they plug into can’t be.

Every talk at Shift landed on the same idea: run agents and the processes around them on one durable execution layer. That layer records every step as it runs, so work survives crashes, retries and long waits for a person. Agents then inherit the retries, state, observability and human approvals that workflows already have. Here’s how each session made the case.

1. Bumble: one written-down process. Rebuilding trust and safety as a single workflow turned seven handoffs into one definition and gave every report one execution record. That record is what let Bumble hand steps to AI one at a time, with a person still on the record.
2. Twilio Segment: a workflow engine they no longer have to maintain.. Conductor tracks when an agent’s work starts, pauses and finishes, so one mechanism covers crash recovery, human approvals and handoffs between agents.
3. LinkedIn: a team of coding agents with a person in charge. Conductor passes work between product, architect, developer, QA and code review agents, with a limit on review rounds and a person approving the plan and the final changes.
4. Orkes: retries and saved progress, built in. If each step works 99% of the time, a 100-step agent task finishes only about a third of the time. Saving each step as it finishes means a crash resumes the task instead of paying a customer twice.

We announced upcoming product releases

Shift was also where we shared what’s next for Orkes. We announced three things, each aimed at making it easier to run agents and workflows in production:

• Worker and tool hosting. Orkes will soon host the workers and tools your agents and workflows call, so there’s less infrastructure for your team to run.
• Multi-region and multi-cloud deployments. Run Conductor across regions and cloud providers, for teams that need resilience, lower latency, or data kept in a specific region.
• Particle DB, The world’s first agentic database. Agents are only as good as the data they can reach, and today that data is scattered across relational databases, key-value stores like Redis and vector databases, kept in sync by ETL pipelines. Particle DB handles all of it in one engine. It also lets you load your own code, in Python, Rust or other languages, into the database itself, so agents and workflows run directly on your data.

Want to try them before anyone else? Request early access.

We heard how real teams run workflows and agents in production

Speakers from Bumble, Twilio, LinkedIn and Orkes shared what’s working for them, what broke along the way, and what they’d do differently.

🐝 Bumble: why choreography gave way to orchestration

Paul Vander Griend, Distinguished Engineer at Bumble, followed a single user report through Bumble’s trust and safety system, the part of the app that handles reports of bad behavior.

In the old setup, each part of the system reacted to the one before it, but nobody owned the process as a whole. One report passed through seven handoffs, including human moderators and an outside review vendor. Its status lived in three different places, and they didn’t always agree. If a report got stuck, nobody noticed until a timer went off three days later. Even small changes were expensive: adding one new status meant touching 13 places in the code across three teams.

So Bumble rebuilt the same process as a single workflow. Same steps, same people, but now written down in one place. Seven handoffs became one definition, and three status records became one, so “where is this report?” became a simple lookup. When a step fails, it retries on its own. If it still fails, the workflow pauses with its data intact until the bug is fixed. Every decision is recorded, giving regulators and appeals a clear trail.

That groundwork is what made AI possible. Paul shared three principles for automating any business process:

1. Understand the process, not just the code. Ask the people who run it what it’s for.
2. Reimagine it. Don’t rebuild something just because that’s how the old system worked.
3. Measure first, then add AI. Run the process with people making the decisions, so you have a baseline to compare against.

From there, Bumble hands steps to AI one at a time: first gathering background on a case, then labeling reports, then making the decisions it’s confident about. Each AI step runs quietly alongside a person first, and only takes over if its quality holds up. Adding a new step, like a second review, now takes days instead of quarters. And Bumble is seeing the same pattern in payments, GDPR requests and internal automation.

Paul closed with three things to take home.

• First, when every part of a system just reacts to the last, the process is hidden; writing it down as a workflow is what lets you change it on purpose.
• Second, durability makes change safe: a failed run waits for the fix instead of disappearing, and that’s what lets a team move fast.
• Third, AI fits into a written-down process as just another step. You add it, let it act only when it’s confident, and keep a person on the record.

💬 Twilio Segment: from maintaining a workflow engine to building on one

Joe Yan, a Staff Software Engineer and Tech Lead at Twilio Segment, shared how his team moved off a workflow engine they had built themselves, and what that freed them to do.

Twilio Segment helps businesses collect customer data, combine it into one profile per customer, and use it to reach the right people, like a pizza chain winning back customers who stopped ordering. Behind the scenes, Orkes coordinates the work of moving billions of rows between Segment’s live data pipeline and its data lake of roughly 10 petabytes.

It wasn’t always that way. Segment’s original workflow engine was built on a MySQL database, with one table per job type and two columns for every step. Adding a step meant changing the database. A step that was running, failed or stuck all looked the same, and finding a stuck job meant writing SQL by hand. Debugging a single failure could take hours. And there was no path to the team’s goal of running 30,000 workflows at once.

After comparing Orkes with three other workflow tools, the team chose Orkes Conductor. A few reasons stood out: steps that must not run twice don’t, new versions of a workflow can run side by side with old ones, it’s fully managed so no team has to run it, and customer data stays inside Segment’s own systems.

The payoff showed in 2025, when Segment moved customer computations from batch, where everything is recalculated on a schedule, to real time, where results update as new data arrives. Real time is far cheaper for the same result. Because the team could reuse existing workflows and roll back at any point, the project took about eight weeks from design to production. They migrated more than 10,000 computations and now save seven figures a year.

Today Segment runs about 54,000 workflows at once, peaking at 64,000, well past the original 30,000 goal. The number of engineers contributing to orchestration code grew from 23 to 78, and debugging a failure went from hours of SQL to minutes in the UI.

The takeaway, in Joe’s words: “We stopped maintaining a workflow engine and started building on one.”

🤝 LinkedIn: Scaling automation with an agent platform

Obi Azogu of LinkedIn showed how his team grew LinkedIn’s workflow automation into a platform for AI agents, without building a new system from scratch.

It started with a familiar problem. LinkedIn’s internal business teams, like sales and operations, work with rules that keep changing across regions, roles and policies, and on tight fiscal-year deadlines. The team’s answer was to break the work into small, single-purpose actions, like assigning a user to a seat or updating account ownership, then combine those actions into workflows. Obi compared it to Legoland, where huge model cities, stadiums and railways are all built from the same basic bricks. In one example, a temporary coverage process for when someone goes on leave reused the exact same actions as employee onboarding, just in a different order.

Then LLMs made it possible for non-technical people to build automations for their own day-to-day work, and LinkedIn wanted to let them add AI to the workflows that already existed. So the team treated automation as a spectrum: fixed workflows on one end, fully reasoning agents on the other, and hybrids in between, where a workflow includes an AI step.

The key design choice is that Conductor doesn’t track every thought an agent has. It only tracks when a piece of the agent’s work starts, stays alive, and finishes or pauses. Each pause saves the agent’s progress, so if a server crashes, the agent picks up where it left off on another one.

That same pause turned out to solve two more problems. When an agent needs a person’s approval, like before sending an email outside the company, it pauses, frees up its server, and waits at no cost until the person responds. Then it carries on with everything it knew. And when one agent hands a task to a specialist agent, it pauses the same way and resumes when the result comes back. No new machinery was needed for either. LinkedIn is still working through the policies around approvals, like which actions should need one, but the mechanism comes for free.

The takeaway: complex agent behavior doesn’t need a complex new system. Like the Lego cities, it can be built by combining simple, durable pieces.

🤝 LinkedIn: Stop babysitting your AI coding agents

Yangchen Situ and Calvin Lei of LinkedIn opened with a scene every engineer who codes with AI will recognize. You ask an agent for a simple change, and it adds three new layers. You remind it, again, to follow the repo’s conventions. It fixes one thing and breaks another. Yangchen called this babysitting: repeating decisions you’ve already made, instead of making new ones. Asking the AI to “remember this for next time” only goes so far, because those notes aren’t always loaded, or followed.

For the past six months, Yangchen’s team has worked differently. Every project moves through four stages, each with its own command: explore the idea, propose a plan, apply it, and archive what was learned. The plan comes as two files, one written for people to review and one with the detailed rules an AI needs to build it. A third file tracks progress as the work happens. Because the context lives in files rather than in one long chat, a new session can pick up exactly where the last one stopped. And because the team reviews the plan before any code is written, big design problems get caught early instead of buried in dozens of pull requests later.

Conductor ties it all together. Instead of a person chasing each agent, Conductor hands the work from one agent to the next. A product agent drafts the plan, and an architect agent reviews it against a checklist: Is it clear? Does it cover the requirements without inventing new ones? Is it over-engineered? They go back and forth up to three times before a person approves. Then a manager agent splits the plan into tasks for developer agents, a QA agent checks their work for up to ten rounds, and a code review agent adds its notes before everything reaches a person. As Yangchen put it, the human is now the CTO of the agent team.

In one month, the team shipped 40 features. Yangchen stressed that this is the number that matters, not the 66,833 lines changed or the 111 pull requests, since AI makes lines and pull requests cheap. The setup is flexible, too. Teams can change the number of review rounds, add their own agents, or build their own dashboard on the same data. One manager turned his into a game where every feature is a boss to defeat.

Calvin then took on the last kind of babysitting: teaching every teammate, and every teammate’s agent, the same lessons over and over. His team keeps a shared knowledge graph of linked articles about systems, recurring gotchas and past decisions. Each project starts by reading from the graph and ends by proposing what it learned. A person reviews every update before it joins the graph, because, in Calvin’s words, the graph is “self-improving, not self-authorizing.” The graph has grown 78% since late June. His advice for getting started: don’t document everything; start with the thing your team explained twice this week.

The takeaway, in Calvin’s closing line: “Every project should leave the graph smarter than it found it.”

💜 Orkes: The realities of running agents in production

Nick Lotz of Orkes made a simple point: building an AI agent is easy now. Running one in production is the hard part.

He showed this with one example: an agent that handles refund requests. It looks up the order, checks the refund policy, and suggests what to do. A few lines of code get it working on a laptop. In production, though, you also need a way to retry failed steps, save progress, get a person’s approval, keep API keys safe, and see what happened when something goes wrong. Most teams end up building each of those pieces themselves.

Small failures add up fast. If each step works 99% of the time, a 100-step task finishes only about a third of the time. Retrying failed steps fixes most of that. But starting over after a crash creates new problems: the agent might suggest a different refund, ask the approver again, or pay the customer twice. The fix is to save each step as it finishes, so a crashed task picks up where it left off.

Orkes does that for you. Nick showed it live: he crashed part of the system in the middle of a task, and instead of failing, the task waited and then carried on once things were running again. The agent also fits into a bigger process. It suggests a refund, a person approves it, and the refund is issued automatically. Other AI tools, like Claude Code, can start that whole process too.

The takeaway: you don’t have to build all those extra pieces yourself. Retries, saved progress, approvals and safety checks are built into Orkes. To try it, head to www.developer.orkescloud.com.

🔥 Fireside chat with Jeu and Geo Varkey: Where does engineering work go in the age of agentic AI?

If you’re short on time and can only watch one session, make it this one. Pure gold!

Jeu George, our CEO, sat down with Geo Varkey, who leads data engineering teams at Google. Geo started his career on Wall Street, building large-scale trading systems and the infrastructure under them at Lehman Brothers, Barclays and Fidelity. He then spent years at AWS, where he ran the Neptune graph database team and the Redshift analytics team.

Jeu asked him about agentic coding, where engineering work is heading, and what it takes to run agents somewhere as unforgiving as Wall Street. I’m paraphrasing a lot of what was said, with my own thoughts sprinkled in on the parts I got most excited about. 🙌

Jeu: How have coding agents changed over the last 12 to 18 months, and how are people using them?

Geo: A tremendous amount has changed. Context windows got larger, models got smarter, more reasoning moved into inference, and agents now have memory. Take a product I managed: a codebase of 2 million lines with half a million tests running every night. On any given day, half a percent to 1% of those tests fail, for any number of reasons. Tracking down why could take engineers days or even weeks. Now agents collect the log files, reason through the codebase and work out what went wrong. If it’s just an infrastructure hiccup, the agent reruns the test itself. This ability to reason across a large codebase is the biggest shift I see happening in my field.

The part that got me was how long those failures used to take to track down. Personally, I was very happy to hear agents can help with that, because large codebases were my nemesis when I started my first job as a software engineer.

Jeu: Coding went from asking ChatGPT for a snippet, to Copilot and Cursor in the editor, to terminal agents like Claude Code and Codex. Coding has almost become a commodity. So where does the engineering work go?

Geo: Into everything around the code. Planning still belongs to people: when stakeholders disagree about what to build, an agent can’t settle that for you. Verification does too, especially when data moves between two companies and both sides have to agree on what “correct” means. Someone also has to be sure that what you deploy actually works. You can’t have an agent on an outage. And after launch, people still decide what the system taught you and what to build on top of it next.

What has changed is essentially the speed of development the most it seems. In the fireside Geo mentions that if 10 projects used to take 100 people, they might now take 10. He was clear that this doesn’t mean the jobs go away though. Just that the same people can take on 100 projects instead of 10 now.

There are plenty of takes online that agents aren’t really making anyone more productive. After hearing Geo, I think the potential is clearly there, and many companies are already seeing it. Like any new technology, there’s a learning curve before it pays off. Once we’re past it, we get to solve bigger problems, or solve the ones we have much faster.

Jeu: Agents usually start out running on someone’s laptop, but they only become truly useful once they run on their own, in production. Orkes is used heavily in financial services, through both open source Conductor and the hosted Orkes Conductor, including in trading systems where regulation and compliance are strict. You spent years on Wall Street. What challenges do you see for agentic systems there?

Geo: Wall Street’s controls were learned the hard way. Over the years, things like privilege escalations caused big outages and real financial damage, so regulators tightened the screws and banks built internal controls of their own. When a regulator shows up, you want to answer fast. Sometimes they just want an audit. Sometimes they’re investigating a transaction and won’t tell you why. Either way, they want everything about it, and a single transaction can pass through 10 to 15 systems. Until you deliver, they might halt your trading or lower your risk limits for the day. And the information has to hold up as evidence, with no chance it was tampered with.

The old way to ship something new was slow but predictable (predictability is great for shippig proucts). You would write a doc listing what the system will do, its privileges and its controls, get a committee to approve it, then build it. That process assumed deterministic workflows. Agents, however, aren’t deterministic, and now teams can build agentic applications on their own. As Geo put it, “What is terrifying the leadership is the rate with which these applications are getting created.” Banks aren’t in the business of building platforms, so they need one that lets them run their world with agents and still answer a regulator’s questions quickly.

Jeu: So a lot of the checks people do today are moving to agents. How do you keep those agents in line?

Geo: The same way a firm keeps people in line. A trader’s job is to make as much money as possible with the firm’s capital, so risk managers set controls that block trades taking on too much risk. Sometimes a control stops an action outright. Sometimes it stops the same action from happening too often or going past a limit. In software terms, that’s rate limiting, backoff and dropping requests when you’re over capacity, and agents need all of it.

Rules start at the top and flow down. Some apply to everyone, agents included, like not trading your own company’s stock at certain times. Others are stricter. Banks keep traders and researchers apart, so a trading agent must never read a research report and act on it, even if it’s told to finish a task no matter what. And when an agent passes work to another agent, that agent has to follow the same rules.

Jeu explained how Orkes handles this. In Conductor, guardrails sit on the tools an agent calls, and the platform enforces them every time the agent uses one.

Jeu: When a regulator asks why something happened, a traditional workflow can show its execution history. But if you replay an agent, it might do something completely different the second time. How do you explain what an agent did?

Geo: Take wire transfers. A hedge fund might set standing instructions: a trader can wire out $50,000 on their own, after the system confirms who they are and checks their history and employment status. At $100,000, the request goes up to the CFO, and the trader’s agent has no power to approve it. Anything bigger needs the CEO to sign off. The stakes are high because once the money leaves the platform, it’s gone. Now picture an agent crashing halfway through that chain, and an investigator showing up days later. In the real world, there’s a paper trail. What’s the version of that for agents?

Jeu: In Orkes, every step an agent takes runs as a Conductor workflow under the hood, so every LLM call and tool call is recorded with its inputs and outputs. To replay a run, you swap in the responses the LLM actually gave and rerun everything else. You can also record which model was used and what was in its context window and memory, and attach correlation IDs like a trade ID, customer ID and date, so an investigator can find the exact run they need.

Geo pushed back on this. An LLM may not give the same answer twice, so is that really a replay? Jeu’s answer was that you either skip the LLM calls and use what they actually returned, or get as close to deterministic as you can with the same model and the same context, a bit like seeding a random number generator. In practice, investigators mostly want to know what the agent was given, which model answered, what it said and what actions followed. That’s exactly what the execution history holds.

Jeu: What about using an LLM as a judge? Most models are trained on much the same internet data, so they tend to give the same answers. That’s why at Orkes we let you plug in different providers and open-weight models, since different weights can give a judge a genuinely different point of view. Is that something you’ve seen in the industry?

Geo: Wall Street has done this with people for decades. When the traders go home, an army of reconciliation and post-trade staff comes in to check everything. For example, a trade has to execute within the national best bid and offer, between the best bid and ask prices, and there are many ways a price can drift outside it. When something’s off, it gets reported and corrected. The rule that matters: the thing verifying the work can’t be the same as the thing doing it. At the end of the day everything has to net out to zero, or you have to explain why.

Jeu: Are these processes long-running?

Geo: Many are. Single trades are fast, but they add up against risk limits that something has to watch all day. Say a big client asks the firm to buy 10 million shares of Apple. That can take days, with pieces of the order sent to different venues or handed to other banks to execute, a lot like delegating to sub-agents, all while staying within the firm’s limits. A crash in the middle is catastrophic.

Jeu: With distributed transactions, when something fails partway through, you unwind it with something like the Saga pattern. Is that true for agents too?

Geo: Of course. Say the firm bought a few hundred shares too many. It either unwinds the extra or takes the loss. You need an automatic workflow that does the unwinding. Today, a person makes that call.

And with that, Jeu opened the floor to the audience, and they came ready with some great questions.

Questions from the audience

• Could agents handle the data contracts between companies? For simple, standard exchanges, yes. But when complex data triggers a chain of actions inside another company, Geo still wants a person to verify it, at least for now. A follow-up asked why not let agents do it with other agents reviewing as judges. His answer is a rule worth keeping: “If the process is reversible, then it makes sense. If it is not reversible, then it’s a problem.” A wire that lands in the wrong account on the other side of the world is gone, no matter how many agents agreed to send it.

• How should we think about security? Geo described a conversation with a partner at an investment bank. The bank’s crown jewels are its proprietary knowledge, like its trading algorithms. It wants the power of hosted frontier models but worries about that knowledge leaving the building, so its plan is to run open-weight models in-house and accept that they trail the best models a little. The tension: a four-person hedge fund using a frontier model is racing them at the same time. Jeu added that agents need a zero-trust model, where the platform verifies the agent, and that identity and authorization schemes for agents are still evolving fast.

• How can finance, where two plus two must always equal four, rely on non-deterministic models? Geo described a hierarchy. Routine automation goes to LLMs first. Most bank workflows still have a person pushing a button here and there, and those will follow. Judgment-call approvals come next; leadership is wary today but more comfortable every year. The most sophisticated work is still an open question. He also shared a story from building a trading system: when he offered to automate everything the head trader knew, the trader said no, because then he’d have no job.

And with that, the fireside chat came to a close, and so did a full day of talks about running agents in production. 🙌

What’s next for you and for Orkes Shift

• Session recordings playlist: https://www.youtube.com/playlist?list=PLFYs1itjCO0Y
• Keep the conversation going: join us on Slack and star Conductor OSS on GitHub.

Missed the day? Start building on the same engine the speakers use: try Orkes Developer Edition for free or book a demo to see agents and workflows running side by side.

Lastly, thank you to our speakers for sharing honest stories from production, to our customers and partners, and to everyone who spent the day with us. And a special shoutout to the whole Orkes team for putting it all together.

As our CEO, Jeu George, put it after the event: “We’re entering an era where anyone can build an AI agent.” The real difference, in Jeu’s words, will come from the platforms that make those agents reliable, scalable, explainable and ready for production. That’s exactly what every conversation at Shift came back to.

And this is just the beginning. Orkes Shift is coming to a city near you. Stay tuned for dates.