Coding agents vs coding assistants vs orchestration CLIs

"AI coding assistant", "coding agent", and "orchestration CLI" get used as synonyms on comparison pages, and the purchases that follow go wrong in a repeatable way: a team that needed coordination buys a suggestion engine and grades it on autonomy, or a solo developer buys a coordination layer and grades it on chat quality. The three names are not synonyms. They name three different jobs, stacked one above another, and the honest way to tell them apart is not vendor positioning but one mechanical question: when a unit of coding work advances a single step, which component made that step happen?

That question is the dividing line this page defends. Each category below is defined from the vendor's own published page, then carries the two things a definition is for — the category's failure model and the concrete consequences of choosing it. Where finer-grained layering matters, What a coding-agent harness is is the page that separates model from agent from harness from IDE from control plane; this reference stays at the level of the purchase decision.

The dividing line, in one breath

• A coding assistant moves the cursor. You hold the loop: the assistant proposes the next edit or answer, and nothing changes until you accept, reject, or retype it.
• A coding agent moves the repository. You hand over a goal; the agent plans, edits files, runs commands, and reports back what it did.
• An orchestration CLI moves the agents. Deterministic code above every agent decides which task runs, in which isolated workspace, under what bounds, and what evidence each run must leave behind.

Three tiers, three verbs: suggest, execute, coordinate. The rest of this page earns that compression — each tier defined by its own vendors, each with the failure model that actually decides whether you should buy it.

Coding assistants: the proposal tier

GitHub Copilot is this tier's reference product, and its own pages are the cleanest definition available. The product is marketed as "Your AI pair programmer", and the feature page says Copilot "provides contextualized assistance throughout the software development lifecycle, from inline suggestions and chat assistance in the IDE to code explanations and answers to docs in GitHub and more". Even the mechanics are documented in proposal terms: prompts and surrounding context are sent to the model "to make a probabilistic determination of what is likely to come next and generate suggestions". GitHub uses the category noun in passing too — "unlike other AI coding assistants" — and the job described everywhere is assistance, not execution.

Microsoft's own editor documentation grades this tier honestly from above: "Agents are the most autonomous of several AI experiences in VS Code. For lighter-weight help, you can also use chat, inline chat, inline suggestions, and smart actions." The assistant is that lighter-weight help by design, and the design is the safety.

The failure model follows. An assistant cannot go rogue in the usual sense, because it cannot act — it can only be wrong persuasively, and the blast radius of one failure is one suggestion that a reviewer accepts without reading. That safety has a price, and the price is the selection consequence: assistant throughput scales linearly with human attention, because its unit of work is your keystroke. Choose this tier when the constraint is typing and review speed against a human who still reads every line, and do not expect it to compound — the tier has no concept of a task, only of a next suggestion.

Coding agents: the execution tier

The agent tier is defined by transitive verbs. The Claude Code documentation opens with "Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools", and OpenAI's Codex CLI repository describes itself as a "Lightweight coding agent that runs in your terminal". Reads, edits, runs: the category boundary is exactly there — an agent acts on the repository rather than proposing that you act.

The most instructive boundary case wears the other tier's clothes. Aider markets itself with assistant vocabulary — "AI pair programming in your terminal", where "Aider lets you pair program with LLMs to start a new project or build on your existing codebase" — and then documents execution mechanics one paragraph later: "Aider automatically commits changes with sensible commit messages." A tool that commits to your Git history is executing, whatever the tagline says. That is the rule this page exists to hand you: labels are marketing, verbs are categories.

The failure model changes tier completely. An assistant fails by being wrong; an agent fails by doing — working past the point of value, reporting a plausible completion that was never verified, or losing its own context mid-task. Blast radius per failure is repository state and elapsed time, not one suggestion. Review therefore shifts from per-suggestion to per-run, which is the real selection consequence: the agent tier pays off when a task is well specified and you add what the tier does not ship on its own — explicit bounds, stop conditions, and a record of what the run did. The smallest habit that installs all three is the bounded agent loop; the architecture of containing long-running agents is treated in depth in harness engineering architecture. Without those additions, an agent purchase is a bet on averages with unbounded downside.

Orchestration CLIs: the coordination tier

Once several agent tasks share one repository — parallel agents on separate features, long chains where one agent's output feeds the next, scheduled runs nobody watches — a third job appears. Someone has to decide which work runs at all, where each run executes so agents cannot overwrite each other, what bounds it, what it must record, and who admits the finished change into shared history. That job is not additional intelligence; it is coordination, and it is owned by deterministic software standing above the agents.

The category is young enough that its products still describe it plainly. Conductor's pitch is one sentence — "Run a team of coding agents in the cloud" — and its architecture note is the tier's signature move: "Conductor runs the first-party Claude Code, Codex, Cursor, and OpenCode agents under the hood." The orchestrator's value is the runs, not the reasoning; it is judged on what happened to the work, never on suggestion quality. YYLO occupies the same tier from the open-source side. Its README states that "YYLO orchestrates AI coding agents and structured development workflows", and its documentation describes it as a control plane that "coordinates bounded coding-agent work while preserving task, worktree, model, session, validation, review, and commit evidence".

The failure model is systemic rather than generative. A coordination tier fails when two agents write one branch, when a run dies and its evidence dies with it, or when an unreviewed change reaches shared history because nothing gated the transition. No smarter model fixes any of those; they are prevented structurally — isolated workspaces per task, serialized admission, durable records that survive the process that made them. Selection consequence: buy this tier when multiple agent tasks genuinely share a repository and history must stay reviewable, and expect its cost to feel like overhead until the second concurrent agent arrives. The composition patterns — each agent behind one step contract, typed outputs handed between steps, one gate deciding what lands — are laid out in Use multiple coding agents in one workflow.

One product can span all three tiers

The tiers are jobs, not boxes on a pricing page, and vendors climb them without renaming themselves. GitHub's own metering copy walks the ladder in a sentence: "You use credits when you chat with Copilot, work with agents, or use Copilot CLI, and Spaces." Chat, agents, CLI — three tiers metered inside one product. Visual Studio Code documents assistants sitting below agents in a single editor. Aider pitches pairing and ships execution.

So "is Copilot an assistant?" is a question with no stable answer, and that instability is the point: nouns on landing pages follow positioning, while the verbs in the documentation — suggests, edits, runs, orchestrates — change only when the product's actual behavior changes. Categorize by the documented verb, then ask which of the jobs you are buying and whether your failure tolerance matches that tier. A vendor label can migrate in a release cycle; the failure model you signed up for cannot.

Choosing by failure model

Three questions, one per tier, each phrased so the answer is checkable:

• What happens when it is wrong? If the answer must be "a suggestion I rejected", you are buying the assistant tier — accept that throughput scales with your attention, and that nothing lands without you.
• What happens while I am not watching? If the tool executes a goal unattended, you are buying the agent tier — budget for bounds, stop conditions, and per-run evidence before the first run, because the tier's failures are actions, not sentences.
• What happens when several runs share one repository? If more than one agent task will touch the same history, you are buying the coordination tier — isolation, serialized admission, and durable evidence stop being preferences and become the product.

The inverse mistakes cost more than the purchases. Grading an orchestrator on suggestion quality judges it against a job it does not perform; demanding autonomy from an assistant means demanding the one property it is built not to have; and adopting agents without the coordination tier is how "my agent went rogue" becomes a postmortem category.

Where YYLO sits

YYLO is a product of the third tier: an orchestration CLI and control plane that drives installed agent CLIs instead of competing with them. The agents and models stay selectable per run — the switching mechanics are documented in Switch coding-agent harnesses — and task truth plus run evidence live above every harness swap, which is the coordination tier's whole offer. How the tiers assemble into an open-source stack, layer by layer with the open-source options at each, is the companion map in The open-source AI coding stack, layer by layer, and the operational reference is the YYLO documentation.

Cite this reference

Every quotation above was taken from the linked public page and re-checked, word for word, against the live text on 2026-08-28; YYLO's positioning was verified the same day against the repository's committed README and this site's committed documentation pages. Products climb tiers as they grow — treat each quote as a dated snapshot and confirm the verb still holds before you rely on it after that date. The three-tier contrast itself (suggest, execute, coordinate; cursor, repository, agents; proposal, action, system) is this page's original synthesis, and if it is useful to you, cite this reference — the stable URL is rendered in the panel below — and credit it rather than restating the tiers as folklore.