ARIA: Building an Azure-Native Agentic AI Platform

Summary

ARIA (Academic Research Intelligence Assistant) is a production-grade, Azure-native agentic AI platform designed for private-document research workflows. Built as a master's thesis at Metropolia University of Applied Sciences (March 2026), the platform combines retrieval-augmented generation with multi-agent orchestration to deliver grounded, citation-traceable research answers from private document corpora — all while maintaining enterprise-grade security with zero public endpoints.

The system integrates seven specialized agents, three distinct workflow paths (question answering, report generation with human-in-the-loop approval, and document ingestion), and an eleven-stage middleware pipeline handling authentication, PII filtering, content safety guardrails, and cost tracking. Deployed on Azure Functions Flex Consumption with managed identity and VNet isolation, ARIA demonstrates that agentic AI platforms can be built with production-oriented security at a manageable but non-trivial baseline cost when private networking is enforced.

The Challenge

Research Context

Large language models have expanded the scope of automated knowledge work, yet deploying retrieval-augmented generation systems with production-grade security and operational controls remains an open engineering challenge. Researchers working with private or sensitive documents cannot rely on public AI services, and existing RAG implementations typically lack multi-agent orchestration, citation traceability, and security hardening — the features that separate a prototype from a deployable platform.

This project set out to answer whether these concerns — retrieval quality, workflow orchestration, and enterprise security — could coexist in a single, deployable platform, and whether the resulting trade-offs could be made visible and measurable rather than assumed away.

Technical Challenges

• Orchestrating multiple specialized agents with deterministic routing across QA, report generation, and document ingestion workflows — each with different state management requirements.
• Implementing hybrid RAG with PostgreSQL pgvector for semantic search, including confidence-thresholded chunk filtering and section-metadata-aware retrieval.
• Building a comprehensive 11-stage middleware pipeline handling authentication, rate limiting, PII detection, content safety guardrails, semantic caching, and cost tracking — consistently applied across all workflow paths.
• Achieving a zero-trust security posture: no public endpoints, managed identity for all service-to-service authentication, VNet isolation with private endpoints, and fail-closed content safety enforcement.
• Keeping costs feasible on an academic budget while using production Azure services and making the cost of each security posture visible rather than assumed away.

Requirements

• Private-document processing with no data leaving the Azure tenant
• Multi-agent orchestration with human-in-the-loop approval for report generation
• Full citation traceability from every answer back to source document, section, and page
• Production-ready security posture suitable for enterprise deployment patterns
• Cost-efficient serverless architecture using consumption-based pricing

Solution Architecture

System Context

The platform sits between a Streamlit research frontend and three categories of Azure services: AI inference (Azure OpenAI), content safety (Azure AI Content Safety), and vector-backed persistence (PostgreSQL with pgvector). Every boundary crossing between the platform and an external service is subject to managed identity authentication and, in production, private endpoint networking.

Agent Architecture

The system uses seven specialized agents, each responsible for a distinct aspect of the research workflow:

Middleware Pipeline

The fixed ordering of middleware stages is a structural requirement — it ensures that security and observability controls are applied consistently before any workflow-specific logic executes, preventing individual workflow paths from bypassing safety checks. The fail-closed content safety configuration (CONTENT_SAFETY_FAIL_CLOSED=true) ensures that service unavailability defaults to blocking rather than bypassing, a critical property for platforms handling sensitive research data.

Agent Workflows

QA Workflow

The question-answering path implements a linear flow from intent classification through retrieval, synthesis, and citation-packaged response.

The OrchestratorAgent classifies each incoming request as simple_qa, chitchat, or report_intent. For QA requests, the RAGRetrievalAgent performs pgvector similarity search with a configurable minimum cosine similarity threshold (PGVECTOR_MIN_REFERENCE_SCORE), filtering out low-confidence chunks before they reach the ReasoningAgent. This confidence gating is the primary mechanism for ensuring citation defensibility — only chunks meeting the threshold are exposed to synthesis and referenced in the final response.

Report Generation with Human-in-the-Loop

The report workflow implements a stateful lifecycle with draft generation, human approval, and finalization — the most complex workflow due to its multi-step nature and persistent state management:

1. Request submission — The user submits a research question via POST /api/report
2. Evidence gathering — The ReportAgent orchestrates parallel evidence collection: one lane gathers text-based evidence via RAG, another gathers figure-oriented evidence via the MultimodalAgent
3. Draft synthesis — Evidence lanes merge; the ReasoningAgent generates a structured draft with citations
4. Approval checkpoint — The draft is persisted in PostgreSQL with pending_approval status; the system returns an approval_id and suspends the workflow without consuming compute
5. Human review — The reviewer inspects the draft and issues POST /api/report/approve to approve or reject
6. Finalization — On approval, the report is finalized with full event audit trail accessible via GET /api/report/events

The workflow is durably suspended during human review using the Durable Task Scheduler — no polling, no idle compute. The system resumes exactly from its checkpoint when the reviewer responds.

Document Ingestion

The ingestion path processes documents through extraction, section-aware chunking, embedding generation (via text-embedding-3-small), and idempotent storage in PostgreSQL. Each chunk carries a labelled section path (e.g., "3.2 Related Work"), enabling the retrieval stage to return contextually situated evidence rather than decontextualised text fragments. A unique constraint on (document_id, chunk_index) prevents duplicate chunk accumulation on re-ingestion.

Infrastructure & Security

Deployment Topology

ARIA uses a dual-environment architecture that deliberately separates rapid-iteration development from production-grade security:

Security Architecture

All infrastructure is defined as code using Bicep templates, enabling repeatable provisioning across environments. The production deployment was validated through eight checkpoints covering VNet integration, private endpoint confirmation for all data-plane services, health endpoint responsiveness, and CI/CD verification gates.

Results & Evaluation

Retrieval & Performance Metrics

Comparative Analysis

The confidence threshold parameter (PGVECTOR_MIN_REFERENCE_SCORE) has a direct, measurable effect on citation quality. Without filtering, the baseline system exposes all retrieved chunks regardless of relevance, producing noisy citations. ARIA's confidence gating ensures only high-scoring chunks reach synthesis, dramatically improving citation defensibility.

Cost Analysis

Azure Cost Management data for the historical production resource group (rg-aria-prod-sdc) shows that the original $10/month figure understated the active production baseline by roughly an order of magnitude. During the period when ARIA was active in the production subscription (2026-02-27 to 2026-03-04), measured spend was EUR 42.94 across six active days, implying an active run rate of roughly EUR 180-220/month for the fully private topology. For the case study, ~EUR 200/month is the most defensible single-number summary.

The more important finding is architectural rather than numerical: at thesis-scale traffic, network posture dominated spend more than token usage or function execution. The largest cost driver in the measured window was VPN Gateway (EUR 19.73 over the active six-day sample), followed by Durable Task Scheduler, PostgreSQL, and VNet-related charges.

Security Posture Comparison

This comparison matters because the step-up in cost was not caused by the application becoming "large"; it was caused by the move from an open research environment to a private-network enterprise posture. Teams reproducing ARIA for internal pilots do not need to assume the fully private baseline immediately, but teams targeting regulated or security-sensitive deployments should expect the networking layer to dominate baseline spend. Intermediate postures, such as VNet integration without full private endpoint coverage, were considered architecturally but were not empirically measured in this project.

What Belongs to ARIA vs Supporting Platform

To avoid overstating the cost of the application itself, it is useful to separate ARIA-specific services from delivery-environment and supporting-platform overhead:

This segregation is important for two reasons. First, it makes the thesis result reproducible: readers can see what they must provision to reproduce ARIA itself versus what was specific to the surrounding delivery environment. Second, it clarifies that the fully private production cost should be interpreted as the cost of a security posture, not as the minimum cost of the application logic.

Lessons Learned

What Worked Well

• Unified PostgreSQL + pgvector eliminated the operational complexity of managing separate vector and relational databases — conversations, embeddings, query logs, and approval records all live in one schema.
• Azure Functions Flex Consumption provided true scale-to-zero economics — no idle capacity costs during development pauses or between evaluation runs.
• Microsoft Agent Framework simplified multi-agent orchestration patterns with consistent agent lifecycle management and tool binding.
• Managed identity throughout eliminated an entire class of security vulnerabilities — no connection strings to rotate, no secrets to leak, no credential management overhead.

Honest Limitations

Key Takeaways

Conclusion

ARIA demonstrates that agentic AI platforms can be designed, implemented, and deployed on Azure with production-grade security controls while remaining tractable within the constraints of a single-engineer project. The platform contributes a reusable implementation pattern — seven agents, three durable workflows, eleven middleware stages, and a zero-trust deployment topology — backed by empirical evidence on the trade-offs between retrieval quality, operational complexity, and security overhead.

The strongest contribution is not algorithmic novelty but architectural and operational viability. The cross-cutting insight from this project is that quality, operability, and security are interdependent dimensions: teams cannot improve retrieval quality without accepting orchestration complexity, cannot simplify operations without relaxing security, and cannot achieve security without investing in integration overhead. Making these trade-offs visible and measurable — rather than assuming them away — is what separates deployable platforms from prototypes.

This case study presents ARIA, developed as a master's thesis at Metropolia University of Applied Sciences. It demonstrates Cosmic Eye's expertise in Azure AI architecture, agentic AI systems, and production-grade cloud deployments. Contact us to discuss how we can help with your Azure AI initiatives.