TL;DR
- Horizontal agents go wide: one general-purpose system handles drafting, research, routing, and cross-team tasks. Vertical agents go deep: one domain workflow (legal review, clinical documentation, fraud checks) with compliance, schema, and system-of-record constraints baked in.
- These are product choices, not model choices. The LLM is often the smallest part of a production vertical agent; deterministic policy, audit trails, and domain adapters do the load-bearing work.
- Loop engineering applies to both, but the loop you design changes shape. Horizontal loops optimize for routing, context hygiene, and safe breadth. Vertical loops optimize for verification against domain rules, human checkpoints, and replayable audit evidence.
- Do not confuse product horizontal/vertical with integration horizontal/vertical. In protocol terms, MCP is the vertical integration layer (agent → tools/data) and A2A is the horizontal coordination layer (agent ↔ agent). Mature systems usually need both.
- Most enterprises land on a hybrid: a horizontal coordinator (Copilot-style router, internal orchestrator, or coding-agent harness) that delegates high-stakes work to vertical specialists.
- Start horizontal for exploratory, low-risk breadth. Go vertical when failure cost, regulation, or proprietary workflow data makes generic models insufficient. Design the loop before you scale either one.
- Ship specs in five template layers (loop contract → integration → domain surface → verification → durable state). PMs start at Layer 1; engineers add layers as the workflow earns autonomy.
What You Will Learn Here
- What horizontal and vertical agents mean in 2026 product and architecture conversations—and what they do not mean.
- How loop engineering (the perceive → plan → act → verify cycle) differs when you optimize for breadth vs domain depth.
- A hybrid reference architecture: horizontal router, vertical workers, MCP tools, optional A2A handoffs.
- A decision matrix for PMs and a loop-design checklist for engineers.
- Template layers: five artifacts (loop contract → integration → domain surface → verification → durable state) with a “start with Layer 1” path for PMs.
- Where this article stops (and which related devlog posts go deeper).
This article is for engineers and PMs planning agent systems beyond a single chat prompt. If you already use coding agents daily, think of this as the layer above tool choice: which agent shape earns autonomy, and what loop makes that safe.
Two Vocabularies, One Stack
“Horizontal” and “vertical” show up in two separate conversations. Mixing them causes bad architecture reviews.
| Vocabulary | Horizontal means | Vertical means |
|---|---|---|
| Product / market | General-purpose agent across departments and tasks | Domain-specific agent for one industry or workflow |
| Integration / protocols | Agent-to-agent coordination (peer delegation) | Agent-to-tool/data access (MCP servers, APIs, DBs) |
Both are useful. They are not the same axis.
Primary architecture guidance (Anthropic, Google A2A, Microsoft Copilot Studio) emphasizes routing/orchestration plus specialists—a hybrid loop—not a forced choice between “Copilot everywhere” and “one vertical vendor per domain.”
PRODUCT VIEW
┌──────────────────────────────────────┐
│ Horizontal agent (wide coordinator) │
│ routes ──► vertical specialists │
└──────────────────────────────────────┘
│
INTEGRATION VIEW
┌─────────── A2A (agent ↔ agent) ───────────┐
│ │
Horizontal router Vertical worker
│ │
└──── MCP (agent → tools/SOR) ────────────────┘
│
EHR / CRM / Git / ledger
Coding-team mapping: Claude Code or Cursor as the horizontal harness; a domain-specific subagent or skill (payments, infra, compliance) as the vertical slice—with CI or scenario evals as the vertical verification layer. The HR example below uses the same pattern in an enterprise ops context.
Horizontal Agents: Optimize for Breadth and Routing
A horizontal agent is general-purpose by design. Examples in the wild include Microsoft Copilot, Google Gemini for Workspace, Claude Code as a general coding harness, or an internal “company copilot” wired to Slack, docs, and ticket systems.
Horizontal agents excel when:
- the task categories vary week to week (research, drafts, summaries, light automation)
- regulatory exposure is moderate and human review is acceptable
- integrations are mostly standard SaaS (email, calendar, GitHub, Notion)
- time-to-value matters more than domain-perfect accuracy on day one
Anthropic’s production guidance treats routing and orchestrator-workers as first-class patterns here: classify the input, delegate to the right specialist prompt or subagent, synthesize the result. That is horizontal architecture in practice—even when the “workers” are just differently prompted instances of the same model.
What a horizontal loop must get right
Loop engineering for horizontal agents is mostly about not poisoning your own router:
| Loop primitive | Horizontal priority | Why |
|---|---|---|
| Stopping conditions | Strict iteration and budget caps | Wide tool access + vague goals → runaway loops |
| Context management | Aggressive compaction and subagent summaries | Breadth tasks accumulate noise fast |
| Verification | Lightweight checks (tests, linters, schema validation) | You cannot encode every domain rule centrally |
| Guardrails | Scoped credentials per tool | One over-powered token becomes a company-wide risk |
| Routing | Explicit classifier or supervisor | Without it, one prompt tries to be expert at everything |
Anthropic describes the core single-agent cycle as: receive task → plan → act with tools → observe → repeat until done or paused for human review. Horizontal systems add a supervisor layer on top when classification is reliable enough to trust.
Vertical Agents: Optimize for Depth, Policy, and Evidence
A vertical agent owns a narrow workflow inside a regulated or high-stakes domain: prior authorization, clinical note drafting, contract clause extraction, mortgage income verification, fraud disposition.
Production vertical agents converge on a similar anatomy whether the vendor sells to healthcare, legal, or finance (descriptions vary; components recur):
- Router / orchestrator inside the domain workflow
- Specialist models or prompts with supervisors
- Deterministic policy layer that retains final decision authority
- Domain schema adapter into the system of record
- Long-horizon state store (case files, not chat history)
- Human checkpoint router
- Regulator-replay audit trail
The recurring lesson from regulated deployments (summarized in industry writeups citing vendors like Abridge, Anterior, Sierra, and Harvey): the LLM is not the system. The harness is.
What a vertical loop must get right
Vertical loop engineering trades flexibility for provability:
| Loop primitive | Vertical priority | Why |
|---|---|---|
| Stopping conditions | Exit on policy pass/fail, not model confidence | Compliance needs binary gates |
| Context management | Structured case state outside the model | Auditors need replay, not summarization |
| Verification | Domain evaluators + human-in-the-loop | Generic “looks good” checks fail silently |
| Guardrails | Policy engine before side effects | The model proposes; code disposes |
| Routing | Workflow-state machine as much as LLM router | Next step depends on case status, not vibe |
An arXiv framework (May 2026) separates cognitive function (reasoning, action, governance) from execution topology (chain, route, loop, hierarchy). Vertical production systems often combine Route (triage) + Loop (iterative draft/review) + Hierarchy (supervisor specialists)—with Governance implemented outside the model.
Loop Engineering: Same Name, Different Emphasis
Loop engineering is the practice of designing the runtime around an agent—the schedule, tools, memory, verification, and stop rules—not hand-writing every turn. Addy Osmani named the practice in June 2026, building on Boris Cherny’s “my job is to write loops” framing and the convergence of Claude Code / Codex-style harnesses.
Osmani’s six primitives map cleanly onto both agent shapes:
| Primitive | Horizontal emphasis | Vertical emphasis |
|---|---|---|
| Automations | Inbox sweeps, dependency bots, triage cron | Case queue processors, SLA timers |
| Worktrees / isolation | Parallel repo tasks | Per-case sandboxes with PHI/legal walls |
| Skills | Repo conventions, team playbooks | Domain SOPs, coding systems, form schemas |
| Connectors (MCP) | GitHub, Slack, generic SaaS | System-of-record adapters (EHR, core banking) |
| Sub-agents | Research, test, review workers | Specialty reviewers (coding, policy, medical) |
| Durable state | NOTES.md, feature lists, boards | Case records + immutable audit log |
For coding-agent loops specifically, see Building a Senior-Engineer Agent—that article goes deep on orchestration, maker/checker splits, and auto-PR trust. This article stays at the product/architecture layer: choosing horizontal vs vertical before you tune the harness.
Horizontal loop (reference shape)
Trigger (schedule, webhook, user)
│
▼
┌──────────────┐ classify ┌─────────────────┐
│ Horizontal │ ────────────────► │ Route to worker │
│ supervisor │ │ prompt/subagent │
└──────┬───────┘ └────────┬────────┘
│ │
│ MCP tools (Git, docs, CI) │
▼ ▼
┌──────────────┐ verify (tests/lint) ┌──────────────┐
│ Act + observe│ ◄────────────────────── │ Loop until │
└──────┬───────┘ │ stop rule │
│ └──────────────┘
▼
Summarize to user / open PR / post Slack
Vertical loop (reference shape)
Case opened in system of record
│
▼
┌──────────────┐ deterministic ┌──────────────┐
│ Intake + │ ────────────────► │ Policy gate │
│ schema bind │ eligibility │ (allow/deny) │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
┌──────────────┐ draft/revise ┌──────────────┐
│ Vertical LLM │ ◄───────────────── │ Domain eval │
│ loop │ until pass │ + human HITL │
└──────┬───────┘ └──────────────┘
│
▼
Writeback + immutable audit event (who/what/when/evidence)
The vertical loop is slower by design. That is a feature when a wrong automation is expensive.
Hybrid Architecture: How Mature Teams Actually Ship
Enterprise guidance from Microsoft Copilot Studio, Google A2A, and Anthropic’s multi-agent patterns converges on a layered model:
- Horizontal entry point — user chat, copilot, or internal orchestrator
- Router / supervisor — classifies intent and risk
- Vertical workers — domain agents with their own loops and policy shells
- MCP — each worker reaches tools and systems of record
- A2A (optional) — cross-team or cross-vendor agents delegate without sharing internals
Google’s A2A protocol (announced April 9, 2025, donated to the Linux Foundation) exists precisely for this horizontal coordination layer: Agent Cards at /.well-known/agent-card.json, JSON-RPC over HTTPS, task/artifact models for long-running work. A2A explicitly complements MCP—MCP equips an agent with tools; A2A lets opaque agents collaborate.
Employee / customer
│
▼
┌─────────────────────┐
│ Horizontal copilot │ Loop: route + summarize + guard
└──────────┬──────────┘
│ A2A task: "process LOA case"
▼
┌─────────────────────┐ MCP ┌─────────────┐
│ Vertical LOA │ ─────────────────► │ Workday / │
│ case worker │ │ policy DB │
└──────────┬──────────┘ └─────────────┘
│ A2A result artifact
▼
Horizontal copilot explains outcome + links audit ID
PM read: You are not choosing Copilot or Harvey. You are choosing where the front door lives and which workflows earn a vertical runtime.
Engineer read: Keep vertical agents opaque to the horizontal router (A2A’s sweet spot). Do not leak PHI or privileged prompts through shared chat context.
Decision Framework
PM quick path: which shape first?
Can you name the eval, human checkpoint, and audit artifact upfront?
│
no ──► start horizontal (suggest-only, low write access)
│
yes
│
▼
Is failure cost high (legal, clinical, financial, safety)?
│
no ──► horizontal + strong verification may be enough
│
yes
│
▼
Do you need system-of-record writeback or regulated replay?
│
no ──► horizontal with gated tools + human approval
│
yes ──► vertical worker (buy or build) + Layer 1 loop contract
If the workflow is still exploratory, stay horizontal even when the domain sounds “serious.” Vertical investment pays off when the same case types repeat and you can scenario-test them. See When a Prompt Is Enough for AI Agents before adding loop complexity.
For PMs: which shape first?
| Signal | Favor horizontal | Favor vertical |
|---|---|---|
| Task diversity | High (many teams, many formats) | Low (one workflow, repeatable cases) |
| Error cost | Recoverable with human edit | Financial, legal, clinical, or safety impact |
| Regulation | Light / generic retention | HIPAA, SOC 2, PCI, industry-specific |
| Data moat | Public or generic docs | Proprietary corrections, outcomes, audit history |
| Integration | Standard SaaS | System-of-record schemas |
| Time to first value | Days–weeks | Months (worth it if ROI is case-closed, not chat-assisted) |
Practical default in 2026: deploy horizontal for productivity surfaces; add vertical agents only for workflows where you can name the eval, the human checkpoint, and the audit artifact upfront. Analyst forecasts (Gartner and others, early 2026) point to rapid growth in embedded, task-specific agents inside enterprise apps—mostly as vertical slices, not generic chat everywhere.
For engineers: loop checklist before production
Horizontal loop readiness
- Router accuracy measured on a labeled set (precision/recall per route)
- Max iterations, token budget, and wall-clock timeout configured
- Tool scopes least-privilege per route
- Subagent summaries capped (avoid parent context bloat)
- Verification hook for each route that mutates state
- Kill switch and spend cap (sandbox org, budget alarm)
Vertical loop readiness
- Policy engine can veto model actions before writeback
- Case state stored outside the model with version history
- Domain eval suite (scenario tests, not one happy path)
- Human checkpoint defined for escalation paths
- Immutable audit log (prompt hash, tool calls, outputs, approver)
- Replay procedure documented for regulators or internal review
If you cannot check the vertical list, you likely have a demo loop—not a production loop.
Template Layers: Five Artifacts, One Hybrid Loop
The examples below are not a single framework file. They are five layers you can adopt independently, using the same employee-benefits scenario throughout: a horizontal copilot routes FAQ questions and delegates leave-of-absence (LOA) requests to a vertical case worker.
Layer 1 Loop contract (PM) ──► what routes exist, what "done" means
Layer 2 Integration spec ──► how workers are invoked (brief or A2A)
Layer 3 Domain surface ──► what tools/data each worker may touch
Layer 4 Verification ──► how you prove the loop worked
Layer 5 Durable state ──► what survives between loop runs
PMs: start with Layer 1. You do not need YAML, Agent Cards, or eval files on day one. Fill the loop contract table in a doc or ticket, get engineering sign-off on stop rules and human gates, then add layers 2–5 as the workflow earns autonomy. If Layer 1 is vague (“handle HR questions”), every layer below it will drift.
Maturity ladder:
| Stage | Layers | Typical milestone |
|---|---|---|
| Explore | Layer 1 only | Named routes, owners, stop rules in a ticket |
| Pilot | Layers 1–2 | Subagent briefs or A2A card; suggest-only |
| Controlled write | Layers 1–3 | Domain surface + scoped MCP; no open write tools |
| Production vertical | Layers 1–5 | Scenario evals, durable case state, audit replay |
Layer 1 — Loop contract (PM one-pager)
Use a markdown table—or the equivalent fields in Jira/Linear—before anyone writes agent config. This is the spec horizontal and vertical owners align on.
| Field | Horizontal route (FAQ) | Vertical route (LOA) |
|---|---|---|
| Trigger | User chat in copilot | LOA intent classified OR case opened in Workday |
| Owner | Internal platform / IT | HR ops + compliance |
| Max iterations | 8 | 12 |
| Stop on | user_satisfied, budget_exceeded | policy_pass, human_required, policy_fail |
| Verify with | Response schema + required citations | OPA policy bundle + scenario evals |
| Human gate | None (suggest-only) | Borderline policy → HR specialist queue |
| Audit | Optional chat log | Immutable event log (case ID, policy version, approver) |
| Autonomy | Answer and link sources | Draft case; gated writeback only after approval |
| Escalation | ”I don’t know” → link to HR portal | human_required → pause loop, preserve case state |
Done when Layer 1 is ready: both routes have named owners, binary stop conditions, and an explicit “no automation” path.
Layer 2 — Integration spec (engineer)
Layer 2 answers how the horizontal supervisor invokes workers. Pick one or both patterns depending on deployment shape.
2a. In-process subagent brief (same harness—Claude Code, Cursor, internal orchestrator):
Use the six-field brief from Building a Senior-Engineer Agent. The horizontal supervisor emits this when routing to the vertical LOA worker:
ROLE: LOA case worker. Evaluate eligibility, draft case, escalate borderline outcomes.
You do not answer general HR policy questions.
CONTEXT:
- Policy bundle: opa_bundle_hr_loa v2026.06
- Employee record: read via workday_hr_readonly MCP
- Case writeback: workday_case_write MCP (LOA objects only)
GOAL: Produce a policy-checked LOA draft or escalate with evidence.
NON-GOALS:
- Do not modify payroll, termination, or benefits enrollment directly.
- Do not bypass human_required when policy_result is borderline.
- If eligibility is unclear, stop and queue hr_specialist_review.
TOOLS: workday_hr_readonly, workday_case_write (scoped), policy_check_loa.
No Slack, no generic web search.
DONE-WHEN:
- policy_result is pass AND draft case written, OR
- policy_result is borderline/fail AND human_required queued with audit event.
For the low-risk FAQ route, the same harness uses a shorter brief:
ROLE: HR handbook assistant. Answer general policy questions with citations only.
GOAL: Answer from handbook/FAQ sources, or escalate if the question needs employee-specific data.
NON-GOALS: Do not open LOA cases. Do not read employee records.
TOOLS: notion_handbook, slack_hr_faq (read-only).
DONE-WHEN: Answer includes ≥1 citation OR escalate_to_loa_route with reason.
2b. A2A Agent Card (vertical worker as a separate service):
When the LOA agent runs outside the copilot runtime, expose it via A2A. The horizontal copilot becomes an A2A client; the vertical agent publishes capabilities at /.well-known/agent-card.json:
{
"name": "loa-case-worker",
"description": "Processes leave-of-absence requests with policy checks, human escalation, and audit trail.",
"url": "https://hr-agents.example.com/a2a/v1",
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": false
},
"skills": [
{
"id": "process_loa_request",
"name": "Process LOA request",
"description": "Evaluate eligibility, draft case, escalate borderline cases to HR.",
"examples": [
"Employee requests 6-week medical leave starting July 1",
"Check FMLA eligibility for employee ID E-1042"
]
}
]
}
Rule of thumb: subagent briefs for teams building in one repo; Agent Cards when vertical agents are opaque, vendor-hosted, or owned by another team.
Layer 3 — Domain surface (vertical boundary)
Before wiring MCP servers, define what each worker may touch. This YAML is a security and product contract, not orchestration config—similar to the semantic-layer pattern in Preparing Databases for Secure AI Agents:
# domain-surface-loa.yaml — vertical worker boundary
domain: leave_of_absence
worker: vertical_loa_agent
allowed_actions:
- check_eligibility
- create_draft_case
- append_case_note
- request_human_review
blocked_actions:
- terminate_employee
- modify_payroll
- change_benefits_enrollment
- cross_employee_queries
mcp_servers:
- name: workday_hr_readonly
scopes: [hr.employee.read, hr.loa.read]
- name: workday_case_write
scopes: [hr.loa.draft] # not hr.loa.submit until human approves
approval_required:
- submit_case_to_workday
- writeback_final_decision
audit_fields:
- case_id
- policy_version
- inputs_hash
- tool_calls
- decision
- approver
The horizontal FAQ worker gets a lighter surface: read-only handbook MCP, no write tools, no case objects.
# domain-surface-faq.yaml — horizontal route boundary
domain: hr_faq
worker: hr_faq_worker
allowed_actions:
- search_handbook
- cite_source
- escalate_to_loa_route
blocked_actions:
- read_employee_record
- create_case
- any_write_to_workday
mcp_servers:
- name: notion_handbook
scopes: [hr.docs.read]
- name: slack_hr_faq
scopes: [hr.faq.read]
Layer 4 — Verification (earn autonomy)
Horizontal and vertical loops need different proof. Layer 4 is where “demo” becomes “production.”
Horizontal (FAQ): schema + citation checks—cheap, run every turn.
# verify-faq.yaml
route: hr_faq_worker
checks:
- type: json_schema
schema: hr_response_v2.json
- type: citation_required
sources: [notion_handbook, slack_hr_faq]
- type: refusal
when: question_requires_case_specific_data
action: escalate_to_loa_route
Vertical (LOA): scenario evals before rollout—see Testing AI Agent Skills with LangWatch Scenario for the full workflow.
# scenarios-loa.yaml
scenarios:
- name: eligible_medical_loa
input: { tenure_months: 14, reason: medical, duration_weeks: 6 }
expect: { policy_result: pass, human_required: false }
- name: borderline_tenure
input: { tenure_months: 11, reason: medical, duration_weeks: 12 }
expect: { policy_result: borderline, human_required: true }
- name: ineligible_short_tenure
input: { tenure_months: 2, reason: personal, duration_weeks: 4 }
expect: { policy_result: fail, human_required: false }
Run scenario suites on every policy-bundle change. Horizontal routes can lean on spot checks; vertical routes should not ship without eval coverage on escalation paths.
Layer 5 — Durable state (memory outside the model)
Models forget between runs. Vertical case work especially must not live only in chat history. Persist state the next loop iteration (or the human reviewer) can reload:
{
"case_id": "loa-2026-0142",
"route": "vertical_loa_agent",
"status": "awaiting_human_review",
"attempts": 2,
"policy_version": "opa_bundle_hr_loa@2026.06",
"policy_result": "borderline",
"open_questions": [
"FMLA overlap with existing PTO balance"
],
"last_tool_calls": ["check_eligibility", "create_draft_case"],
"human_queue": "hr_specialist_review",
"last_verified_at": "2026-06-25T14:30:00Z"
}
Horizontal FAQ turns can stay ephemeral. Once a user crosses into LOA, promote the conversation into case state (Layer 5) and hand off to the vertical loop.
How the layers connect
User: "I need 6 weeks medical leave"
│
▼
[Layer 1] Router picks LOA route (not FAQ)
│
▼
[Layer 2] Supervisor delegates via subagent brief OR A2A task
│
▼
[Layer 3] LOA worker sees only allowed_actions + scoped MCP
│
▼
[Layer 4] policy_check → scenario eval on CI; borderline → human gate
│
▼
[Layer 5] case JSON persisted; loop pauses until HR approves writeback
│
▼
Horizontal copilot summarizes outcome + audit ID for the employee
Design choices this stack makes explicit:
- The horizontal layer owns routing, user-facing summary, and cheap FAQ paths.
- The vertical layer owns domain surface, policy, human escalation, audit, and durable case state.
- Verification differs by route—do not reuse one test harness for both.
- PMs gate Layer 1; engineers implement 2–5 incrementally as trust grows.
For delegation inside a single coding harness, also see When to Use Subagents vs the Main Chat Thread.
Risks and Honest Limits
- Horizontal agents overreach. A capable router still hallucinates classification labels. Measure routing accuracy before automating write actions.
- Vertical agents ossify slowly. Domain adapters and policy bundles are expensive. Buying vertical SaaS vs building is a portfolio decision, not a purity test.
- Protocol soup. MCP plus A2A plus vendor-native orchestration can duplicate governance if you lack a control plane. IBM’s agent-sprawl guidance (2026) notes that most large enterprises already run agents in some capacity, yet many lack a complete inventory—sprawl raises security and integration risk as teams deploy faster than they govern.
- Loop expressiveness vs control. Research on agent execution (April–May 2026) notes that unconstrained agent loops hide dependencies and retry forever; graph-harness approaches trade flexibility for inspectability. High-stakes vertical workflows often benefit from more explicit structure than a single opaque loop.
- Template layer creep. Adding Layers 2–5 before Layer 1 is stable produces pretty YAML and flaky production behavior. Keep FAQ routes at Layers 1–2 until routing accuracy is measured.
- Convergence is real but uneven. Horizontal platforms add industry modules (Copilot for Finance, Gemini healthcare features). That can delay vertical vendor spend—but rarely removes the need for proprietary eval data in your environment.
Editorial and Source Notes
This article deliberately avoids vendor revenue claims (ARR, valuation multiples) unless tied to architectural evidence. Market numbers from secondary blogs are omitted when they do not change design decisions.
Distinct from other devlog posts in this repo:
- Senior-engineer agent — coding orchestration and auto-PR trust
- Subagents vs main thread — delegation inside one harness
- When a prompt is enough — when loop complexity is premature
- Preparing databases for secure AI agents — domain surface and tool authorization depth
- Testing AI agent skills with LangWatch Scenario — Layer 4 scenario evals in practice
- Leading agentic systems sandbox → beta — product graduation gates
Sources
Primary and strong secondary sources supporting the main claims:
- Anthropic: Building Effective Agents — routing, orchestrator-workers, when to add agentic complexity; single-agent perceive-act loop with stopping conditions.
- Anthropic: Building Effective AI Agents (PDF) — hierarchical supervisor patterns, financial-services vertical spotlight, multi-agent economics.
- Anthropic: Building agents with the Claude Agent SDK — gather context → act → verify loop; subagents for parallelization and context isolation.
- Google A2A Protocol — agent-to-agent interoperability; complementary role vs MCP; Linux Foundation stewardship.
- A2A GitHub repository — Agent Cards, JSON-RPC transport, task model; originally contributed by Google.
- Google for Developers: Announcing the Agent2Agent Protocol (A2A) — April 9, 2025 launch context.
- Microsoft Learn: Multi-agent patterns for Copilot Studio — MCP for tools, A2A for cross-platform agent messaging; orchestration vs opaque agent internals.
- Model Context Protocol — agent-to-tool integration standard.
- Addy Osmani: Loop Engineering — June 2026 naming of loop engineering; automations, worktrees, skills, connectors, sub-agents, durable state.
- A Two-Dimensional Framework for AI Agent Design Patterns (arXiv, May 2026) — cognitive function × execution topology (chain, route, loop, hierarchy).
- From Agent Loops to Structured Graphs (arXiv, April 2026) — limits of opaque agent loops; controllability tradeoffs.
- The Anatomy of a Production Vertical Agent (The AI Runtime, 2026) — seven-component regulated vertical pattern; LLM as smallest part (industry analysis citing production vendors).
- IBM: What is AI Agent Sprawl? — governance gaps, inventory challenges, and sprawl risk as agent deployment democratizes.
Judgment, not vendor fact: The hybrid “horizontal front door + vertical workers” default reflects converging guidance from Anthropic routing patterns, Microsoft multi-agent architecture docs, and A2A/MCP complementarity—it is a design recommendation for readers planning 2026 deployments, not a statement that every enterprise has already implemented it.