Company OS vs Agent Framework vs Orchestration
Teams often collapse three different problems into one shopping trip: “Which agent platform should we buy?”
That question mixes agent frameworks, orchestration, and what I call a Company OS. They sit at different layers. Buying the wrong one burns months.
The three layers in one sentence each
Agent framework — libraries and runtimes for building agents: planning loops, tool calling, memory primitives, eval hooks. Think LangGraph, AutoGen-style stacks, custom agent runtimes.
Orchestration — scheduling, routing, retries, and wiring between systems. Think n8n, Temporal, Inngest, queue workers, cron plus webhooks.
Company OS — the operating layer that answers what matters, who may act, with which tools, under which approvals, and whether the outcome landed. Models and workflows are capabilities inside that layer. See the Company OS thesis and Operating Note 001.
Side-by-side
| Concern | Agent framework | Orchestration | Company OS |
|---|---|---|---|
| Primary question | How does an agent think and act? | How do steps run reliably? | How does the organisation turn intent into accountable action? |
| Typical artifact | Graph, prompt pack, tool schema | Workflow, job, webhook chain | Priority map, permissions, approval policy, outcome loop |
| Failure mode | Clever demo, brittle ops | Brittle glue without judgment | Autonomy without direction or ownership |
| You feel it when… | Tool choice and planning are hard | Retries, schedules, and integrations dominate | Agents ship work nobody asked for |
What each is good at
Agent frameworks
Use them when the hard part is agent behaviour: multi-step reasoning, tool selection, structured outputs, evaluation.
They do not automatically give you:
- org-wide priorities
- shared business memory across teams
- human approval architecture
- cost and permission governance across ten tools
Orchestration
Use it when the hard part is reliability of movement: triggers, retries, fan-out, connecting GitHub → Linear → Slack → datastore.
Orchestration is essential in production agent systems. My stack uses n8n heavily for exactly that. It is still not an operating model. A perfect workflow can still automate the wrong work.
Company OS
Use this framing when the hard part is coordination and accountability:
- What matters now?
- What context should inform the work?
- Who or what acts?
- Which systems, within what limits?
- Which decisions need a human?
- Did the outcome match intent?
That is the six-layer model on /company-os. Frameworks and orchestrators show up inside layers 3–4. They are not substitutes for layers 1, 5, and 6.
A concrete example
Goal: publish research-backed posts across several sites with human approval.
- Framework: draft agent, research agent, critic agent, tool schemas for search and CMS.
- Orchestration: daily trigger, handoffs, GitHub PR open, Slack notify, retry on API failure.
- Company OS concerns: which sites are in scope this week, brand voice constraints, who approves publish, what “done” means, how performance feeds next priorities.
Without the third layer, you get volume. With it, you get directed volume.
Decision shortcut
- Bottleneck is agent quality → invest in framework + evals.
- Bottleneck is fragile integrations → invest in orchestration + observability.
- Bottleneck is unclear ownership / runaway automation → design the operating layer first (Company OS thinking), then pick tools.
Most European product teams I talk to already have models and a few workflows. Their gap is the operating layer: priorities, permissions, approvals, and feedback.
How this maps to my stack
In production I use all three deliberately:
- Framework / agent runtime for specialised agents (content, data, ops)
- n8n + event jobs for orchestration
- MCP gateway for tool access with boundaries
- Company OS thesis for how those pieces relate to human intent and outcomes
Full stack notes: /stack. Practice definition: What is agentic engineering?.
If you are hiring
You rarely need “someone who knows LangGraph.” You need someone who can place the right layer in the right place — and ship a first reliable loop. That is the agentic engineer brief, not a model-tuning brief.
Book a discovery call if you want a written map of which layer is your actual bottleneck.
FAQ
Is Company OS a product I can install?
Not as a single SKU. It is a working architecture thesis grounded in systems I operate. Treat it as a design lens, then implement with concrete tools.
Should we standardise on one vendor for all three layers?
Usually no. Best-of-breed orchestration plus a focused agent runtime beats a bloated “platform” that is mediocre at everything.
Where do MCP gateways fit?
Tool and permission infrastructure — closer to orchestration and guardrails than to “the OS.” They enforce how agents touch systems; Company OS still decides why and whether.