AbejaIT AbejaIT
AI Solutions 27.10.2026 15 min read

Enterprise AI Agent Architecture: When One Agent Is Enough — and Subagents Hurt

AbejaIT Engineering Team · Architecture & Cybersecurity Practice · Since 2003
Enterprise AI Agent Architecture: When One Agent Is Enough — and Subagents Hurt
Executive Summary

Anthropic's latest engineering guide challenges the "more subagents = more power" assumption: a single main loop with tool search often outperforms sprawling multi-agent pipelines. For B2B organizations deploying AI, this means lower operational costs, fewer failure points, and faster ROI. Learn how to architect enterprise AI agents the right way.

1. Market Context and Business Framework (Executive Summary)

October 2024 brought a critical signal from Anthropic — the creators of Claude — that should land on the desk of every CTO and IT architect responsible for enterprise AI deployments. Their engineering guide titled "When to fold subagents into your main agent loop" dismantles one of the most persistent myths of the AI agent era: that more specialized subagents automatically mean a more powerful and scalable system.

The engineering reality is far more nuanced. Over the past two years, the AI agent market has exploded. Organizations — often driven by competitive pressure and vendor marketing narratives — have built sprawling subagent networks: one agent collects data, another analyzes it, a third generates reports, a fourth decides next steps. The result? Systems that are difficult to debug, expensive to maintain, prone to cascading failures, and far less predictable than assumed at design time.

For boards and business owners who have invested or are planning to invest in AI, this signal carries concrete strategic implications:

  • Operational costs: every additional subagent means additional tokens, API calls, latency, and the risk of errors propagating through the entire pipeline.
  • Reliability: complex agent graphs have exponentially more failure points than a single, well-designed main loop with tools.
  • Compliance and auditability: in regulated environments (GDPR, NIS2, KSeF), every unexpected agent output must be traceable — which is nearly impossible with deep subagent hierarchies.
  • ROI: simplifying architecture shortens deployment time, reduces infrastructure costs, and accelerates the moment of achieving real business value.

At AbejaIT, we've been designing systems that must operate reliably in mission-critical environments since 2003 — scrap metal yards, coal depots, allotment gardens, ERP systems. AI deployments are not an experiment for us — they are an engineering task that must deliver measurable results. That's why the "simplify first" approach is in our DNA.

2. Deep Technical Analysis and Risk Vectors

Before moving to the recommended architecture, it's important to understand why sprawling subagent networks are so tempting — and why they consistently underperform in practice.

The Myth of Scalability Through Specialization

Intuition suggests that dividing work among specialized agents should work the same way as human teams: one specialist for finance, another for logistics, a third for customer support. The problem is that language models (LLMs) don't work like humans. Every subagent call means a new context, new token cost, and — critically — the risk of contextual coherence loss between calls.

In practice, subagent B may make a decision that contradicts what subagent A established, because it lacks access to the full conversation context. The result: errors that are difficult to catch in testing but catastrophic in production.

Risk Vectors in Multi-Agent Architectures

  • Prompt injection between agents: malicious input data can be passed through the agent pipeline, escalating permissions or changing task intent. This is a serious attack vector in B2B systems processing external data.
  • Token bloat and hidden costs: every agent call generates costs. With 10 subagents handling one request, the cost may be 5–20× higher than with a single well-designed agent with tools.
  • Cascading latency: sequential subagent calls sum up delays. In real-time systems (e.g., integrations with weighbridges, ERP systems), latency above 2–3 seconds is unacceptable from a business perspective.
  • Lack of determinism: multi-agent systems are inherently non-deterministic. For systems requiring audit trails (e.g., financial transactions, tax documents), this is a serious regulatory risk.
  • Debugging difficulty: when a multi-agent system returns an incorrect result, identifying the cause requires analyzing every node in the graph — extremely expensive for production systems running 24/7.
  • Risk of loops and deadlocks: agents can wait on each other or call each other recursively, leading to complete system stalls.

Anthropic's Key Finding: Over 80% System Prompt Reduction in Claude Code

One of the most telling examples from Anthropic's guide is the revelation that they reduced Claude Code's system prompt by over 80% — without loss of functionality, and with gains in reliability and predictability. This is not a cosmetic change. It is a fundamental revision of thinking about how a model should understand its task. Instead of instructing every possible edge case through dedicated subagents, a single well-calibrated context with dynamic tool access is sufficient.

3. Solution Architecture and Step-by-Step Implementation Guide

Below we present a reference AI agent architecture for B2B environments, aligned with Anthropic's recommendations and validated in practice by AbejaIT engineers.

Principle #1: One Model, One Context Window, One Main Loop

The default architecture should be based on a single LLM (e.g., Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro) operating within a single continuous context window. Subagents should only be introduced when there is a proven need for parallelism or security isolation — not as the default design pattern.

Principle #2: Tool Search Instead of Specialized Subagents

Instead of creating a separate agent for each function (database agent, email agent, reporting agent), the model should have access to a tool registry and dynamically select the appropriate ones in context. This is the RAG (Retrieval-Augmented Generation) approach applied to the tools themselves — the agent "searches" for the right tool just as it searches for the right document fragment.

# Example tool registry configuration in Python
tools = [
    {
        "name": "query_erp_database",
        "description": "Query ERP system for inventory status, invoices, or accounts",
        "parameters": {"query": "string", "module": "enum[warehouse, invoices, crm]"}
    },
    {
        "name": "send_notification",
        "description": "Send email or SMS notification to a user or business partner",
        "parameters": {"recipient": "string", "message": "string", "channel": "enum[email, sms]"}
    },
    {
        "name": "generate_document",
        "description": "Generate PDF document (invoice, delivery note, report) from data",
        "parameters": {"template": "string", "data": "object"}
    },
    {
        "name": "search_bdo_registry",
        "description": "Check contractor's BDO waste registry number",
        "parameters": {"nip": "string"}
    }
]

# The agent decides which tools to use based on context
# No separate subagents needed for each function

Principle #3: Skills as Organized Prompt Blocks

Instead of delegating to a subagent, define skills — predefined instruction blocks that the agent activates based on context. A skill is not a separate model — it is a prompt fragment loaded dynamically into the main agent's context window.

# Example skills structure in YAML configuration
skills:
  - name: "invoice_analysis"
    trigger: "invoice|VAT|KSeF|payment"
    context_injection: |
      You are analyzing invoice data in the context of Polish tax regulations.
      Check: VAT number, VAT rates, payment terms, KSeF compliance.
      Flag split payment requirement for transactions above PLN 15,000.

  - name: "scrap_yard_analysis"
    trigger: "scrap|raw_material|BDO|waste|KPO"
    context_injection: |
      You are analyzing data in the context of secondary raw material procurement.
      Check: BDO number, cash payment limits (Polish payment restriction law),
      requirements for KPO/KPOk cards, FPO forms.

Principle #4: When Subagents Are Justified

Subagents make sense only in specific scenarios:

  • True parallelism: 50 independent tasks must be executed simultaneously with results collected (fan-out/fan-in pattern).
  • Security isolation: an agent processing data from external, untrusted sources should run in an isolated sandbox — without access to internal systems.
  • Context window overflow: a task requires processing data exceeding the token limit of a single call.
  • Specialized models: e.g., a vision model for OCR + a language model for analysis — different modalities require different models.

Infrastructure for AI Agents in B2B Environments

Reference infrastructure architecture for a production AI agent in a business context:

# Docker Compose – minimal production AI agent architecture
version: '3.9'
services:
  agent-api:
    image: abejait/agent-api:latest
    environment:
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DATABASE_URL=postgresql://agent:${DB_PASS}@postgres:5432/agentdb
      - REDIS_URL=redis://redis:6379
    ports:
      - "8080:8080"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  postgres:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: agentdb
      POSTGRES_USER: agent
      POSTGRES_PASSWORD: ${DB_PASS}

  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
    volumes:
      - redisdata:/data

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/ssl/certs:ro

volumes:
  pgdata:
  redisdata:

4. Engineering Implementation and Audit Checklist

  • ☑ Audit existing architecture: inventory all subagents — for each, answer: "Does this subagent need to be a separate model, or can it be a tool or skill in the main agent?"
  • ☑ Token cost measurement: measure the exact cost of each agent call in production (inputs + outputs) — many organizations discover that 60–80% of costs come from inter-agent communication overhead, not the actual task.
  • ☑ Latency benchmark: measure end-to-end latency of the current system and compare it with a single-loop architecture on the same test task.
  • ☑ Prompt injection test: conduct security tests — check whether data from external sources (e.g., email content, customer documents) can modify agent behavior or escalate its permissions.
  • ☑ Determinism validation: for critical business paths (invoice generation, access to financial data), verify whether the agent always produces the same result for the same input (or whether deviations are acceptable).
  • ☑ Configure limits and circuit breakers: every tool call must have a timeout, retry policy, and fallback — never trust an external API without a resilience mechanism.
  • ☑ Logging and audit trail: every agent decision must be logged (timestamp, input, selected tool, output) — a GDPR and NIS2 requirement for systems processing personal or business-critical data.
  • ☑ Regression tests after every prompt change: prepare at least 20 test cases (golden dataset) and run them automatically with every system prompt modification.
  • ☑ Real-time API cost monitoring: set alerts for cost anomalies — a sudden spike in token consumption may indicate an infinite loop or a prompt injection attack.
  • ☑ Disaster Recovery plan for the agent: what happens when the LLM provider's API is unavailable? Does the system gracefully degrade to an alternative model or manual mode?
  • ☑ Tool permission review: principle of least privilege — the agent should only have access to tools and data necessary for the specific task, not the entire system.
  • ☑ Architecture documentation: data flow diagram (DFD) and sequence diagram for each agent path — required for security audits and NIS2-compliant deployments.

5. Legal, Tax and Regulatory Compliance Requirements

Deploying AI agents in a B2B environment in Poland and the EU comes with specific regulatory requirements that system architects must consider from the design stage.

EU AI Act (Regulation EU 2024/1689)

The European AI Regulation, which entered into force on August 1, 2024, classifies AI systems by risk level. AI agents automating business decisions (e.g., assessing counterparty creditworthiness, automatic BDO verification, HR decisions) may be classified as high-risk systems, imposing obligations: technical documentation, registration in the EU database, algorithmic transparency, and human oversight of decisions.

GDPR and Personal Data Processing by AI Agents

An AI agent processing personal data of contractors, employees, or clients is a data processor under GDPR. Requirements:

  • The Record of Processing Activities (RPA) must include AI-based processing.
  • Personal data cannot be sent to external AI models without an appropriate legal basis and a Data Processing Agreement (DPA) with the provider.
  • For locally hosted models (private inference) — a Data Protection Impact Assessment (DPIA) is required when processing sensitive data.

NIS2 Directive and DORA

For entities covered by NIS2 (operators of essential services, digital service providers), deploying AI agents in critical processes requires:

  • AI supply chain security risk assessment (including risks from model providers).
  • Business continuity plans accounting for unavailability of external LLM APIs.
  • Reporting AI-related security incidents within 24/72 hours.

KSeF and AI-Automated Invoicing

AI agents integrating with the Polish National e-Invoice System (KSeF) must meet the technical requirements of the Ministry of Finance: XML schema FA(2)/FA(3), qualified signatures or KSeF API tokens, JPK_V7 compliance. Every invoice automatically issued by an AI agent is subject to the same requirements as a manually issued invoice — an agent error is not a mitigating circumstance during a tax audit.

6. Total Cost of Ownership (TCO) vs Return on Investment (ROI)

The decision to simplify AI agent architecture has direct financial implications. Below is an approximate analysis for a typical SME deploying AI to automate document processes.

Complex Multi-Agent Architecture Costs (Scenario A)

  • 5 subagents handling 1,000 requests/day: average 8,000 tokens per request × 5 calls = 40,000 tokens/request
  • Cost: ~$0.12/request × 1,000 = $120/day (~$3,600/month)
  • Additional costs: debugging failures (5h/week × senior developer rate), 8–15s latency (negative UX), difficulty implementing changes
  • Estimated annual TCO: ~€15,000–20,000 (API + maintenance + incidents)

Simplified Single-Loop Architecture Costs (Scenario B)

  • 1 main agent + tool search: average 6,000 tokens/request (no inter-agent communication overhead)
  • Cost: ~$0.018/request × 1,000 = $18/day (~$540/month)
  • Debugging cost reduction: 80% (simpler stack = easier diagnostics)
  • Estimated annual TCO: ~€3,000–5,000

ROI from Architecture Simplification

Annual savings: €10,000–15,000+ at the same request volume. Additionally: faster implementation of new features (refactoring tools vs. building new subagents), higher reliability (fewer P1 incidents), easier compliance with audit requirements.

AbejaIT Conclusion: Simplifying AI agent architecture by 80% in complexity can reduce operational costs by 50–85% with the same or higher quality results. This is one of the best optimization investments available today for companies deploying AI.

7. Frequently Asked Questions (FAQ)

Can a single AI agent handle all company processes?

No — and that's not the point of the "single main loop" approach. One agent should be responsible for one coherent process or domain (e.g., handling incoming documents, supporting sales teams, analyzing warehouse data). For different processes, it makes sense to have separate, specialized agent configurations — but each should be as simple as possible internally. The key distinction: separation at the configuration and domain level, not at the model and subagent level within a single flow.

How do you securely connect an AI agent to internal ERP systems or databases?

The recommended architecture: the agent never connects directly to a database — instead, it calls dedicated API microservices with granular permissions (principle of least privilege). Each agent tool is a separate API endpoint with its own authentication (API key or OAuth2), rate limiting, and logging. Never put database connection strings in agent system prompts — this is one of the most serious security mistakes in AI systems.

How do you measure AI agent effectiveness and when should you switch architectures?

Key metrics: success rate (% of tasks completed correctly without human intervention), cost per task (tokens × price), end-to-end latency, false positive rate (% of incorrect results requiring correction), and error escalation rate (% of tasks requiring human intervention). If success rate drops below 90% or cost per task grows exponentially with task complexity — it's a signal that the architecture needs revision. For most B2B applications: benchmark targets are <3s latency, >95% success rate, cost <$0.05/task.

Can an AI agent be deployed with full data privacy — without sending data to external cloud services?

Yes — and in many regulated industries (finance, healthcare, employee personal data), this is an absolute requirement. Available solutions: private instances of open-source models (Llama 3, Mistral, Qwen) hosted on own infrastructure or in a private cloud, fine-tuning models on company data without sending it to the provider, and RAG architecture with a local vector database (Qdrant, Milvus, pgvector). AbejaIT offers deployments of private AI model instances on managed infrastructure in Poland, eliminating the risk of data transfer outside EU jurisdiction.

8. Dedicated Solutions and Deployment in the AbejaIT Ecosystem

At AbejaIT, we have been building systems for demanding business environments for over 23 years. Our approach to AI is pragmatic: we deploy what works reliably and delivers measurable return on investment — not what's trending. The agent design principles described in this article (single main loop, tool search, skills) are applied in our own deployments and in client projects.

If your company uses our industry-specific systems, AI integration capabilities are ready to activate:

  • For scrap metal and secondary raw material buyers — the ESSW system (zlom.io) with automatic BDO verification, KPO/KPOk card handling, and weighbridge integration can be enhanced with an AI agent analyzing commodity price trends, classifying waste streams, and generating FPO documents.
  • For coal and solid fuel depots — the wegiel.io platform can use an AI agent to automatically fill in AKC-WW declarations based on order and coal product registry data.
  • For companies managing finances and invoicing — the mojafirma.io ERP system with KSeF integration can be extended with an AI agent that automatically categorizes cost invoices, validates the VAT whitelist, and generates JPK reports.
  • For allotment garden management boards — the dzialkowiec.io system can use AI to automatically respond to plot-holder inquiries, calculate fees, and analyze utility consumption patterns.

We also offer comprehensive AI solutions and agent deployments for companies looking to automate processes beyond the above sectors, and for organizations requiring secure infrastructure — AbejaIT IT infrastructure services with 24/7 monitoring and SLA guaranteeing business continuity.

Contact our engineering team: consultation with the AbejaIT team — a free analysis of your AI use case and a recommendation for the optimal architecture.

Source reference: Anthropic Watch

Engineering Consultation & Solutions

Need system architecture, cloud migration or IT audit?

AbejaIT delivers reliable mission-critical systems and infrastructure maintenance since 2003.

Related Articles & Analyses

22.10.2026 Servers & Infrastructure
Local AI Infrastructure for Enterprise: Architecture, Risk Vectors and ROI for IT Decision-Makers

NVIDIA's unveiling of RTX Spark, DGX Spark and DGX Station at GTC Berlin marks a pivotal shift toward on-premises AI — but is your enterprise technically and organisationally ready to harness it? We analyse the architecture, operational risk vectors, regulatory obligations and true ROI of deploying local language models in manufacturing, trading and service-sector businesses.