Skip to main content

AI Orchestration

Are you using agents to write the code — or to run the business? Same models, different job. Confuse the two and both fail.

Agents split cleanly into two orchestration tracks. One builds the factory. The other runs it. Pick the track before picking the tool.

Two Tracks

TrackJobWho directsFeedback loop
Agentic CodingWrite, refactor, and test softwareEngineerCompile, test, deploy
Agentic WorkflowsRun business operations — sales, ops, researchOperator / agentOutcome, revenue, KPI

Coding agents live inside the IDE and the repo. Workflow agents live inside the business — email, CRM, docs, calendars, ledgers. The first ships code. The second ships value.

Why Split

A coding agent optimizes for a unit test. A workflow agent optimizes for a customer outcome. The gauges are different, the tools are different, the quality bar is different. A single "AI strategy" that ignores the split ends up with great code nobody uses and busy ops nobody measures.

Key Concepts

ConceptDefinition
DirectionHuman or agent objective the agent must follow
Tool accessThe agent's hands — APIs, CLIs, MCP servers, files
Context windowWhat the agent sees when it reasons
Autonomy levelHow far it runs without human confirmation
Feedback loopHow success is measured and fed back in
HandoffWhere one agent's output becomes another's input

Where Each Lives

Context

Questions

Which of your current AI efforts is building the factory, and which is running it — and are you confusing the two?

  • When does a coding agent's success metric conflict with a workflow agent's success metric?
  • What breaks first when the same person owns both tracks without separating the loops?
  • Where does a coding agent need to hand off to a workflow agent — and who designs that seam?
  • If a workflow agent produces bad outcomes, is the fix a better prompt or a better process?