Orchestration — client capability tiers
Orchestration on the HCS estate is organised by what a connected AI client can do, not by which scope a repo belongs to. There are two tiers. Every supported tool falls into exactly one.
The two tiers
| Tier | Capability | Real tools today | Digest |
|---|---|---|---|
| A — subagent-capable | Can spawn parallel subagents, run lifecycle hooks, and load reusable skills | Claude Code | digests/tier-a.md |
| B — single-agent | Drives one agent; no parallel fan-out, no hook system, no native skill layer | OpenAI Codex CLI, Google Gemini CLI, Cursor, VS Code Copilot | digests/tier-b.md |
A client asks the MCP which tier it is by calling bootstrap(repo, client) — the returned payload already contains the right digest for that client. It never has to guess.
Why tier is about capability, not scope
Scope (hcs, tierpoint-prodtech, azurelocal) decides which rules apply to a repo — the standards, the hard rules, the naming matrices. Tier decides how a client executes those rules — in parallel with fan-out, or sequentially on its own.
These are orthogonal. A tierpoint-prodtech repo is governed by the same tier logic whether you open it in Claude Code (Tier A) or Cursor (Tier B); only the execution style changes, never the rules being enforced. That is why there is one orchestration standard for all scopes and all models — it adapts by client capability, not by scope.
The corollary matters for correctness: a Tier B client must not invent Tier A machinery to look compliant. There are no Codex agent files, no hooks.json, no fabricated subagents. A single-agent client runs the same seven workstreams (build, review, refactor, test, document, investigate, operate) one step at a time and validates through the MCP's deterministic tools (validate, check_drift). Faking fan-out is a defect, not conformance.
What each tier does differently
| Concern | Tier A (Claude Code) | Tier B (Codex / Gemini / Cursor / Copilot) |
|---|---|---|
| Workstreams | Skills sequence specialised subagents (planner → coder → reviewer → …) | The one agent performs each step itself, in order |
| Parallelism | Wave-packing: max 8 concurrent spawns, max 1 agent per repo | None — one repo, one step at a time |
| Validation | Fold into MCP validate; validators can also run as subagents | MCP validate / check_drift called directly, results read by the agent |
| Security gate | security-waf-caf subagent, non-overridable block | Self-review against WAF/CAF standards + human approval gate |
| Native config | .claude/ (agents, skills, hooks, commands, settings) | Tool-native config only (.codex/config.toml, .github/copilot-instructions.md, etc.) — no emulated .claude/ |
Full multi-model configuration
This page covers only the orchestration split. For the complete cross-tool configuration model — the canonical AGENTS.md + CLAUDE.md shim layout, the per-tool config matrix, MCP wiring per client, the memory model, and session model overrides — see the agents standard. This page does not duplicate that detail.