Choosing an Integration Mode

AxonFlow has seven named runtime paths. They are not seven competing products. Each puts policy enforcement at a different point in a model, tool, or workflow lifecycle.

The fastest way to choose is to answer one question: who should execute the real action?

• If your gateway, application, MCP host, or workflow engine should execute it, choose a caller-owned path: Decision Mode, Gateway Mode, MCP governance, or WCP.
• If AxonFlow should execute it, choose an AxonFlow-managed path: Proxy Mode or MAP.
• If a trusted internal platform service needs lower-level APIs, consider Direct Orchestrator access.

Most production systems combine paths. An application can use Gateway Mode for existing model calls, MCP governance for database tools, and WCP for its durable workflows.

For the canonical endpoint inventory, see Runtime Request Paths. For control-by-control differences, see Governance Architecture and Coverage.

Evaluating a production architecture?

Use the free 90-day Evaluation License for self-hosted validation. For a sponsored workflow with a defined production requirement, review the paid Production Program.

All Seven Paths

Path	Who executes	Start with it when	Main responsibility you retain
Decision Mode	Your infrastructure gateway	One gateway should govern many applications without per-application changes	Enforce the decision and fulfill supported obligations
Gateway Mode	Your application	Existing code should keep the direct model-provider call	Honor the pre-check and reliably submit the post-call audit
Proxy Mode	AxonFlow	A new or simplified application wants one governed model-request call	Supply correct identity, provider context, and retry behavior
MCP governance	Your MCP host or connector	Tool calls need connector-scoped policy and input/output checks	Gate execution and submit output when output controls are required
MAP	AxonFlow	AxonFlow should generate and execute a multi-step plan	Monitor, approve where enabled, and resume the managed plan
WCP	Your external orchestrator	LangGraph, n8n, Temporal, Airflow, or another engine should keep workflow execution	Gate every governed step and submit completion or failure
Direct Orchestrator	Depends on selected API	A trusted internal platform service needs the low-level Orchestrator surface	Protect the service boundary and wire auth, identity, routing, and audit context

Framework integrations are adapters, not additional modes. A LangGraph integration, for example, can use Gateway Mode for model calls, WCP for workflow steps, and MCP governance for tools.

Decision Tree

Add MCP governance to any selected path when connector identity, tool inputs, or tool outputs require dedicated controls.

Path Details

Decision Mode

Use Decision Mode when your organization already routes AI traffic through shared infrastructure such as an LLM gateway, MCP gateway, or agent router.

Client -> your gateway -> POST /api/v1/decide -> gateway enforces -> target

AxonFlow returns a policy decision and obligations. It does not make the target call or automatically capture the target response. The gateway must enforce the verdict and safely handle an unavailable policy service.

Primary endpoint: POST /api/v1/decide

See Decision Mode and Building a Policy Enforcement Point.

Gateway Mode

Use Gateway Mode when an existing application or framework should keep its provider call.

Application -> pre-check -> provider call in application -> audit submission

It is usually the least disruptive model-call integration, but the audit trail depends on the application reliably submitting the post-call record.

Primary endpoints:

• POST /api/policy/pre-check
• POST /api/audit/llm-call

See Gateway Mode.

Proxy Mode

Use Proxy Mode when AxonFlow should own the model request, provider routing, enabled response controls, usage capture, and audit flow.

Application -> Agent POST /api/request -> Orchestrator POST /api/v1/process -> provider

SDK-style Proxy Mode enters through Agent POST /api/request. Direct POST /api/v1/process calls use the lower-level Orchestrator contract and belong inside a trusted service boundary.

Primary endpoint: POST /api/request

See Proxy Mode and Provider Routing.

MCP Governance

Use MCP governance when the immediate risk is a tool or connector action: a database query, SaaS write, file retrieval, message send, or HTTP request.

Primary endpoint families:

• POST /api/v1/mcp/check-input
• POST /api/v1/mcp/check-output
• /api/v1/mcp-server

MCP governance carries connector_type, so connector allowlists, per-connector policies, and output checks can apply. Decision and Gateway Mode do not become connector-scoped merely because submitted text describes a tool.

See MCP Overview and MCP Policy Enforcement.

Multi-Agent Planning

Use MAP when AxonFlow should turn an objective into a stored plan and execute its governed steps.

Primary endpoint family:

• POST /api/v1/plan
• POST /api/v1/plan/execute
• GET /api/v1/plan/{id}
• plan status, version, approval, cancel, resume, and rollback routes

MAP owns planning and execution. It is not the right choice merely because a workload has several steps.

If your application supplies a predefined workflow for AxonFlow to execute, use POST /api/v1/workflows/execute. If an external orchestrator executes the steps, use WCP.

See Multi-Agent Planning Overview and the Workflow and MAP API.

Workflow Control Plane

Use WCP when an external orchestrator owns the workflow but needs an AxonFlow policy gate before each governed step and a completion record afterward.

Primary endpoint family:

• POST /api/v1/workflows
• POST /api/v1/workflows/{id}/steps/{step_id}/gate
• POST /api/v1/workflows/{id}/steps/{step_id}/complete
• workflow complete, fail, abort, resume, checkpoint, and enabled approval routes

WCP does not replace LangGraph, n8n, Temporal, Airflow, or your internal workflow engine. Those systems remain responsible for executing a step only after the gate permits it.

New queue-backed approval entries require Professional or above. Community and Evaluation can receive require_approval decisions but do not create new queue entries. Evaluation exposes resolve-only endpoints for draining approval entries created under a qualifying license.

See Workflow Control Plane and Retry Semantics and Idempotency.

Direct Orchestrator

Use Direct Orchestrator access only for a trusted internal platform service that deliberately needs low-level process, plan, workflow, policy, provider, or audit APIs on :8081.

This path changes the service boundary, not the meaning of the selected operation. A direct /api/v1/process call is still governed processing; a direct plan call is still MAP; and a direct workflow gate is still WCP.

Prefer the Agent for application traffic. A Direct Orchestrator caller must own service authentication, identity propagation, route selection, retry behavior, and network exposure.

See Orchestrator API Endpoints and the Authentication and Header Matrix.

Feature Comparison

Capability	Decision	Gateway	Proxy	MCP	MAP	WCP	Direct Orchestrator
Real action executed by AxonFlow	No	No	Yes	Managed connector only; checks do not execute	Yes	No	Depends on endpoint
Best boundary	Shared gateway	Existing application	Managed model request	Tool or connector	Generated plan	External workflow step	Trusted platform service
Request or step policy	Decision call	Pre-check	Managed flow	Input check	Managed plan and steps	Explicit step gate	Depends on endpoint
Output governance	Obligation plus separate check	Not automatic	Enabled managed controls	Explicit output check	Step-specific	Completion record; MCP for tool output	Depends on endpoint
Provider-call audit	Gateway must correlate it	Explicit audit call	Managed	Not its purpose	Managed per execution path	External executor reports lifecycle	Depends on endpoint
Connector-scoped policy	Add MCP	Add MCP	Add MCP for connector work	Yes	Add MCP for connector work	Add MCP for connector work	Use MCP endpoints
External orchestrator fit	Gateway-level	Possible	Possible	Composable	No	Best fit	Advanced
AxonFlow plan generation	No	No	No	No	Yes	No	Through MAP routes

No row by itself promises complete regulatory compliance or complete audit coverage. Coverage depends on the deployed policies, the endpoint used, the data submitted, caller enforcement, and enabled edition features.

Common Architectures

Existing architecture	Recommended starting point
Shared AI gateway serving many applications	Decision Mode; add MCP governance for connector-specific controls
Existing application with direct model calls	Gateway Mode; add MCP governance for tools
New application that wants one governed model endpoint	Proxy Mode; add MCP governance for connector work
LangGraph, n8n, Temporal, or Airflow workflow	WCP for steps; add MCP governance at tool boundaries
AxonFlow-generated agent plan	MAP; add MCP governance for connector steps
Internal platform automation	Agent for application traffic; Direct Orchestrator only inside the trusted boundary

Migration Paths

Gateway To Proxy

Start with Gateway Mode when an application already owns provider calls. Move selected flows to Proxy Mode when automatic provider routing, usage capture, and managed audit are more valuable than retaining the direct call.

Proxy And WCP Together

Use Proxy Mode for individual model requests and WCP for workflows whose external engine must preserve step, retry, checkpoint, and approval state.

WCP And MAP

Choose WCP when your orchestrator owns execution. Choose MAP when AxonFlow should generate and execute the plan. A system may use both for different workloads, but a single workflow should have one clear execution owner.

Recommended Defaults

1. Start a new model-backed application with Proxy Mode.
2. Add governance to existing direct model calls with Gateway Mode.
3. Add MCP governance wherever tools or connectors cross a trust boundary.
4. Use WCP for an existing external workflow engine.
5. Use MAP when AxonFlow should generate and execute the plan.
6. Use Decision Mode when a shared gateway is the reliable enforcement point.
7. Reserve Direct Orchestrator for trusted platform engineering use cases.

Related Docs

• Runtime Request Paths
• Governance Architecture and Coverage
• Runtime Surface Map
• Proxy Mode
• Gateway Mode
• MCP Connectors Overview
• Workflow Control Plane
• Decision Mode