Enterprise Architecture
AxonFlow Enterprise is easiest to understand as a governed runtime plus a protected control plane. The runtime handles application traffic. The customer portal and enterprise modules help platform, security, and compliance teams operate that runtime across organizations, tenants, providers, connectors, approvals, and evidence workflows.
This page is public because the architecture model is not customer-specific. It helps evaluators, platform teams, and coding agents understand where Enterprise adds operational depth without exposing private deployment details.
The Architecture Boundary That Matters
Keep three surfaces separate:
| Surface | What it does | Typical users |
|---|---|---|
| Public runtime | Agent, Orchestrator, SDKs, MCP connector governance, WCP, MAP, audit, provider routing | Application engineers and platform teams |
| Customer portal | Session-backed operational UI and protected portal APIs for identity, usage, deployments, providers, connectors, policies, and docs access | Platform, security, compliance, and operations teams |
| Enterprise modules | Regulated workflows, approvals, evidence export, code governance, non-repudiation, and customer-specific rollout workflows | Compliance, risk, platform, and admin users |
If teams miss that boundary, they often treat every feature as one monolithic API surface. In practice, applications call runtime paths, operators use the portal, and governance teams review evidence produced by both.
Core Enterprise Components
Customer portal
The customer portal is the enterprise control plane for:
- session-backed authentication and SSO
- organization, license, and deployment views
- API key, SCIM token, SSO, and docs-access management
- connector and LLM-provider configuration
- policy, approval, execution, usage, and export workflows
- deployment upgrade and observability workflows where the deployment mode supports them
Agent
The Agent is the application-facing enforcement surface. It is where request validation, system-policy checks, MCP handling, gateway-mode pre-checks, and audit collection happen.
Orchestrator
The Orchestrator handles higher-level runtime control: tenant policies, provider routing, proxy-mode processing, workflows, MAP, WCP, planning, replay, and compliance/reporting modules available in Evaluation or Enterprise builds.
Enterprise modules
Enterprise modules add protected operational workflows on top of the runtime. Examples include regulated compliance modules, approval queues, evidence export, non-repudiation, code governance, deployment operations, and portal administration.
Request Path Versus Control Plane
The request path is where governed work executes. The control plane is where enterprise teams configure, review, and operate the platform safely.
That distinction drives several architecture decisions:
- provider routing should be standardized as platform configuration, not copied across every app
- connector onboarding should be reviewed with security and governance before production use
- approvals and evidence export should have clear owners before high-risk workflows launch
- customer-specific runbooks belong in protected docs or partner packs, not public pages
SaaS Versus In-VPC
The first architecture choice is often not Proxy Mode versus Gateway Mode. It is whether the enterprise runs in shared SaaS or inside a customer-controlled deployment.
| Deployment mode | When it fits | What changes operationally |
|---|---|---|
| SaaS | Teams that want fast rollout and tenant isolation without owning full platform infrastructure | Operations are more shared, node-level visibility is narrower, and customer-facing controls stay tenant-scoped |
| In-VPC | Enterprises that need stronger infrastructure control, tighter network boundaries, or shared internal platform ownership | Platform owners get broader operational visibility, deployment workflows are more infrastructure-aware, and runtime resources can align to internal controls |
| Self-hosted | Teams that want to own infrastructure, upgrades, network, and runtime dependencies directly | The customer owns more operational responsibility and should validate telemetry, secrets, backup, upgrade, and monitoring posture explicitly |
Banks, healthcare organizations, public-sector teams, and large enterprises with strong internal platform teams often prefer In-VPC or self-hosted postures for higher-risk workloads. SaaS can still be a strong fit for lower-risk workflows, early adoption, or teams that prioritize speed over infrastructure ownership.
Runtime Patterns In Enterprise
The same enterprise deployment can use multiple request patterns.
| Pattern | Best fit | Enterprise angle |
|---|---|---|
| Gateway Mode | Existing applications that already own direct LLM calls | Low-friction governance with application-owned provider calls and mandatory audit discipline |
| Proxy Mode | Teams that want AxonFlow to own governed request processing and provider routing | Stronger centralization and a simpler audit posture for new AI services |
| Decision Mode | Existing gateways, service meshes, or platform layers that can call AxonFlow as a policy decision service | Governance without placing AxonFlow on the traffic path |
| MCP connector governance | Tool and connector calls that touch external systems | Per-connector controls, request/response scanning, and audit for tool activity |
| Workflow Control Plane | Multi-step, approval-heavy, or replay-sensitive workflows | Step-level governance, approvals, checkpoints, retries, and execution visibility |
Use Runtime Request Paths and Runtime Surface Map to choose the request path. Use Gateway Mode, Proxy Mode, Decision Mode, and WCP Overview for implementation detail.
Control-Plane API Families
Enterprise control-plane APIs are not the same thing as runtime SDK credentials. The major families include:
| Family | Example path family | Notes |
|---|---|---|
| Portal authentication | /api/v1/auth/* | Session-backed portal authentication and SSO availability |
| Deployment operations | /api/v1/deployments/* | Upgrade and deployment status workflows where enabled |
| Connector and provider configuration | /api/v1/connectors*, /api/v1/llm-providers* | Runtime configuration surfaced through the portal |
| Usage and operational visibility | /api/v1/usage*, /api/v1/nodes*, /api/v1/license/status | Deployment-mode-aware visibility |
| SCIM | /scim/v2/*, /api/v1/scim/tokens* | SCIM bearer-token provisioning and portal-side token lifecycle |
| SSO configuration | /api/v1/sso/* | SAML provider metadata, testing, and audit workflows |
| API keys | /api/v1/keys | Portal automation keys, separate from runtime client credentials |
| Admin organization operations | Admin organization API surface | Privileged tenant lifecycle and license operations; treat the admin key like a database credential |
Use public docs for the generic model and protected docs or support channels for customer-specific route behavior, screenshots, environment details, hostnames, commercial context, and rollout runbooks.
Architecture Decisions That Matter Most
When enterprises move from one governed assistant to a shared AI platform, these decisions matter most:
Provider strategy
- Which providers are centrally approved?
- Which workloads need Bedrock, Azure OpenAI, OpenAI, Anthropic, Ollama, or private inference?
- Who can change routing, cost metadata, health status, or failover behavior?
Start with Provider Routing and Provider Credential Matrix.
Connector strategy
- Which business systems will AI workflows read from or act on?
- Which connectors are tenant-specific versus shared?
- How are credentials stored, tested, rotated, and reviewed?
Start with Connector Capability Matrix and MCP Policy Enforcement.
Governance strategy
- Which teams own system policies, tenant policies, overrides, and rollout gates?
- Which workflows need approvals before actions complete?
- Which evidence should be retained or exported?
Start with Policy Hierarchy, Policy Management, HITL Approval Gates, and Audit Logging.
Operations strategy
- Who owns upgrades?
- Who owns monitoring and dashboard access?
- Who responds when provider, connector, telemetry, or deployment posture changes?
Start with Deployment Mode Matrix, Deployment Operations, Monitoring Overview, and Customer Portal.
Architecture Review Checklist
Before standardizing an enterprise deployment, make sure the team can answer:
- Which deployment mode are we actually running: SaaS, In-VPC, or self-hosted?
- Which workloads should use Gateway, Proxy, Decision Mode, MCP connector governance, or WCP?
- Which providers and connectors are centrally managed?
- Which teams own policy changes, approvals, incident response, and evidence export?
- Which dashboards and operational APIs are visible in this deployment mode?
- Which regulated workflows need compliance-module coverage?
- Which customer-specific details must stay in protected docs or private support channels?
