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 model below is what AxonFlow v11 enforces: one policy decision engine on the planes it governs. The unified identity, approval, obligation and signed-decision model it is built on is described in Policy and Identity Control Plane.
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 | Typed policy authoring, policy decisions on the orchestration planes, 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.
One Policy Decision Engine
In v11 one policy decision engine decides on the enforcement planes it governs. The Agent runs the pattern-based detectors whose findings the engine reads, and the Agent and the Orchestrator each call the engine for the planes they serve.
The shipped system policies
In the current runtime (v11.1.0) AxonFlow ships these system policies on the platform's own policy root:
70pattern-based system policies15condition-based system policies85total system policies
The condition-based count rose from 10 to 15, and the total from 80 to 85, in v11.0.0. Nothing was added: the five media-governance controls that have always shipped became migration-seeded, and therefore counted, in that release.
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)
Beside these 85, v11 ships 22 organization-editable policies on each organization's own policy root: the tenant-tier policies v10.x seeded, among them the destructive-command, DROP TABLE and TRUNCATE blocks and the EU AI Act and GDPR templates. Nine IDE and agent integration detectors ship disabled and decide nothing in v11. Shipped Policy Posture lists every one with its action.
The 85 and the 22 decide from the first boot on every edition, so a deployment is governed before anyone writes a policy.
Your organization's policies
An organization can disable, re-enable or re-action each shipped policy, and writes policies of its own as a typed policy document, which the same engine enforces once it is published and activated. Rows in the v10.x tenant-policy tables are read-only in v11 and decide nothing; see Typed Policy Authoring.
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 the detectors, and deciding each governed request on its planes with the policy decision engine
- 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:
- the typed policy authoring routes, and the policy decisions on the orchestration planes (MAP, WCP and response filtering)
- 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.
