A comprehensive enterprise architecture recommendation — one that spans business requirements, solution design, security risk, and infrastructure cost — typically requires three to four specialist consultants, a discovery workshop, and anywhere from two to eight weeks of structured analysis. This system compresses the first-pass synthesis into under five minutes, then hands the output to the human architect for validation and refinement.
The EA Advisor Agent is a live, deployed multi-agent AI system engineered to production disciplines in which four GPT-4o-mini-powered specialists each contribute a distinct analytical lens over the same set of requirements, before their outputs are assembled into a unified advisory report. It is not a replacement for human architects. It is a compression tool — one that shifts the architect’s effort from discovery to high-judgement decisions.
Why Multi-Agent, Not a Single Prompt
The obvious starting point is a single prompt: “You are a senior enterprise architect. Design a system for these requirements.” It works — up to a point. Large language models are capable of producing reasonable architecture recommendations when given structured input. The problem is cognitive role conflict.
When a single model is asked to simultaneously optimise for solution elegance, security posture, and cost efficiency, those objectives pull against each other. A business analyst and a CISO approach the same system very differently — and that productive tension, in human teams, is where the best architecture emerges. Collapsing all four perspectives into one generation pass flattens that tension. You get a compromise, not a synthesis.
The multi-agent approach preserves the tension. Each agent has a defined scope, a specialised system prompt, and no awareness of trade-offs outside its domain. The orchestration layer — not any single agent — is where the synthesis happens.
The Four-Agent Pipeline
The system runs a sequential pipeline using the CrewAI framework. Sequentiality is a deliberate design choice: each agent receives not just the original user requirements, but the full output of every preceding agent. Context accumulates. By the time the Cost Optimisation Specialist runs, it has access to the business requirements, the proposed architecture, and the risk assessment — allowing it to price trade-offs, not just components.
- Extracts core objectives, functional and non-functional requirements
- Maps stakeholder groups: operations, IT, compliance, executive leadership
- Surfaces constraints, third-party dependencies, and regulatory exposure
- Defines measurable success criteria before any architecture is proposed
- Selects architecture pattern (microservices, event-driven, serverless, hybrid) with explicit rationale
- Recommends named technology stack: specific products, not categories
- Defines service boundaries, integration patterns, and data flow
- Generates a C4-style architecture diagram in Mermaid, rendered live in the UI
- Evaluates authentication, data protection, and PII handling posture
- Identifies single points of failure and scalability bottlenecks
- Names domain-specific regulations: PCI DSS, HIPAA/PHIPA, GDPR, NERC CIP, ISO 20022
- Rates each risk High / Medium / Low with specific mitigation controls
- Real dollar amounts — component-level monthly breakdown using current AWS/Azure/GCP pricing
- Annual TCO and scaling projections at 2× and 5× current volume
- Reserved vs on-demand recommendation with break-even analysis
- Top 3 cost risks with mitigation strategies
The system ships with four pre-built prompts spanning different domains and compliance regimes, demonstrating that the agents adapt their analysis to the specific regulatory and technical context of each industry.
The Engineering Decisions That Matter
Building a multi-agent system that actually completes reliably in production — rather than timing out, looping indefinitely, or silently returning the wrong output — required a set of specific engineering decisions. These are not configuration details; they are the difference between a demo that works once and a system that runs for every user.
The Timeout Problem — And How to Solve It
A four-agent sequential LLM chain takes two to four minutes to complete. Holding a single HTTP connection open for that duration triggers proxy timeouts on any infrastructure — reverse proxies, load balancers, and API gateways all enforce idle connection limits. The naive solution (tuning timeout thresholds) papers over the symptom without solving the architecture problem.
The correct solution is an async job pattern: decouple the browser from the long-running process entirely.
← { job_id: "uuid", status: "pending" } # returns in <1 second
# browser polls every 4 seconds
GET /analyze/status/{job_id} → { status: "running" }
GET /analyze/status/{job_id} → { status: "running" }
GET /analyze/status/{job_id} → { status: "done", result: "## Business Analysis..." }
Each poll is a short-lived GET request. The analysis runs in a daemon thread on the Railway container. No connection is held open for more than a second, regardless of how long the LLM chain takes. This pattern also makes the loading state meaningful — the UI shows which agent is currently running, advancing through four steps as time elapses.
The Output Problem — Collecting All Four Agents
CrewAI’s crew.kickoff() return value contains only the last agent’s output. In a naive implementation, the C4 architecture diagram generated by Agent 02, the risk register from Agent 03, and the requirements analysis from Agent 01 are all silently discarded — only the cost analysis reaches the user.
The fix is to access task.output.raw_output on each task object after kickoff, and assemble all four sections into a single markdown document. This required identifying the correct attribute name: in CrewAI 0.28.x, the content lives in raw_output, not the raw alias that appears in documentation for other versions.
The Tech Stack
Agent Orchestration & API
Frontend
Deployment & Infrastructure
Architecture Diagram — Generated by the Agent
One of the more interesting product decisions was asking the Solution Architect agent to include a C4-style container diagram in its output, written in Mermaid syntax. The frontend renders this live using Mermaid.js — so the architecture diagram the user sees is not a static template. It is generated specifically for their requirements, with the correct component names and technology labels.
LLMs reliably generate the Mermaid diagram body but inconsistently include the opening code fence. A backend regex — re.sub(r'(?<!`)\nmermaid\n', '\n```mermaid\n', raw) — adds the fence when missing, ensuring the frontend parser always receives a valid fenced code block regardless of model output variation.
What a Production Deployment Would Add
This system is a working portfolio demonstration. For an enterprise deployment where the recommendations influence real infrastructure spend or real compliance posture, four categories of capability would need to be added.
| Control | Implementation | Estimated Saving |
|---|---|---|
| Output Caching | Redis on input hash; 24–72 hour TTL for repeated queries | 30–50% |
| Model Tiering | GPT-4o-mini for BA and Cost; GPT-4o for Architect and Risk | 40–60% |
| Token Budgets | Hard max_tokens per agent with graceful truncation | 15–25% |
| Prompt Injection Guards | Pre-processing classification step before requirements enter the pipeline | Security control, not a cost saving |
| Audit Trail | Immutable log of inputs, intermediate outputs, and final recommendations with user identity | Governance control, not a cost saving |
The Honest Value Proposition
Multi-agent architecture analysis works. For early-stage feasibility work, internal innovation reviews, or rapid client discovery, a system like this compresses a meaningful amount of structured expert thinking into a time frame that human teams cannot match. The Business Analyst agent does not get tired. The Risk Assessor does not forget to check the compliance section. The Cost Specialist does not assume the client has negotiated enterprise pricing.
The value is not in replacing the architect. It is in ensuring that the architect starts every engagement with a comprehensive first-pass analysis that covers all four domains — so they can spend their time on the decisions that genuinely require human judgement: organisational politics, existing technology debt, vendor relationships, team capability. That is a commercially real use case, and the production readiness work described above is the gap between demonstrating it and deploying it.
Try It or Read the Code
Live demo at ea-advisor-agent.cloudkraft.com. Access credentials on the sign-in page. Source code, agent prompts, and deployment configuration on GitHub.