Orchestration is all you need

Many companies use a 360 feedback tool. They help you gather feedback from your peers - after projects, before promotions, during annual reviews. The idea is great: let people drive their own development by hearing from colleagues who work with them.

The tools work. But they sometimes frustrate me.

Why? They're often locked into "feedback sessions" where you can't easily gather incremental feedback, on the fly, throughout the year. The process is largely prescribed - everyone follows essentially the same steps in the same order.

One employee might want to send requests to everyone at once, then have follow-up questions generated based on initial responses. Another might prefer starting with a small group, identifying themes, then asking targeted questions to the rest. Neither can. The tool owns the process. The user just clicks through it.

I used to think they were just awkward tools. Now I realise they're how we've built all software. And why that's about to change.

The Old Model

Here's how we build enterprise software today. We gather requirements: "This is how we do things here." We translate that process into code. We ship a product that encodes that consensus view.

This made sense. Customisation was expensive. Labour was scarce. Building a rigid process into software meant efficiency gains that justified the trade-off.

The result: averaged-out workflows that work reasonably well for everyone but optimally for no one. Every user gets the same experience, regardless of their context or ideas about how to do things better.

We encoded "the way we've always done it" into software that can't imagine doing it differently.

This was a reasonable trade-off. It's about to become a fatal one.

What Changed

AI models like Anthropic's Opus 4.5, combined with agent harnesses like Claude Code, provide something genuinely new: effectively infinite scalable intelligent labour.

This isn't like previous automation waves. Low-code platforms still required you to do the work. ERP customisation was expensive and slow. This is different for three reasons:

1. The cost of customisation drops to near-zero. AI generates the implementation.
2. The tooling is intelligent. Natural language interfaces lower the skill barrier.
3. You now have workers. Whatever you orchestrate, AI executes.

The old trade-off no longer makes sense. If your competitor's employees can innovate on their processes and yours can't, you lose.

This isn't theoretical. Steve Yegge built Gas Town - an orchestration system running 20-30 Claude Code instances simultaneously - producing 75,000 lines of Go code and 2,000 commits in 17 days. Developers report building complete applications with 20,000+ lines of code, full database architecture, and comprehensive test suites in single overnight sessions. Healthcare agents autonomously sift massive datasets for clinical target identification. Finance agents handle vendor invoices and reconciliations end-to-end.

Infinite intelligent labour is here. The question is whether you're positioned to use it.

The Orchestration Moat

Tech moats are disappearing. Any software can be generated or cloned. Yes, other moats remain - unique domain knowledge, proprietary data, brand position. But for operational excellence, what matters now is how well you orchestrate AI to improve how work gets done.

"The pace of innovation is all that matters." — Elon Musk

Baked-in processes throttle innovation. If your software dictates how employees work, they can't experiment with better approaches. They can't adapt to new contexts. They can't leverage AI to find improvements you never anticipated.

The companies that win will be the ones that give employees orchestration power - the ability to direct AI labour toward their specific goals, in their specific contexts, using their specific judgement about what works.

The New Architecture

So what should we build instead? A two-layer model: primitives and skills.

Primitives are atomic, constrained building blocks. The platform provides them. They encode non-negotiable business rules. A "Send Marketing Email" primitive checks the opt-in database - you can't spam customers regardless of how you orchestrate your workflow. A "Store Feedback" primitive ensures security and appropriate access controls. A "Process Payment" primitive handles compliance.

Users cannot bypass these constraints. This is where accountability lives.

Skills are composable units of orchestration. They define how work gets done. They can exist at three levels: platform defaults, team overrides, and individual user overrides.

The platform might provide a default "360 Feedback" skill. A team might override it with their preferred approach. An individual might override that with their own variation. Each level inherits from the one above but can customise as needed.

Think of Git's architecture. Plumbing commands are low-level, stable, constrained - the primitives. Porcelain commands are high-level, user-facing, and customisable - the skills. Most users work with porcelain. Power users can go deeper. Anyone can build new porcelain on top of plumbing.

Emerging standards like Agent Skills - originally developed for Claude Code and now open-sourced - provide composable formats for packaging these orchestration units. Skills can be shared, versioned, discovered by agents on demand.

The 360 Tool, Reimagined

Let's return to the feedback example. Here's what the primitive layer provides:

• Send message to colleagues via channel
• Store feedback securely with appropriate access for managers and designated reviewers
• Schedule an agent task
• Generate summaries from responses
• Share results with designated parties (manager, promotion committee)

Now two employees can define entirely different skills on top of these primitives.

User A's approach (breadth-first, fully automated):

1. Agent sends feedback request to all peers simultaneously
2. Agent generates clarifying follow-up questions based on initial responses
3. Agent sends follow-ups and collates responses
4. Agent synthesises themes
5. User reviews and optionally edits before sharing with manager

The entire process is agent-orchestrated. The human reviews at the end.

User B's approach (depth-first, human-in-the-loop):

1. Agent sends to a small initial group
2. Agent identifies core themes from responses
3. User reviews themes and adjusts focus areas
4. Agent generates targeted questions and sends to remaining peers
5. Agent synthesises final report

The process is agent-orchestrated but the human intervenes mid-way to shape the direction.

Same primitives. Same goal. Different orchestrations. Different levels of human involvement. Both valid. The user - not the software - decides what works for their situation.

When User B's approach proves effective, they share it as a team skill. The team adopts it as their default. But individuals can still override it. And analysis of agent session logs can reveal further improvements, allowing skills to evolve continuously.

The Objections

"Most users can't or won't do this."

True. And fine. The architecture supports tiers. Most users will stick with platform or team defaults. Some will customise lightly. Power users will go deep. What matters is that the option exists. Those who can innovate shouldn't be constrained by those who can't.

"Who's accountable when things go wrong?"

System-enforced constraints live in primitives, not skills. Skills encode workflow constraints - do A, then B - but users can change those. Primitives encode business rules that cannot be bypassed.

You can orchestrate your feedback process however you want. You cannot orchestrate around "check marketing opt-in" or "verify payment compliance." Platform designers must obsess over which constraints are truly non-negotiable - and fight to minimise that list.

"Won't successful skills calcify into the rigid processes you're critiquing?"

Possibly. The innovation of one user becomes the default for others. But with a key difference: users can always override. A shared skill is a starting point, not a prison. And continuous analysis of how agents are being used can surface improvements automatically.

"This sounds like low-code all over again."

Low-code failed because you still had to do the work. You designed workflows, but humans executed them. Now AI executes them. You orchestrate; it works. Infinite intelligent labour changes everything.

What This Isn't

This isn't "all process is bad." Some process creates value through standardisation. Stripe's payment flow is rigid because that rigidity ensures compliance, security, and consistency. Git encodes a specific model of version control that enables the entire ecosystem. The argument is against process that restricts innovation without providing compensating value.

This isn't "fixed agents are wrong." Structure is fine. Even cutting-edge orchestration systems have defined roles. The critique is about users being unable to modify or override the orchestration - being locked into someone else's idea of how work should flow.

This isn't "coding disappears." The abstraction layer keeps rising - from machine code to assembly to high-level languages to natural language. Andrej Karpathy calls the current shift "Software 3.0": we moved from telling machines how to do things, to showing them through examples, to simply describing what we want. But someone still thinks about workflows, constraints, architecture. It's still software - just at a higher level.

Three Principles

For those building systems in this new world:

1. Don't bake in business processes unless they are truly non-negotiable.

Default to flexibility. Every constraint should justify itself. If a process can reasonably vary by team or individual, don't lock it down.

2. Obsess over minimising non-negotiables.

Fight hard before declaring something a fixed constraint. The fewer things locked into primitives, the more room for innovation in skills.

3. Give users the tools to innovate via orchestration.

Primitives they can trust. Skills they can modify. Agent harnesses they can direct. The combination enables individual employees to leverage infinite AI labour toward their specific goals.

What To Do Monday Morning

For individuals:

Start using an agent harness like Claude Code. Use it to automate a business process - not coding, actual work. Break the process into steps. Use available tools as primitives. Extract what you build into a reusable skill. Share it.

A simple example: download video transcripts with yt-dlp, have Claude summarise key points, generate a PDF overview with Pandoc. Package that workflow as a skill others can use and modify.

For organisations:

Audit your software. Where is process baked in that doesn't need to be? Identify which constraints are truly non-negotiable - compliance requirements, security rules, legal obligations. Encode those into primitives. Make everything else flexible.

Enable team and user-level skill overrides. Analyse agent session logs to surface improvement opportunities. Let the system evolve based on how people actually use it.

The Shift

The way we build and use software is changing. Companies that give employees orchestration power will move faster - not because their technology is better, but because their people can continuously improve how work gets done.

Companies that lock process into rigid software will be outcompeted. Not immediately. But inevitably.

The question isn't whether this shift happens. It's whether you're positioned for it.

Orchestration is all you need.