# Horizontal vs vertical AI agents is the wrong question > Scope is only one of five design choices for enterprise agents. How to decide ownership, execution authority, mechanism and architecture, with the governance that makes them safe. Source: https://aibyos.com/blog/horizontal-vs-vertical-ai-agents-is-the-wrong-question AI Agents · Architecture · Governance · Enterprise AI · Strategy # Horizontal vs vertical AI agents is the wrong question Scope is only one of five design choices for enterprise agents. How to decide ownership, execution authority, mechanism and architecture, with the governance that makes them safe. AIBYOS · 20 September 2026 · 9 min read Most enterprise AI conversations still start with the same question: _"Do we need a horizontal agent or a vertical one?"_ Some teams add a third option: _"Or should we let citizen developers build their own?"_ It sounds like a strategic choice. It isn't. Horizontal versus vertical only describes **where an agent operates**. It says nothing about who should build and own it, how much it should be allowed to do on its own, whether the work needs an agent at all, or how the system should be put together. Those are separate decisions. Forcing them into one label produces the wrong requirements and, eventually, the wrong systems. Gartner expects [more than 40% of agentic AI projects to be cancelled by the end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), citing rising costs, unclear business value and inadequate risk controls. Getting these decisions right up front is how you stay out of that 40%. The better question is: **where should specialisation, ownership, control and execution authority live?** ## The five axes that actually matter ### 1\. Scope: from horizontal to vertical **Horizontal** systems optimise for breadth: many kinds of tasks across many domains, using general capabilities. **Vertical** systems optimise for depth: they are designed around specific domain knowledge, workflows, systems of record, policies and definitions of success. When a horizontal system falls short, the cause is rarely the model's raw intelligence. It is usually missing context, shallow integrations, unclear authorisation boundaries, generic workflows and no one accountable for the outcome. Vertical systems solve those problems by design. ### 2\. Ownership: from central engineering to domain users Who builds the system, maintains it and answers for it? Owner Brings Watch out for Central engineering Engineering rigour, consistency, platform control Distance from the work; long queues Domain engineering Process knowledge plus technical ownership Duplicated effort across domains Domain users (citizen developers) Speed and proximity to the work Shadow automation without guardrails Builder and owner are not always the same person. A domain expert can create a workflow in a low-code or natural-language builder while the platform team still owns deployment, authentication, connectors, policies, monitoring and lifecycle. Citizen development is one way to involve the domain. It doesn't have to mean full technical ownership. ### 3\. Execution authority: from recommend to fully autonomous Level The system may... Recommend Suggest; a person does everything Execute with approval Prepare the action; a person or a rule approves it Execute within policy Act on its own inside hard limits (amounts, systems, data) Fully autonomous Act without routine approval For enterprise risk, this axis matters more than scope. A very capable system that can only recommend is far less risky than a simple one that can change records in your ERP. OWASP lists [Excessive Agency](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/2_0_vulns/LLM06_ExcessiveAgency.md) among the top ten risks for LLM applications and traces it to three root causes: too much functionality, too many permissions and too much autonomy. Its central mitigation is to enforce authorisation in the downstream systems themselves, not to trust the model to decide what it is allowed to do. ### 4\. Mechanism: deterministic workflow or agentic reasoning Not every "agentic" use case needs an autonomous agent. Anthropic's widely cited [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) draws the line clearly: **workflows** orchestrate models and tools through predefined code paths, while **agents** direct their own process and tool use. Its advice is to find the simplest solution that works and add complexity only when needed. If the sequence, rules and permitted actions are known in advance, a deterministic workflow with a model inside individual steps is usually safer, cheaper and far easier to evaluate. Use agentic reasoning where the problem genuinely needs dynamic interpretation, planning or tool choice. With "agent" now used as a marketing umbrella (Gartner calls it "agent washing"), it pays to ask which mechanism is really underneath. ### 5\. Architecture: from one agent to many Single agent or workflow → orchestrated specialists → multi-agent collaboration. More agents is not automatically better. Each additional agent adds coordination, latency, observability, evaluation and failure-mode complexity. OpenAI's [practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/) makes the same recommendation: get the most out of a single agent first, and move to a manager-with-specialists or hand-off pattern only when the complexity demands it. Add specialists when specialisation or isolation brings a concrete benefit, such as separate permissions, separate data or independent evaluation. **Any enterprise system can sit at any combination of these five axes.** That's the point. ## What this looks like in practice ### Customer support A customer complains about a delayed shipment and a billing discrepancy. A purely horizontal assistant can draft a polite reply. That is rarely enough. A realistic flow looks like this: ```text Customer request | v General interaction / orchestration layer | +---------------------+----------------------+ v v v Retrieve customer Retrieve contract, Classify complaint and order history SLA and billing data type and severity | | | +---------------------+----------------------+ v Domain logic + policy checks v Draft reply + proposed actions v Approval gate (person or automated rules) v Update CRM and ticketing, notify the carrier ``` Specialisation lives in the retrieval tools, the domain logic and the action constraints. The entry point doesn't need to be an autonomous agent: it can be a model-based router, a workflow engine or plain deterministic routing. The system becomes vertical exactly where the work demands it. ### Finance A horizontal research assistant helps an analyst explore data. Invoice reconciliation is different: it needs access to specific systems, deterministic validation rules, audit trails and clear approval limits. A reporting tool built by the finance team itself can sit in between: owned by the people who understand the numbers, and constrained by the platform team's identity, data and action boundaries. ### Marketing A horizontal research capability helps with competitive intelligence. A campaign-performance system is built around your own metrics, ad platforms and attribution rules. A marketer can build lighter content or workflow automations in a governed environment without waiting in a central queue, while the platform team keeps control of connectors, policies and monitoring. ### The same three systems, described properly Support resolution Invoice reconciliation Campaign reporting Scope Horizontal entry, vertical capabilities Vertical Vertical, domain-specific Ownership Central platform + support engineering Central or finance engineering Marketing team, on the central platform Execution authority Execute with approval Execute within policy (tolerances, amounts) Recommend Mechanism Workflow with agentic classification and drafting Deterministic workflow, model for matching exceptions Agentic analysis on governed data Architecture Orchestrator + specialist tools Single workflow Single agent Each row is a deliberate design decision. None of them is captured by the words "horizontal" or "vertical". ## A practical decision framework Instead of picking a label, answer these questions: Question What it pushes towards Many unrelated or exploratory tasks? Broader, more horizontal scope Deep domain knowledge, rules or systems of record needed? Narrower, more vertical specialisation Complex integrations or high engineering effort? Central or domain engineering involvement Domain experts understand the workflow best, and it changes often? Domain ownership, with platform support High consequences if the system is wrong? Stronger controls, lower execution authority Sequence and rules known in advance? Deterministic workflow where possible Dynamic interpretation, planning or tool choice required? Agentic reasoning Several distinct specialist capabilities, with a clear isolation benefit? Orchestrated specialists Long-running, multi-step execution? Explicit architecture, observability and approval design This produces much clearer requirements than "we need a vertical agent". ## Governance cuts across every axis Governance is not a soft add-on. It is the operating model that makes all the other choices safe. Every enterprise agent system needs at least five boundaries: 1. **Identity.** Which user or service identity does the system act as, and whose permissions does it inherit? 2. **Data.** Which sources can it read, under which identity, with what filtering? 3. **Actions.** Which tools and write operations can it call, and under what conditions? 4. **Approvals.** Which kinds of action need human review, dual control or automated policy checks? 5. **Observability.** Logs, evaluations, cost tracking and audit trails, so someone can understand what happened and improve it. Without these, domain and citizen involvement turns into shadow automation. With them, the people closest to the work can safely own more of the lifecycle while the platform protects the organisation. For high-risk use cases in the EU, these boundaries are also how you show the [human oversight required by Article 14 of the EU AI Act](https://artificialintelligenceact.eu/article/14/). ## Putting it together Mature deployments rarely pick one pure category. They combine: - a fairly general interaction or orchestration layer (the horizontal surface); - specialised knowledge, tools and logic where the work demands it (the vertical depth); - ownership with the people best placed to maintain each workflow, backed by central platform controls; - an explicit decision about execution authority, per action rather than per system; - a deliberate choice between deterministic workflow and agentic reasoning; - additional agents only where specialisation or isolation brings a concrete benefit; - concrete identity, data, action, approval and observability boundaries. Before building, answer six questions: 1. How specialised is the work? 2. How much execution authority is acceptable, given the risk? 3. Who should own the workflow and keep improving it? 4. Does the problem need agentic reasoning, or is a deterministic workflow safer? 5. Which systems and data must it be able to read and change? 6. What happens, and who is accountable, when it gets something wrong? Answer those clearly and the right combination of scope, ownership, authority, mechanism, architecture and governance usually becomes obvious. The label is the least important part. ## Frequently asked questions What is the difference between a horizontal and a vertical AI agent? A horizontal agent handles many kinds of tasks across domains with general capabilities; a vertical agent is built around one domain's knowledge, workflows, systems and policies. In practice, most enterprise systems combine a horizontal entry point with vertical capabilities where the work demands depth. When should we use a workflow instead of an AI agent? When the sequence of steps, the rules and the permitted actions are known in advance. A deterministic workflow with a model inside individual steps is easier to test, audit and control. Use agentic reasoning only where the task genuinely needs dynamic planning or tool selection. Should citizen developers build AI agents? They can build and own workflows close to their work, provided the platform team owns identity, connectors, data access, action limits, monitoring and lifecycle. Builder and owner don't have to be the same, and governance is what keeps citizen development from becoming shadow automation. Is a multi-agent system better than a single agent? Not automatically. Each extra agent adds coordination, latency, evaluation and failure modes. Start with one agent or workflow and add specialists only when separate permissions, data or evaluation bring a concrete benefit. ## How we can help We help enterprises design agent systems around these five axes: mapping use cases to the right scope, ownership model and execution authority, choosing workflow or agent per step, and building the identity, data, action, approval and observability boundaries on a shared platform. A typical starting point is a two to three week [Architecture Sprint](https://aibyos.com/how-we-work) that ends with a target architecture and an operating model your domain teams can build on. Related: [AI Agents & Agentic Workflows](https://aibyos.com/services/agents) · [Agent Infrastructure & Runtime](https://aibyos.com/services/agent-infra) · [AI Gateways & Model Routing](https://aibyos.com/services/gateway) · [AI Governance & EU AI Act](https://aibyos.com/services/governance) Deciding what to build first? [Book a consultation](https://aibyos.com/contact). ## Sources - Anthropic: [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) - OpenAI: [A practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/) - Gartner: [Over 40% of agentic AI projects will be canceled by end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) - OWASP: [LLM06:2025 Excessive Agency](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/2_0_vulns/LLM06_ExcessiveAgency.md) - EU AI Act: [Article 14, Human oversight](https://artificialintelligenceact.eu/article/14/) [← All articles](https://aibyos.com/blog/)