AI Agents for Business — Production Architecture for Custom AI Agent Development

By Amar Kumar, founder of stackcone · September 2026

Search interest has moved from “what is AI” to “AI agents for business”. Companies are no longer asking for a demo chatbot. They want custom AI agents that answer from their own data, take actions in their CRM and helpdesk, pick up the phone, and stay inside GDPR and the EU AI Act. This brief lays out the reference architecture stackcone (an AI agent development company) uses for custom AI agent development: one agent core with four pluggable layers — knowledge (RAG), action (tool calling + MCP), channels (web, Slack/Teams, WhatsApp, voice), and trust (evals, guardrails, human-in-the-loop).

Proposed outcome: A production AI agent that resolves 40–70% of routine requests end to end (support tickets, bookings, lead qualification, internal questions), cites its sources, writes back to your systems through audited tools, escalates to a human when unsure, and can be hosted in the EU or your own cloud.

What buyers are actually asking for

US Google data through mid-2026 shows agent and automation queries now pull roughly four times the volume of generic “AI for [task]” searches. “Agentic AI” sits around 110k monthly US searches, “AI agents” around 60k, and “AI agents for business” more than tripled year over year. The searches that turn into projects are more specific:

Two patterns stand out. First, industry-specific agents (dental, legal, insurance, real estate, e-commerce) are the fastest-growing segment and outperform general-purpose ones. Second, roughly half of B2B buyers now start vendor research in ChatGPT, Claude or Perplexity rather than Google, and they ask about architecture, pricing and compliance directly — which is what this brief answers.

Why most AI agent projects stall

• Demo ≠ production — a prompt in a playground works on ten questions and fails on the eleventh; nobody measured accuracy before launch
• No grounding — the agent answers from model memory instead of the company’s current policies, prices, and documents, so it hallucinates
• Read-only agents — it can explain the refund policy but cannot issue the refund, so the ticket still reaches a human
• Unsafe actions — the opposite failure: an agent with broad API keys and no approval step, which security teams (rightly) block
• Framework lock-in — integrations written once for one vendor’s SDK have to be rewritten when the model or framework changes
• Compliance afterthought — EU customers ask where data is processed, how long logs are kept, and who reviews automated decisions; the answer is “we’ll check”
• No owner after launch — prompts drift, documents go stale, costs creep, and nobody watches the dashboard

Requirements

Functional

• Grounded answers: Retrieve from company sources (docs, website, tickets, product DB) with citations; refuse when the answer is not in the sources
• Actions through tools: Typed, permission-scoped tools for CRM, helpdesk, calendar, billing, e-commerce, and internal APIs
• Multi-channel: Website widget, Slack/Teams, WhatsApp/SMS, email, and phone (voice) from one agent core
• Memory: Conversation state per user/session; optional long-term customer profile from the CRM rather than free-form model memory
• Human-in-the-loop: Approval queue for risky actions (refund > threshold, contract changes); warm handoff to a human with full context
• Admin console: Edit knowledge sources, tool permissions, prompts and escalation rules without a code deploy

Non-functional

• Accuracy gate: Offline eval suite (golden questions + tool-call scenarios) must pass before every release
• Latency: First token < 1.5 s for chat; < 800 ms turn latency for voice
• Security: SSO, RBAC, per-tenant data isolation, secrets in a vault, least-privilege tool credentials
• Data residency: Selectable US / EU / UK regions; option for self-hosted open-weight models
• Observability: Full trace of every run — retrieved chunks, tool calls, tokens, cost, latency, user feedback
• Model independence: Swap between Claude, GPT, Gemini or open-weight models through one gateway without rewriting the agent

Reference architecture

The design keeps one agent core (planner + tool loop) and makes everything around it pluggable. Channels are thin adapters. Knowledge and tools sit behind stable interfaces — retrieval as a tool, integrations as MCP servers — so the same agent can run behind a web widget today and a phone line next quarter.

flowchart TB classDef chan fill:#ede9fe,stroke:#7c3aed,color:#5b21b6 classDef core fill:#dbeafe,stroke:#2563eb,color:#1e3a8a classDef know fill:#ccfbf1,stroke:#0d9488,color:#115e59 classDef act fill:#f1f5f9,stroke:#64748b,color:#334155 classDef trust fill:#fef3c7,stroke:#d97706,color:#92400e WEB["Website widget"]:::chan CHAT["Slack / Teams / WhatsApp"]:::chan VOICE["Phone: Twilio + voice runtime\nSTT / TTS"]:::chan API["Your product API"]:::chan GW["Channel gateway\nauth, session, rate limits"]:::core WEB --> GW CHAT --> GW VOICE --> GW API --> GW GR_IN["Input guardrails\nPII redaction, injection filter"]:::trust GW --> GR_IN AGENT["Agent core\nplanner + tool loop + state"]:::core GR_IN --> AGENT LLM["LLM gateway\nClaude / GPT / Gemini / open-weight"]:::core AGENT <--> LLM RAG["Retrieval tool\nhybrid search + rerank"]:::know VDB["Vector + keyword index\npgvector / OpenSearch"]:::know SRC["Sources: Drive, SharePoint,\nConfluence, site, tickets"]:::know AGENT --> RAG RAG --> VDB SRC -->|"ingest + ACLs"| VDB MCP["MCP servers\ntyped, scoped tools"]:::act AGENT --> MCP MCP --> CRM["CRM: HubSpot / Salesforce"]:::act MCP --> DESK["Helpdesk: Zendesk / Intercom"]:::act MCP --> OPS["Calendar, Stripe, Shopify,\ninternal APIs"]:::act HITL["Approval queue +\nhuman handoff"]:::trust AGENT -->|"risky action / low confidence"| HITL OBS["Tracing + evals\nLangfuse / LangSmith"]:::trust AGENT -.-> OBS

Reference architecture — thin channel adapters, one agent core, retrieval and MCP tools behind stable interfaces, and a trust layer (guardrails, approvals, tracing) around every run

sequenceDiagram autonumber participant U as Customer participant G as Gateway + guardrails participant A as Agent core participant R as Retrieval participant T as MCP tools participant H as Human agent U->>G: "Where is my order? I want a refund" G->>A: redacted message + session A->>T: get_order(email) T->>A: order 4412, delivered late A->>R: search("late delivery refund policy") R->>A: policy chunks + citations alt refund within auto-approve limit A->>T: create_refund(4412, 30.00) T->>A: refund_id A->>U: refund issued + policy link else above limit or low confidence A->>H: handoff with summary + draft reply H->>U: approves / edits and sends end

Typical support-agent run — look up the record, ground the answer in policy, act within limits, and hand off with a draft when the action is risky

Build path

Ship one narrow agent to production first; add channels and tools only after the eval gate is green

Five agent patterns (and when to use each)

Rule of thumb: start at the lowest pattern that solves the problem. Most “we need a multi-agent system” requests are really pattern 2 with good retrieval. Move to pattern 5 only when one agent’s tool list, permissions, or prompt become unmanageable.

Recommended stack

Recommendation: Python (FastAPI) agent service on LangGraph or a vendor agent SDK (Claude Agent SDK / OpenAI Agents SDK), Postgres + pgvector for state and retrieval, integrations exposed as MCP servers, a model gateway for provider switching, and Langfuse for tracing and evals. For SMB workflow agents, n8n (self-hosted in the EU if needed) keeps the automation visible to the client.

Why MCP for integrations? A HubSpot or Zendesk MCP server built once can be used by the support agent, the sales agent, and staff inside Claude or ChatGPT. It also forces clean tool contracts — name, typed arguments, scope — which is exactly what security reviews ask for.

Why not start with a no-code agent builder? They are fine for prototypes. Production buyers usually need custom retrieval, permission-aware data, eval gates and hosting control, which is where a custom build pays off. A common path is prototype in n8n, then move the core loop to code.

Component design

1 — Knowledge layer (RAG)

• Ingestion: Connectors for Drive, SharePoint, Confluence, Notion, website, and resolved tickets; scheduled re-sync with change detection
• Chunking: Structure-aware (headings, tables) with parent-document linking; metadata for source, owner, date, and access group
• Search: Hybrid BM25 + vector, reranker, top-k 5–8; filter by the caller’s access group before ranking
• Answering: Cite chunk IDs; say “I don’t know” when retrieval score is below threshold
• QA gate: Recall@5 and faithfulness on a 100–300 question golden set (see how to evaluate RAG retrieval)

2 — Action layer (tools + MCP)

• Tool contract: Name, description, JSON schema, scope (read / write / money), and idempotency key
• Permissions: Tools run with the end user’s or a service account’s least-privilege token, never an admin key
• Thresholds: Write actions above a configurable limit go to the approval queue
• Audit: Every call logged with input, output, user, and trace ID
• QA gate: Scenario tests that assert the right tool is called with the right arguments — and that forbidden tools are never called

3 — Agent core

• Loop: Plan → call tools → observe → answer, with a max-step budget and timeout
• State: Session state in Postgres; customer facts pulled from CRM on demand instead of stored in model memory
• Routing: Small model classifies intent and picks the playbook; frontier model handles multi-step reasoning
• Fallback: Provider failover through the gateway; graceful “I’ll pass this to a colleague” when all else fails

4 — Channels

5 — Trust layer

• Input: PII detection and redaction before logs; prompt-injection filtering on retrieved content and user input
• Output: Policy checks (no legal/medical advice beyond scope, no price promises outside catalogue), citation required for factual claims
• Human-in-the-loop: Approval inbox, handoff with summary and draft, confidence thresholds per intent

GDPR, UK GDPR & EU AI Act

European and UK buyers search for “GDPR compliant AI chatbot” and “EU AI Act compliant AI” because procurement will ask. The architecture above supports this by design:

This is engineering guidance, not legal advice — the client’s DPO or counsel should confirm risk classification for their specific use case.

Implementation plan

Evals, monitoring & ops

More on this in AI agent testing and evaluation strategies.

Cost & effort estimate

Ranges depend on API quality of existing systems, number of integrations, compliance scope, and how clean the source documents are.

FAQ

How much does it cost to build a custom AI agent for a business?

A focused pilot usually costs 8k–25k over 3–6 weeks. Multi-channel production agents with voice, evals and SSO land in the 25k–80k range, plus monthly run and tuning costs.

What is the difference between an AI chatbot and an AI agent?

A chatbot answers. An agent also acts — it calls your CRM, helpdesk, calendar or billing APIs, follows multi-step plans, and hands off to a human when unsure.

Do I need a multi-agent system?

Usually not at first. One well-scoped agent with good retrieval and a few tools covers most use cases. Split into multiple agents when permissions or tool count make one agent unmanageable.

Can an AI agent be GDPR and EU AI Act compliant?

Yes — EU-region or self-hosted models, zero data retention, PII redaction, a DPA, AI disclosure, and human oversight for consequential decisions.

Who builds custom AI agents like this?

stackcone is an AI agent development company founded by Amar Kumar. We build RAG chatbots, AI customer support agents, AI voice agents and MCP integrations for businesses, with fixed-scope pilots and full handover. See our portfolio or contact us.

What is MCP and why does it matter?

The Model Context Protocol is an open standard for exposing tools and data to AI models. MCP-based integrations work across Claude, ChatGPT, IDEs and custom agents, so you are not locked into one framework. See AI agents and MCP in practice.

Glossary