Architecture Overview

AxonFlow is a runtime control plane for AI systems. It sits between your applications, LLM providers, and external tools so you can add policy enforcement, audit trails, connector governance, and execution control without rebuilding your existing agent stack.

This page focuses on the public/community runtime model. It explains what runs where, how requests move through the platform, and where Evaluation or Enterprise add deeper operational controls.

If you want concrete system patterns instead of only component descriptions, start with Reference Architectures.

If you are trying to decide how AxonFlow fits at different organizational scales, pair this page with Multi-Agent Architecture Patterns By Org Maturity.

Where AxonFlow Sits

Most teams already have one or more of the following:

• an application or API that receives user requests
• an agent framework such as LangChain, LangGraph, CrewAI, LlamaIndex, or custom orchestration code
• one or more LLM providers
• external systems such as databases, vector stores, SaaS APIs, or object storage

AxonFlow becomes the control layer around those pieces:

Application / SDK
        |
        v
  Agent (:8080)
        |
        +--> system policies, auth, audit, MCP handling
        |
        v
 Orchestrator (:8081)
        |
        +--> tenant policies, routing, MAP, workflow APIs
        |
        v
  LLM providers and external systems

Core Runtime Components

Component	Default Port	Primary Role
Agent	8080	Front door for request validation, system policy enforcement, gateway-mode pre-checks, MCP access, and audit collection
Orchestrator	8081	Tenant policy enforcement, LLM routing, cost tracking, workflow APIs, and multi-agent planning features
PostgreSQL	5432	Policy state, audit records, workflow state, configuration, and platform metadata
Redis	6379	Rate limits, caches, and short-lived runtime coordination
Prometheus	9090	Metrics scraping in self-hosted community deployments
Grafana	3000	Dashboarding for local and self-hosted monitoring

Integration Modes

AxonFlow supports two main integration patterns for LLM traffic.

Gateway Mode

Gateway mode is the fastest way to add governance to an existing stack. Your application asks AxonFlow for approval before a model call, executes the model call itself, then reports the outcome back for audit and usage tracking.

Use gateway mode when you already have production logic in LangChain, LangGraph, CrewAI, DSPy, Semantic Kernel, or custom services and you want to keep that execution path intact.

Proxy Mode

Proxy mode puts AxonFlow on the execution path for the full request lifecycle. The platform can apply policy evaluation, provider routing, cost controls, audit logging, and orchestration logic as part of one flow.

Use proxy mode when you are building a new AI application, want a single governed execution path, or need AxonFlow-managed routing and workflow execution.

Two-Phase Policy Model

AxonFlow separates low-latency baseline enforcement from tenant-specific runtime controls.

Phase 1: System Policies on the Agent

The Agent evaluates built-in system policies before a request is allowed to proceed. In the current runtime, the seeded baseline includes:

• 73 pattern-based system policies
• 10 condition-based system policies
• 83 total system policies

Those policies cover areas such as:

• SQL injection detection
• admin-table and metadata access protections
• global and regional PII detection
• India-specific patterns
• Singapore-specific patterns
• code secret and unsafe-code detection

This is the part of the system that gives community users immediate protection without needing to create their own policy catalog from scratch.

Phase 2: Tenant Policies on the Orchestrator

The Orchestrator evaluates tenant-aware policies and runtime controls after the request clears system-policy checks.

Typical tenant-policy concerns include:

• organization or tenant-specific access rules
• LLM provider routing constraints
• budget and cost controls
• workflow-level approvals
• request-type or environment-specific policy logic

What Runs in Each Mode

Request Path	System Policies	Tenant Policies
LLM requests in Proxy Mode	Yes	Yes
LLM requests in Gateway Mode	Yes	Only for the AxonFlow-managed parts of the flow
MCP connector requests	Yes	Yes when tenant-policy evaluation is enabled for MCP

Agent Responsibilities

The Agent is the runtime entry point for most application traffic.

It is responsible for:

• authenticating and validating requests
• running baseline system-policy checks
• supporting gateway-mode approval and audit APIs
• mediating MCP connector access
• recording audit and usage events
• exposing health and metrics endpoints for operations teams

For engineers building complex AI products, this is the service that turns raw model and connector access into a governed runtime boundary.

Orchestrator Responsibilities

The Orchestrator handles the higher-level execution and control-plane concerns.

It is responsible for:

• tenant-policy evaluation
• provider routing and provider selection logic
• request execution in proxy mode
• workflow APIs and workflow state
• MAP and other planning/orchestration features
• compliance and reporting modules that are available in Evaluation or Enterprise builds

This separation lets teams keep the low-latency enforcement path narrow while still layering richer orchestration and governance on top.

MCP Connectors in the Architecture

MCP connectors let AI workflows access external systems such as databases, storage backends, and SaaS APIs through a governed runtime path.

Architecturally, connector traffic matters for three reasons:

• the same policy layer can inspect queries and responses before data leaves trusted systems
• audit logs capture connector usage alongside LLM execution
• teams can standardize tool access for multi-agent systems instead of embedding ad hoc credentials in every workflow

Community builds cover the core connector path and the public connector set. Evaluation and Enterprise expand the available connector catalog and operational controls.

Multi-Agent and Workflow Use Cases

AxonFlow is designed for teams building serious multi-agent and workflow-driven products, not just single-prompt demos.

Common patterns include:

• retrieval agents with governed database access
• research assistants that mix LLM calls with MCP tools
• customer support workflows with approval gates
• finance and healthcare systems that require auditability and policy checks
• workflow engines that use AxonFlow as an execution-control layer rather than replacing existing orchestration

For those teams, the value is not only “blocking bad prompts.” It is having one runtime boundary for policy enforcement, cost visibility, governance, connector access, and audit across many workflows.

Evaluation and Enterprise Additions

Evaluation and Enterprise builds extend the public/community runtime with areas such as:

• expanded connector catalogs
• advanced routing and governance controls
• workflow approval features
• regulator-specific modules
• enterprise deployment and customer-portal operations

The community runtime is enough to build and validate real applications. Teams usually move to Evaluation or Enterprise when they need deeper governance, operational guarantees, retention controls, or regulated-workflow features.

Deployment Topologies

Two practical topologies matter most:

• Community self-hosted: local Docker Compose or self-managed infrastructure for engineering teams assessing, integrating, or running source-available AxonFlow
• Evaluation / Enterprise: production deployments with additional modules, protected documentation, and stronger operational controls

The runtime model stays consistent across both. What changes is the depth of supported modules, operational tooling, and deployment guidance.

What to Read Next

• Getting Started
• Reference Architectures
• Multi-Agent Architecture Patterns By Org Maturity
• Infrastructure Details
• Workflow API
• MCP Overview
• Security Overview