Modern Agent Engineering

Horizontal Agents vs Vertical Agents: Designing Loop Engineering

A practical guide for engineers and PMs on when to build general-purpose horizontal agents, when to invest in domain-specific vertical agents, and how loop engineering differs for each—including hybrid architectures that route across both.

21 min read

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.

VocabularyHorizontal meansVertical means
Product / marketGeneral-purpose agent across departments and tasksDomain-specific agent for one industry or workflow
Integration / protocolsAgent-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 primitiveHorizontal priorityWhy
Stopping conditionsStrict iteration and budget capsWide tool access + vague goals → runaway loops
Context managementAggressive compaction and subagent summariesBreadth tasks accumulate noise fast
VerificationLightweight checks (tests, linters, schema validation)You cannot encode every domain rule centrally
GuardrailsScoped credentials per toolOne over-powered token becomes a company-wide risk
RoutingExplicit classifier or supervisorWithout 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):

  1. Router / orchestrator inside the domain workflow
  2. Specialist models or prompts with supervisors
  3. Deterministic policy layer that retains final decision authority
  4. Domain schema adapter into the system of record
  5. Long-horizon state store (case files, not chat history)
  6. Human checkpoint router
  7. 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 primitiveVertical priorityWhy
Stopping conditionsExit on policy pass/fail, not model confidenceCompliance needs binary gates
Context managementStructured case state outside the modelAuditors need replay, not summarization
VerificationDomain evaluators + human-in-the-loopGeneric “looks good” checks fail silently
GuardrailsPolicy engine before side effectsThe model proposes; code disposes
RoutingWorkflow-state machine as much as LLM routerNext 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:

PrimitiveHorizontal emphasisVertical emphasis
AutomationsInbox sweeps, dependency bots, triage cronCase queue processors, SLA timers
Worktrees / isolationParallel repo tasksPer-case sandboxes with PHI/legal walls
SkillsRepo conventions, team playbooksDomain SOPs, coding systems, form schemas
Connectors (MCP)GitHub, Slack, generic SaaSSystem-of-record adapters (EHR, core banking)
Sub-agentsResearch, test, review workersSpecialty reviewers (coding, policy, medical)
Durable stateNOTES.md, feature lists, boardsCase 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:

  1. Horizontal entry point — user chat, copilot, or internal orchestrator
  2. Router / supervisor — classifies intent and risk
  3. Vertical workers — domain agents with their own loops and policy shells
  4. MCP — each worker reaches tools and systems of record
  5. 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?

SignalFavor horizontalFavor vertical
Task diversityHigh (many teams, many formats)Low (one workflow, repeatable cases)
Error costRecoverable with human editFinancial, legal, clinical, or safety impact
RegulationLight / generic retentionHIPAA, SOC 2, PCI, industry-specific
Data moatPublic or generic docsProprietary corrections, outcomes, audit history
IntegrationStandard SaaSSystem-of-record schemas
Time to first valueDays–weeksMonths (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:

StageLayersTypical milestone
ExploreLayer 1 onlyNamed routes, owners, stop rules in a ticket
PilotLayers 1–2Subagent briefs or A2A card; suggest-only
Controlled writeLayers 1–3Domain surface + scoped MCP; no open write tools
Production verticalLayers 1–5Scenario 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.

FieldHorizontal route (FAQ)Vertical route (LOA)
TriggerUser chat in copilotLOA intent classified OR case opened in Workday
OwnerInternal platform / ITHR ops + compliance
Max iterations812
Stop onuser_satisfied, budget_exceededpolicy_pass, human_required, policy_fail
Verify withResponse schema + required citationsOPA policy bundle + scenario evals
Human gateNone (suggest-only)Borderline policy → HR specialist queue
AuditOptional chat logImmutable event log (case ID, policy version, approver)
AutonomyAnswer and link sourcesDraft case; gated writeback only after approval
Escalation”I don’t know” → link to HR portalhuman_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:

Sources

Primary and strong secondary sources supporting the main claims:

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.