The WorkOS of the future

The next big software category is not another chatbot.

It is the WorkOS of the future.

I do not mean “project management with a sprinkle of AI”. I mean the operating system for autonomous work: goals, tickets, runtimes, coding agents, review loops, budgets, monitoring, escalation, and proof that anything actually happened.

A lot of current tools are solving one layer of that stack:

• Agent Flywheel attacks the environment problem.
• OpenAI Symphony attacks the orchestration problem.
• CCP attacks the delivery control-plane problem.
• Paperclip attacks the company-level control problem.

None of them is the full WorkOS yet.

The simple model

Here is the stack I keep coming back to:

These tools are not all fighting in the same cage. Most of them sit on different layers. That is the whole point.

Why this matters

Most “AI agent” discourse is still strangely flat.

People compare everything to everything else, as if a coding workstation, a queue runner, a PR autopilot, and a company-level agent dashboard are the same product. They are not. That is how you get nonsense comparisons and brittle systems wrapped in a slick demo video.

A real WorkOS needs four things at the same time:

1. A place for agents to work
2. A way to turn tasks into runs
3. A loop that closes work all the way to outcome
4. Governance so the whole thing does not become an expensive hallucination farm

Most tools in the market solve one, maybe two, of those.

The four contenders

1. Flywheel - the agentic workstation

Repos:

• Site: agent-flywheel.com
• Bootstrap: Dicklesworthstone/agentic_coding_flywheel_setup

Flywheel is not trying to be your company brain.

It is trying to make one engineer or one small team highly productive with a lot of agent tooling, fast. The pitch is simple: bootstrap a VPS or machine with Claude Code, Codex CLI, Gemini CLI, tmux, shell tooling, and a bunch of utilities so you can run many coding agents in parallel without losing your mind.

A lot of teams need this layer before they need anything more ambitious.

Example: You are a founder with three repos, two deadlines, and no patience. You want one box with Claude Code, Codex, Gemini, and shell tools ready, a fast way to fan out work across multiple sessions, searchable memory across those runs, and almost no platform engineering before you start. Flywheel is good here. It gets you from zero to “agents are actually coding” quickly. It is the workshop, not the WorkOS.

2. Symphony - the orchestration layer

Repo: openai/symphony

Symphony matters because it is clear about the architecture.

The headline is not “agent runs code”. We already have that. The interesting idea is the shape of the system: project work becomes isolated implementation runs, and engineers stop babysitting agents directly. Instead, they supervise work at a higher level.

Example: A platform team wants work to start from a tracker, run in isolation, produce artifacts, and write status back into the source of truth. That source might be Linear today. In our world it might be Entity or a swarm queue. The point is the pattern, not the brand. Symphony is the cleanest articulation of this I have seen: work sits in a queue, workers claim it, execution happens in an isolated run, proof returns to the system of record. This is what teams need once raw agent productivity stops being the bottleneck and state integrity becomes the bottleneck instead.

3. CCP - the delivery control plane

Repo: kyan12/ccp

CCP is the most operational of the four.

It is not just saying “turn tickets into runs”. It is saying: take tickets from Linear, dispatch jobs, run a coding agent, create the PR, monitor CI, auto-merge when green, spawn remediation work on failure, create tickets from Sentry or Vercel failures, and keep going until the loop closes.

Example: Production breaks at 2am. Sentry receives the error. A webhook creates a ticket. The job gets dispatched to an agent. The agent opens a PR. CI runs. If CI fails, remediation work gets spawned with the failure logs attached. If deploy fails, Vercel feeds the failure back into the loop. That is software operations starting to become autonomous. This is why CCP is closer to Symphony than Flywheel is - Symphony is the architecture, CCP is the grimy, useful, self-hosted implementation of the software-delivery part.

4. Paperclip - the company control plane

Repos:

• GitHub: paperclipai/paperclip
• Site: paperclip.ing

Paperclip sits above the others.

If Flywheel is the workshop, Symphony is the conductor, and CCP is the release manager, Paperclip is trying to be the company. That sounds absurd until you read what it is actually building: org charts, goals, budgets, governance, many agents across many functions, dashboard visibility across the whole org, and a control plane for autonomous businesses, not just codebases.

Example: Running a small autonomous company with a CEO agent, engineering agents, design agents, support agents, content agents, budgets for each function, and review gates before strategy changes. That is not “PR automation” anymore. That is a business operating model. Paperclip is the clearest expression of that layer right now.

Side-by-side comparison

The WorkOS ladder

What the future WorkOS probably looks like

It probably is not one monolith.

It probably looks more like this:

• a Flywheel-like environment layer for agent workspaces and operator ergonomics
• a Symphony-like orchestration layer for isolated work runs
• a CCP-like loop for shipping, verifying, merging, and remediating software changes
• a Paperclip-like business layer for goals, budgets, governance, and cross-functional coordination
• a system of record tying all of it together

That last piece matters more than people think.

If the system of record is weak, the rest becomes an impressive collection of disconnected automations.

Where Entity fits in

We are not just watching this category. We are building into it.

Entity is the piece I keep thinking about as the system of record and operational surface. Not the only piece. Not the entire WorkOS. But the place where work, state, proof, and visibility can actually live together.

That means:

• work enters the system in one place
• queues are visible in one place
• agents and runs write back into one place
• humans can inspect the current truth without opening five dashboards and saying “I think it succeeded”

A lot of current agent stacks are missing that glue.

Flywheel gives you the workshop. Symphony gives you the orchestration model. CCP gives you the delivery loop. Paperclip gives you the company-shaped control plane. Entity, at least in the direction we are pushing it, can become the memory, visibility, and source-of-truth layer that makes the whole thing legible.

That matters more than another demo.

Where to start

If you want value tomorrow morning, start with the lower layers.

• Use something Flywheel-shaped to make builders fast.
• Use something Symphony-shaped to stop improvising how work gets executed.
• Use something CCP-shaped when you want ticket-to-merge loops that can recover from failure.
• Use something Paperclip-shaped once you are managing not just code, but an actual autonomous organization.

The future WorkOS is not one repo. It is a stack.

The winners will not be the tools with the flashiest demo. They will be the ones that close the loop cleanly, make state legible, and let humans step in without breaking the system.