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 choosing which API path an application should call first, use Runtime Request Paths.
If you are trying to decide how AxonFlow fits at different organizational scales, pair this page with Multi-Agent Architecture Patterns By Org Maturity.
The two-phase model below is what AxonFlow enforces today. For where the authorization architecture is heading - a unified identity, approval, obligation and signed-decision model - read Policy and Identity Control Plane: Target Architecture.
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. The diagram shows Proxy Mode, where AxonFlow owns the model-request lifecycle. Other paths move enforcement or execution to an application, gateway, MCP host, or external orchestrator. See Runtime Request Paths for all seven paths.
Every stage in the diagram is described below. The deployment topology keeps the same Agent and Orchestrator roles, but the exact policy phases, approval behavior, output controls, and audit responsibilities depend on the selected request path.
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 |
Runtime Path Families
AxonFlow exposes seven named paths, grouped by execution ownership:
- Caller-owned execution: Decision Mode, Gateway Mode, MCP governance, and WCP. Your gateway, application, MCP host, connector, or workflow engine executes the real action and must enforce the AxonFlow result.
- AxonFlow-managed execution: Proxy Mode and MAP. AxonFlow owns the provider call or generated-plan execution.
- Advanced service access: Direct Orchestrator. A trusted internal service calls the lower-level Orchestrator surface and owns the additional authentication, identity, and routing responsibilities.
Framework integrations are adapters into those paths, not additional modes. See Choosing an Integration Mode for the decision tree and Governance Architecture and Coverage for coverage differences.
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 (v10.4.0), the seeded, always-on baseline is:
70pattern-based system policies10condition-based system policies80total system policies
The count is pinned by a real-Postgres test in the platform repository that applies every core migration to a fresh database and asserts the seeded total, so the number cannot drift from the migrations without a failing test. The 70 pattern-based policies break down by category as:
- SQL injection detection (38 patterns)
- admin-table and metadata access protections (4)
- indirect prompt-injection guards (4)
- global PII (7), US (2), EU (1), India (2), Singapore (5) and Indonesia (1) PII patterns
- credential and secret detection (6)
Beyond these 80 immutable system policies, a fresh database also seeds editable tenant-tier starter policies (for example the EU AI Act templates) and a set of IDE and agent integration policies that ship disabled and are activated per deployment.
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 Path
| Request path | Policy boundary | Execution owner |
|---|---|---|
| Decision Mode | Decision API used by an infrastructure gateway | Gateway |
| Gateway Mode | Agent pre-check, followed by an explicit audit submission | Application |
| Proxy Mode | Agent and Orchestrator managed request flow | AxonFlow |
| MCP governance | MCP input and output checks, including connector-scoped policy | MCP host or connector |
| MAP | Plan and step policy in the managed planning lifecycle | AxonFlow |
| WCP | Explicit gate before each governed external workflow step | External orchestrator |
| Direct Orchestrator | Depends on the selected Orchestrator endpoint | Depends on endpoint |
Policy coverage is endpoint-specific. See Governance Architecture and Coverage before assuming that a path includes output filtering, queue-backed approvals, or automatic provider-call audit.
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.
If you are choosing between SDK modes, framework integrations, WCP, MAP, MCP connector governance, or Decision Mode, map the surfaces by who owns the model call, who owns execution state, and where governance should happen before committing to an integration shape.
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 AxonFlowEvaluation / 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.
