← all writing
2026-05-01 · 7 min read

Agent Orchestration: The 3 Big Releases (Apr 2026)

Warp went open source, Cursor shipped an SDK, and OpenAI open-sourced Symphony — three releases in one week that move the unit of work from prompt to ticket.

A simple guide to three releases reshaping how AI coding agents are built, deployed, and managed. Written for founders, PMs, designers, and operators — not just engineers.

TL;DR

The unit of work is shifting from prompt to ticket. Engineers are moving from babysitting one chat at a time to managing fleets of agents through boards and pipelines. Three releases in one week made this concrete:

  • Warp open-sourced its terminal — but the contributions are written by AI agents, not humans
  • Cursor SDK lets you run Cursor's coding agents from anywhere — your CI, your backend, your product
  • OpenAI Symphony turns your Linear board into the control panel for autonomous agents

Whoever owns this orchestration layer owns the next dev tools stack.

1. Warp goes open source

What is Warp?

Warp is a modern terminal app — the black window where developers type commands. Most terminals haven't changed in 40 years. Warp rebuilt it from scratch in Rust with a block-based interface (each command and its output is a clean visual block) and built-in AI (you can type "find files larger than 100MB" in plain English and it generates the right command). Over time it evolved from a terminal into what they now call an agentic development environment (ADE) — a place to run and manage AI coding agents.

What just happened

On April 29, 2026, Warp open-sourced its client on GitHub under AGPL-3.0, with OpenAI as founding sponsor. Within 24 hours it had 35K+ stars; now over 41K.

The unusual twist

The contribution model is unlike any other open-source project. Instead of humans writing PRs:

  1. You file an idea or bug as a GitHub issue
  2. A maintainer tags it ready-to-spec (needs design discussion) or ready-to-implement (just needs code)
  3. You tag @oss-maintainers
  4. An AI agent (Warp's Oz platform) writes the actual code
  5. Humans review and merge

Warp's reasoning: writing code isn't the bottleneck anymore — the bottleneck is humans deciding what to build and verifying it works. So let agents do the typing while humans focus on direction and review.

Important nuance: "open source" ≠ "free product"

The code is free to read, fork, and modify. But Warp is split into two pieces:

  • The client (runs on your laptop) — open source, free
  • The cloud backend — Oz orchestration, agent runtimes, codebase indexing — closed source, metered, costs money

If you fork Warp and run it yourself, you get a nice terminal — but no AI agents. The valuable infrastructure stays paywalled. This is called open core.

Pricing

  • Terminal features: free forever on Mac, Windows, Linux
  • Free tier AI: 75–150 credits/month
  • Build plan: $20/month for 1,500 credits + BYOK (bring your own OpenAI/Anthropic/Google API key)
  • Business: $50/user/month

How you'd actually use it (example)

You want a custom keybinding or a niche integration that Warp wouldn't prioritize on their roadmap. Open an issue describing it, tag the bot, an agent ships the PR, and it lands in the product. You shaped the tool you use without writing the code yourself.

Official links

2. Cursor SDK (public beta)

What is Cursor?

Cursor is the AI-powered code editor (built on VS Code) that's become the default for many engineering teams. Until now, its agents only worked inside the Cursor app.

What just happened

On April 29, 2026, Cursor launched the Cursor SDK in public beta. The same agents that power Cursor's desktop app, CLI, and web app are now callable from anywhere — your CI/CD, backend services, custom internal tools, even customer-facing products.

import { Agent } from "@cursor/sdk";

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  cloud: {
    repos: [{ url: "https://github.com/yourcompany/yourapp", startingRef: "main" }],
    autoCreatePR: true,
  },
});

const run = await agent.send("Fix the auth token expiry bug");

The infrastructure Cursor owns (and why this matters)

The model isn't the moat — the harness around the model is. Cursor handles all the boring infrastructure that's usually 80% of the work:

  • Cloud VMs with strong sandboxing, dedicated per agent run
  • Codebase indexing (semantic search + grep, years of engineering investment)
  • Context management (deciding which files to load into the agent's window)
  • Session state (agents keep running even if your connection drops)
  • MCP server support (connect to GitHub, Linear, internal tools)
  • Subagent delegation for complex multi-step tasks

Cursor's agents are also specifically trained for coding tasks (their Composer 2 model), not general-purpose chat. You get coding-specialized intelligence without managing the harness.

What it replaces

No IDE. No local setup. No git pull. No npm install. No waiting for indexing. The agent runs on Cursor's cloud and opens a PR. You wake up, you review.

How you'd actually use it (example)

You run a SaaS product. A customer files a bug at 3am. Your webhook fires the SDK. An agent clones your repo, reproduces the bug, writes a fix, runs your tests, opens a PR, posts the link back to your support tool. You wake up and review one PR — that's your only job. Companies already using it in production: Rippling, Notion, Faire, C3 AI.

Pricing

Token-based consumption pricing (not per-seat). You pay for what your agents actually consume.

Official links

3. OpenAI Symphony

What is it

Symphony is an open-source specification from OpenAI (Apache 2.0 license) that turns project management tools like Linear into the control panel for AI coding agents. Every open ticket spawns an agent that codes, tests, and opens a PR.

Why OpenAI built it

It came out of a real bottleneck inside OpenAI. Their engineers found they could only manage 3–5 concurrent Codex sessions before context-switching became painful. The fix wasn't faster agents — it was changing the unit of management from "session" to "ticket." Result: some internal teams reported a 5x increase in landed PRs in the first three weeks.

How it works

  1. Symphony continuously polls your Linear board
  2. Every open ticket gets an isolated agent in its own workspace
  3. The agent runs continuously — codes, tests, monitors CI, rebases, resolves conflicts
  4. Agents produce proof of work artifacts: CI status, PR review feedback, complexity analysis
  5. If an agent crashes, Symphony restarts it
  6. Human reviews at the work level, not the session level

Agents can even create work themselves — during implementation, they often notice improvements (refactors, performance issues) and file new tickets.

It's a spec, not a product

This is the part most coverage gets wrong. Symphony is a written specification plus a reference implementation in Elixir. OpenAI is not selling it as a hosted product. They published a SPEC.md describing how the orchestration should work and said "build your own." The spec is model-agnostic. As of v1.1.0 it supports the Kata CLI as an alternative agent runtime — meaning you can run Symphony with Claude Code, Gemini, or other models, not just Codex.

How you'd actually use it (example)

A PM creates a Linear ticket: "Add CSV export to dashboard." Symphony picks it up, spawns an agent in an isolated workspace, the agent ships a draft PR with tests, and the ticket moves to In Review automatically. No engineer touched it until review time.

The skeptical read

More PRs ≠ more shipped value. Generation scales effortlessly; review, testing, and governance do not. The real bottleneck just moves from writing to reviewing. Symphony is also explicitly an engineering preview — not yet recommended for production use.

Official links

How they fit together

These aren't competitors — they're different layers of the same stack:

| Layer | Tool | What it does | |---|---|---| | Trigger | Linear, GitHub, customer support | Where work originates | | Orchestration | Symphony (spec) | Decides which work goes to which agent, manages state | | Agent runtime | Cursor SDK, Claude Code, Codex | Actually writes the code | | Infrastructure | Cursor cloud, Warp Oz, your own VMs | VMs, sandboxing, indexing | | Interface | Warp terminal, Cursor IDE, your own UI | Where humans review and intervene |

You could theoretically run Symphony + Cursor SDK + Linear as one pipeline: Symphony watches your Linear board, hands tasks to Cursor SDK agents running in Cursor's cloud, agents ship PRs back. That's the emerging stack.

What this means for non-engineers

If you're a PM, designer, or operator: the management metaphor is becoming familiar. You're moving from "chat with AI" to "run a board of AI workers." The same pattern applies beyond coding — content pipelines, support tickets, data analysis, marketing operations. The interface (Linear/Notion/your own board) becomes the control panel; the agents become the workforce; humans become reviewers and direction-setters. The quote making the rounds: "As agents increasingly join the workforce, we'll see the rise of the agent boss" — Jared Spataro, Microsoft.

Last updated: May 1, 2026

next up
Earth in Blender + a live website — the full guide →