Orkes Shift '26

For some reason, I have been receiving a lot of event invitations lately. This is one of the advantages of living in the Bay Area: there are always people gathering to talk about something they are building, at every scale from a small evening meetup to a major conference. My recent visits to the Computer History Museum had already reminded me to take better advantage of that. When an invitation to Orkes Shift '26 arrived, I knew almost nothing about the company. The word “agent” was enough to make me curious.

Early on the morning of October 15, I took Caltrain to San Francisco. I like the City, and I especially like walking through it. Joining the morning stream of people leaving the station brought back a familiar routine from nearly twenty years ago, when I commuted to an office on Market Street. The destination was different this time, but walking into the city with everyone heading to work felt much the same. Along the way, I passed Moscone West, where TechCrunch Disrupt was underway. The banners were another reminder of where I was: on my way to one technology conference, walking past another.

The conference was at Convene, near Union Square. I knew the area well, yet I could not remember noticing this particular building. I looked it up and learned that it was constructed as a department store in 1974 and later housed Macy's Men's Store. Ah, that building I remembered. A substantial redevelopment was completed in 2022, and Convene opened its meeting and event venue there in November 2023. Its facilities occupy the fourth and fifth floors, with meeting rooms, gathering spaces, and catering designed around events like this one.

First, though, we had to wait in the lobby. The guard would only let us take the elevator once the event was ready, which turned out to be about five minutes after the advertised 10 am opening. I went up to the fourth floor and found a space considerably more polished than I had expected: large windows, carefully furnished gathering areas, stone counters, and a very good breakfast. There were bagels, pastries, eggs, and individual breakfast bowls arranged with more care than the usual conference coffee table. I do not rank events by their catering, but it does give some indication of the budget and how much effort the host has put into the day. I could tell Orkes was taking this seriously.

I needed an introduction to the host as much as to the subject. Orkes builds a commercial orchestration platform around Conductor, the open-source workflow engine that originated at Netflix. I had heard the name Conductor, but had never used it or really looked into it. Netflix open-sourced it in 2016, after using it internally to coordinate work across services, including parts of its content-processing pipeline.

In the opening keynote, Orkes CEO Jeu George put numbers to that reach. According to his presentation, Conductor was part of the infrastructure behind services accounting for 9% of all U.S. television viewing time, 37% of mobile subscriptions in India, and 40% of online food deliveries in India. The customer talks from Bumble, LinkedIn, and Twilio made the adoption more tangible than a collection of logos. This was an established part of the software infrastructure world that I was not familiar with.

George's argument was that AI agents extend the need for that infrastructure. Agents still call services and perform work over time, while adding decisions that are harder to predict, credentials that need managing, and actions somebody may later need to explain.

Paul Vander Griend from Bumble followed. I looked up the company through my dots agent on my iPhone and learned that Bumble is a dating app. (Almost all my searches seem to go through those agents these days.) His example was handling a member's report of potentially abusive behavior, which has to pass through classification, review, a decision, notification, and possibly an appeal. In Bumble's earlier system, different services reacted to messages, with state and recovery logic spread across them. When something stopped halfway through, engineers had to reconstruct the process. Moving it into an explicit workflow made both the progress and the places to change it easier to see.

His explanation also made durability concrete. The workflow engine keeps the process's recorded state through crashes, deployments, and bad releases. A stuck case remains a visible failed execution, so the team can fix the problem and resume the work instead of piecing together its history from scattered components. A handler is the piece of code in a service that responds to an incoming event, such as a new member report. The engine keeps the overall progress separately from those individual pieces, so restarting or replacing the code that performs a step does not erase the record of what has already happened and what remains to do.

The term choreography was new to me, even though the underlying pattern was familiar. Services react to events and produce more events, with the overall process emerging from those interactions. In orchestration, a coordinator follows an explicit workflow and tracks which steps can run and what has happened. Bumble's report-handling process made the difference concrete: the sequence could be read and inspected in one place, instead of being reconstructed from the behavior of several services.

I initially thought Airflow belonged on the choreography side, but I had that wrong. In Airflow, Python code defines a DAG's tasks and dependencies, and the scheduler coordinates their execution. It is orchestration too. In Orkes, the workflow is represented as JSON describing the tasks and how inputs and outputs connect them. It can be edited visually or as JSON, or generated through an SDK. The definition gives Conductor the sequence to coordinate, while workers and services perform the individual tasks.

Airflow felt closer to an engineering perspective because data pipelines were my reference point. Orkes's presentations started from a business process, such as reviewing a member report or issuing a refund, and showed where services, agents, and people fit into it. That is a useful difference in emphasis, though both require engineering and their capabilities overlap, including support for events and human tasks. What appealed to me here was being able to follow a complete business process as it paused for a person, resumed, or took a different path.

The AI part of Orkes fits into this same structure. A workflow can call an LLM as a task, with a selected model and prompt to classify text or summarize a document, then pass the result onward. It can also invoke an agent whose model chooses which available tools to call as it works toward a goal. Conductor coordinates that execution and records its progress, while the surrounding workflow can still require specific steps and human approvals. That gives developers room to combine predictable sequences with decisions made by a model.

Vander Griend also clarified in the Q&A that event-driven behavior still has a place, such as recomputing recommendations when data changes. An event can also start an orchestrated workflow, so the distinction is about who coordinates the work that follows. His concern was how to manage a complete process such as reviewing a member report. Once that process is explicit, individual steps become easier to examine and improve. This connected with his AI advice: measure the existing step, run AI alongside it, compare the results, and only then consider giving AI the responsibility. The measure has to reflect the outcome that matters. Closing a support ticket achieves little if the customer has to reopen it because the problem remains unresolved.

Lunch continued the morning's generous hospitality, with a long buffet of sandwiches, salads, hot dishes, and little layered desserts. I also spent time at the demos, where the questions could get more specific than they usually do during a presentation.

One presenter described his morning catch-up routine. By the time he woke up, work had already been happening in New York and India, and he needed to know what was going on. His agent gathered information from different channels, connected it to meetings and people, and allowed follow-up questions when something needed more investigation. There was also a demonstration of using Claude with Conductor skills to start building a GitHub-to-Slack workflow. The assistant asked about the repository, destination, authentication, and whether to use polling or webhooks. Another query inspected failures across several clusters and brought the results together. That last example made the interface useful in a very ordinary engineering situation: finding out what had broken without visiting each environment separately.

My question was what Orkes's core value would be as the frontier labs and their coding agents grew more capable. If those tools could also construct workflows, what would remain distinctive about this platform?

The answer focused on durable execution: keeping the state of the work on the server, surviving an interrupted client connection, waiting for a human response, and retaining a history that could be inspected later. My own feeling is that AI has made implementing workflows, or reproducing much of a platform's visible functionality, considerably easier. However, I also agree that durability and reliability are harder to reproduce. A working implementation does not tell me how it will behave when a service fails halfway through, a retry repeats an action, or somebody returns days later to approve a request. That is where I could see a stronger case for an established platform like Orkes.

The demo also exposed a useful limit. When another attendee asked about managing the context of a conversation that keeps growing, the presenter said automatic compaction was not built in. A summarization step could be added to the workflow. Keeping the execution history and deciding which parts of it an agent needs are separate problems.

The afternoon talks showed several ways companies were approaching that surrounding work. Obi Azogu from LinkedIn described reusable business actions, such as granting access to accounts or onboarding a salesperson, as Lego blocks that could be assembled into different processes. Agents extended the same foundation by choosing some of the actions, while workflows still handled predictable sequences and waits for approval. The practical consequence was easier to understand through his onboarding example: getting a salesperson the accounts and tasks attached to their role without weeks of manual coordination.

Nick Lotz from Orkes made recovery visible with a refund demonstration. An unavailable worker left the process waiting. Bringing it back allowed the work to continue and reach a human approval step before the refund. An agent script that only kept progress in memory would need additional machinery to recover after stopping, retry work, and wait for that approval. Here Conductor held the workflow state independently of the worker, while the agent helped interpret the request. This is a responsibility other orchestration systems can also take on. The useful distinction was between the agent deciding what to do and the engine keeping track of the work as it happened. Even then, the refund operation needs protection against being applied twice if a task is retried.

Joe Yan from Twilio Segment brought the discussion back to data infrastructure. Coordinating historical data with incoming events had once involved progress recorded in database columns and recovery through manual intervention. With orchestration handled by a shared platform, teams could concentrate on their own workflows. He described roughly twelve million workflow completions a month. It was a useful reminder that this kind of infrastructure already had substantial work to do before agents became the reason everyone wanted to talk about it.

LinkedIn's Calvin Lei and Yangchen Situ then addressed the familiar experience of supervising coding agents: repeated corrections, forgotten instructions, and changes that become too large to review comfortably. Their process preserved plans, specifications, and execution progress outside the conversation, with review before implementation and limits on how many times agents could try to fix a problem before involving a human. They also described carrying project learning into a knowledge graph for later work. The remaining difficulties were recognizable too: selecting context, maintaining that knowledge, and evaluating whether the process was actually improving. Their account made clear how much engineering remains around the coding itself.

The closing conversation between Google's Geo Varkey and Jeu George considered authority and accountability, using financial systems as examples. One distinction stayed with me: asking an agent to follow a rule is different from enforcing that rule in the tools it is allowed to use. Approval levels, records of actions, and ways to recover from partial failure all become more consequential when software can decide what to do next.

By then I had a clearer picture of where Orkes fits. Much of the attention in AI goes to model makers and the applications built directly on their models. Orkes approaches the same moment through existing business processes and the infrastructure needed to keep them running. The interesting question is how that infrastructure changes when some steps are chosen by an agent. The day's examples gave me a useful introduction to a company, and to a part of the agent ecosystem, that I had known very little about that morning.

I still wondered whether a day would come when agents could handle the whole thing well enough: understanding the business goal, building the workflow, dealing with failures, and maintaining the system afterward. Perhaps an agent could eventually choose or build the execution infrastructure too, leaving much less for us to assemble by hand. I could see a use for Orkes today without assuming the boundary between agent and platform would stay where it is. The conference helped me understand the work involved. How much of that work we will still need to do ourselves remained an open question.

There was a reception afterward, with another impressive spread of food. I stayed briefly, then left a little early. I wanted time to walk through San Francisco.

I went along Market Street, past 575 Market, where my office had been in 2008, and continued to the Ferry Building. That stretch had been my regular walk after lunch in those days.

From there I followed the Embarcadero back toward the station, passing the Bay Bridge and eventually Oracle Park.

It is a route worth taking slowly. The Park felt lonely without baseball: the Willie Mays Gate was closed, the plaza quiet, while other teams were still playing their postseason games. There is always something a little sad about seeing the season continue elsewhere after it has ended at your own ballpark.

Back at the Caltrain station, the banners overhead were advertising Genspark. One introduced an AI called Rocco: “He works on the weekends, so I don't have to.” After a day of workflows, failed workers, human approvals, and agent memory, here was the idea compressed into a promise to commuters. AI was waiting at the station too. The conference had given me a better sense of how much work sits behind a sentence like that.