11 Agents, Zero Infrastructure: The Minimum Viable Architecture for Production AI
11 Agents, Zero Infrastructure: The Minimum Viable Architecture for Production AI
Keywords: ai agent architecture ecommerce, multi-agent system, claude production architecture, zero infrastructure ai
Introduction
Most teams think building an AI analytics system means servers, databases, a data warehouse, DevOps headcount, and a six-figure infrastructure bill before the first insight ships. We built an eleven-agent system that analyses a luxury retailer's e-commerce operation across seven channels — orders, products, email, website, market intelligence, Google Ads, and Meta — for zero infrastructure cost.
No servers. No databases. Just Claude, Notion, and Python. This article explains the architecture, the design principles we borrowed from Anthropic's agent research, and why the intelligence lives in the instructions, not the infrastructure.
The Problem We Were Solving
A multi-brand luxury retailer operates at a scale where manual reporting has run out of road. The operation spans:
- Tens of thousands of SKUs across hundreds of brands
- Hundreds of active paid-media campaigns across multiple regional ad accounts
- A six-figure monthly email volume
- Multi-channel sales data flowing from Shopify, physical retail, and wholesale
No human team can hold that whole picture in mind at once. The signal that a campaign has run its course, that a SKU is priced off-market, that an email segment has gone cold — all of these are visible in the data, but only if you can analyse seven channels simultaneously, cross-reference them, and surface transitions.
That was the brief. What we refused to do was spin up a data warehouse to solve it.
The Architecture in One Diagram
Eleven agents, three tools, seven channels.
Channel Agents (7) Support Agents (3) Synthesis Agent (1)
────────────────── ────────────────── ───────────────────
Orders Data Standardisation
Products Feedback Processing ──→ Cross-references
Email Instruction Refinement all channel outputs
Website → unified insights
Market Intelligence → ranked actions
Google Ads
Meta
Each channel agent runs a scoped analytical framework against a single data domain. The three support agents handle plumbing: standardising inputs, processing human feedback from prior cycles, and refining the instruction sets that each analyst agent uses. The synthesis agent reads everything each channel produced and cross-references across them — because the most valuable insights only appear when two channels are viewed together.
A full cycle completes in under three hours. It produces over a hundred individual insights per run, ranked and grouped by action priority.
The Three-Tool Stack
We built this on three tools. That's not a typo.
Claude — every agent, every reasoning step. The intelligence layer.
Notion — the knowledge base. Databases for insights, feedback, instructions, and historical context. No separate CRM, no separate data warehouse, no BI layer.
Python — local CSV processing. No ETL vendor, no Airflow, no dbt. Standardised exports from each channel dropped into a folder, normalised by a small script, then handed to the agents.
That's it. No Kubernetes. No Snowflake. No Airbyte. No Terraform. No on-call rotation.
Why This Works: The Intelligence Is in the Instructions
Here's the counter-intuitive part. The hard work in this system is not the plumbing. It's the instruction set each agent runs.
Each channel agent runs a carefully designed analytical framework — refined across a dozen iterations over three months. That refinement is where the system's intelligence lives. The framework tells the agent:
- What questions to ask of this data domain
- How to rank findings by priority
- What counts as actionable vs. informational
- How to format output so the synthesis agent can consume it
Swap the data warehouse for a Notion database and the system still works. Swap the reasoning framework for a generic "summarise this data" prompt and it collapses. The value is in the prompt library, not the stack.
This mirrors what Anthropic's agent design research consistently emphasises: start with the simplest architecture that solves the problem. We took that principle literally.
The Anthropic Patterns This Maps To
Three patterns from Anthropic's agent research show up explicitly in this architecture:
1. Orchestrator-workers. The synthesis agent is the orchestrator. The seven channel agents are the workers. Each worker has a narrow, scoped job. The orchestrator is the only agent that needs to hold the full picture in context.
2. Evaluator-optimizer. The instruction-refinement agent observes what prior cycles produced, cross-references that with human feedback captured in Notion, and proposes refinements to the analyst agents' frameworks. The system gets sharper every cycle without a human re-writing prompts.
3. Routing. Not every insight gets the same treatment. The system routes findings to different evaluation criteria based on type — brand search is not evaluated like prospecting; prospecting is not evaluated like retargeting. This is what lets a paid-media agent handle hundreds of campaigns without flattening them into a single rubric.
What Actually Runs in a Cycle
A run looks like this:
- Export drop. Standardised CSVs from each channel land in a folder. No live API pulls. No real-time ingestion. Batch is fine.
- Normalise. A Python script standardises schema, timestamps, and identifiers.
- Channel agents in parallel. Each channel agent runs its analytical framework against its domain CSV. Output lands in a dedicated Notion database, one row per insight.
- Synthesis. The synthesis agent reads all channel databases, cross-references, ranks, and writes unified findings to a master insights database.
- Human review. Ranked insights are reviewed by the operator. Decisions and feedback are captured in Notion.
- Feedback loop. The feedback-processing agent ingests the review, updates pattern libraries, and feeds improvements into the instruction-refinement agent for the next cycle.
The whole loop runs in under three hours. Most of that time is the channel agents reading data — the reasoning itself is fast.
The Trade-Offs We Accepted
This architecture has real limits. We named them up front.
Not real-time. This is batch analysis. Insights are produced on a cycle, not streaming. For the use cases we designed it for, that's fine. For a fraud-detection system, it wouldn't be.
No fancy dashboards. Outputs live in Notion. No Looker, no Tableau, no custom BI. For a team that reviews insights in a shared workspace anyway, Notion is the right tool. For a team that wants auto-generated executive PDFs, something else would fit better.
Vendor-coupled to Claude and Notion. We chose that coupling deliberately. The agent framework is portable — the prompts would port to another model. The knowledge base would port to another store. But we're not defending optionality we don't need.
Those trade-offs are what let the architecture be this cheap. Every time we considered adding a component, we asked: does this unlock an insight we couldn't get without it? Most of the time, the answer was no.
Why Start Here, Not Somewhere Bigger
When you're adding AI to an operation, the temptation is to architect for the future: data lakes, vector databases, fine-tuned models, an MLOps pipeline. All of that might be the right answer eventually. Almost none of it is the right answer on day one.
The principle: complexity is a liability, not a feature. Every service added is a service to monitor, patch, pay for, and explain. Start with the minimum viable architecture. Let the instruction quality do the heavy lifting. Add infrastructure only when a specific agent's job demands it and cannot be solved by a better prompt.
We've shipped this pattern across multiple client engagements now. The shape is always the same: simple data pipeline, scoped channel agents, one synthesis layer, a feedback loop. What changes is the instruction library. That's where the compounding happens.
Why This Matters for Your Business
If you're looking at a multi-channel operation and wondering how to add AI analytics without a six-month infrastructure build, this architecture is the short answer. The long answer is a function of how much analytical rigour your team is willing to invest in the instruction library — because that is where the system's intelligence actually lives.
If you're already paying for a data warehouse, a BI stack, an ETL vendor, and an MLOps pipeline — and still not getting cross-channel insights — the question is worth asking: what is the infrastructure actually buying you that a Claude agent with a good framework couldn't produce from a CSV?
FAQ
Q: How do you handle data freshness if exports are manual?
A: For the use cases this system targets — strategic cross-channel analysis, not real-time alerting — a daily or weekly export cadence is fine. If a specific channel needs near-real-time, we add a scheduled export for that channel only. We don't pull everything to real-time just because one domain needs it.
Q: Doesn't running everything through Claude get expensive?
A: Token cost is the system's operating cost. It is materially lower than the infrastructure cost of the equivalent data warehouse + BI + MLOps stack, and orders of magnitude lower than the headcount cost to do the same analysis manually. We track cost per cycle and per insight — it's the metric we actually care about.
Q: How do you prevent the agents from hallucinating insights?
A: Three guardrails. First, each agent is given the raw data it is analysing — it cannot invent numbers that aren't in the CSV. Second, the synthesis agent is instructed to cite specific channel-agent findings, so any synthesised claim traces back to a source row. Third, the feedback loop: operators flag false positives, and those patterns are fed back into the instruction-refinement agent for the next cycle. False-positive rates have dropped cycle over cycle.
Q: Can I run this on a different model? Different knowledge base?
A: Yes. The architecture is model-agnostic and store-agnostic. We've built it on Claude + Notion because that combination delivers the best reasoning-to-cost ratio for our workloads today. The agent framework, the orchestration pattern, and the instruction library are portable.
Q: How long did it take to build?
A: The initial architecture — scoped channel agents, synthesis layer, one Notion workspace — was operational in a few weeks. The instruction library is what took three months, and is what continues to compound. Anyone who tells you the architecture is the hard part has confused the plumbing for the product.
Q: What's the failure mode I should worry about?
A: Instruction drift. If the instruction library stops being refined, insight quality plateaus. The evaluator-optimizer pattern is how we prevent that — but it's only as good as the operator feedback that feeds it. The system we shipped depends on humans closing the loop. If that loop breaks, the system gets stale fast.