Runtime Request Paths

AxonFlow exposes seven named request paths. They are easier to understand when grouped by who owns execution instead of treated as seven unrelated products.

This page is the canonical inventory of those paths. Use Governance Architecture and Coverage to compare what each path can enforce, and Choosing an Integration Mode for a decision tree.

The Complete Model

Caller-owned execution

Your gateway, application, MCP host, or workflow engine executes the real action. AxonFlow supplies policy decisions, scans, workflow gates, and audit records.

• Decision Mode: an infrastructure gateway calls AxonFlow as a policy decision point.
• Gateway Mode: application code checks a model request, calls the provider directly, then reports the result.
• MCP governance: an MCP host or connector checks tool input and output around tool execution.
• Workflow Control Plane (WCP): an external orchestrator checks each workflow step and reports completion.

AxonFlow-managed execution

AxonFlow owns the provider call or the multi-step execution lifecycle.

• Proxy Mode: AxonFlow evaluates, routes, calls the provider, governs the response, and records the request.
• Multi-Agent Planning (MAP): AxonFlow generates, stores, and executes a governed plan.

If your application supplies a predefined workflow for AxonFlow to execute, use POST /api/v1/workflows/execute. That is an AxonFlow-managed workflow variant, not WCP. WCP is specifically for workflows executed by an external orchestrator.

Advanced service access

• Direct Orchestrator access: a trusted internal caller uses the Orchestrator on 8081 instead of entering through the Agent. This changes the network and authentication responsibility, not the underlying governance model.

Framework integrations such as LangChain, LangGraph, Google ADK, CrewAI, and n8n are implementation adapters. They use one or more of the paths above; they are not additional runtime modes.

All Paths At A Glance

Path	Execution owner	Start with	Primary endpoint family	Use it when
Decision Mode	Your infrastructure gateway	Agent :8080	POST /api/v1/decide	A shared LLM, MCP, or agent gateway must enforce one policy plane across many applications
Gateway Mode	Your application	Agent :8080	POST /api/policy/pre-check, then POST /api/audit/llm-call	Existing application code should keep the provider call
Proxy Mode	AxonFlow	Agent :8080	POST /api/request	AxonFlow should own the governed model request from policy check through audit
MCP governance	Your MCP host or connector	Agent :8080	POST /api/v1/mcp/check-input, POST /api/v1/mcp/check-output, or /api/v1/mcp-server	Tool and connector calls need input checks, output checks, and connector-scoped policy
MAP	AxonFlow	Agent :8080	/api/v1/plan, /api/v1/plan/execute, /api/v1/plan/{id}	AxonFlow should generate and execute the plan
WCP	Your external orchestrator	Agent :8080	/api/v1/workflows, step /gate, step /complete, lifecycle routes	LangGraph, n8n, Temporal, Airflow, or another engine should keep execution ownership
Direct Orchestrator	Your trusted internal service	Orchestrator :8081	/api/v1/*, including /api/v1/process	A platform service inside the deployment boundary needs low-level control and accepts the extra auth and routing responsibility

Two proxy endpoints, two different contracts

SDK-style Proxy Mode normally enters through Agent POST /api/request. The Agent validates the application request and forwards ordinary model work to Orchestrator POST /api/v1/process; MAP request types are forwarded to the plan endpoints instead. The Agent also proxies many /api/v1/* routes for authenticated callers. Direct calls to :8081/api/v1/process are the low-level Orchestrator contract and should stay inside a trusted deployment boundary.

Default Service Boundary

Application, SDK, plugin, MCP host, or workflow engine
        |
        v
Agent :8080
        |
        +--> auth, system policies, Decision Mode, Gateway Mode,
        |    MCP checks, audit collection, and /api/v1 proxying
        |
        v
Orchestrator :8081
        |
        +--> tenant policies, provider routing, Proxy processing,
             MAP, WCP records, workflow execution, and audit search

Use the Agent as the public application boundary. Call the Orchestrator directly only from trusted internal services that deliberately take on its authentication, identity, and routing requirements.

Decision Mode Path

1. A shared infrastructure gateway receives a request.
2. The gateway calls Agent POST /api/v1/decide.
3. AxonFlow returns allow, deny, or needs_approval plus obligations.
4. The gateway enforces the verdict and fulfills supported obligations.
5. The gateway forwards the action only when the verdict permits it.

Decision Mode is a policy-decision path. AxonFlow does not automatically own the model or tool call, and the gateway remains the policy enforcement point.

Use it when a common gateway can govern many applications more reliably than per-application integration.

Key docs:

• Decision Mode
• Building a Policy Enforcement Point
• Agent API Endpoints

Gateway Mode Path

1. Application calls Agent POST /api/policy/pre-check.
2. Application stops on a denied or held result.
3. Application calls the LLM provider with its own credentials when allowed.
4. Application calls Agent POST /api/audit/llm-call with the result.

Gateway Mode is the lightest application-level integration for an existing model path. The application remains responsible for enforcing the pre-check result and reliably sending the post-call audit.

Use it for mature LangChain, LangGraph, CrewAI, DSPy, Semantic Kernel, or custom applications whose provider path should remain in application code.

Key docs:

• Gateway Mode
• Agent API Endpoints

Proxy Mode Path

1. Application calls Agent POST /api/request.
2. Agent authenticates the caller and runs the Agent-side controls.
3. Agent forwards ordinary model work to Orchestrator POST /api/v1/process.
4. Orchestrator applies tenant policy and provider routing.
5. AxonFlow calls the provider, governs the response, and records the result.

Use Proxy Mode when you want one application-facing call and automatic governance around the provider lifecycle. It is usually the cleanest starting point for a new model-backed application.

Key docs:

• Proxy Mode
• Provider Routing
• Orchestrator API Endpoints

MCP Governance Path

1. MCP host or managed connector submits tool input for evaluation.
2. AxonFlow evaluates content and connector-scoped policy.
3. The caller executes the tool only when allowed.
4. Tool output is submitted for output scanning and redaction.
5. Decision and audit records retain the tool context.

MCP governance composes with Decision, Gateway, Proxy, MAP, and WCP. It is the path that carries a real connector_type, so the static connector allowlist and per-connector dynamic policies can apply. Decision and Gateway Mode evaluate content without that managed-connector scope.

Key docs:

• MCP Overview
• MCP Policy Enforcement
• Connector Capability Matrix

MAP Path

1. Application calls POST /api/v1/plan to generate and store a plan.
2. Application calls POST /api/v1/plan/execute to execute it.
3. AxonFlow owns plan state and executes governed steps.
4. Application inspects status, versions, costs, or pending step decisions.

Use MAP when AxonFlow should own both planning and execution structure. Do not choose MAP merely because an application has several steps; use WCP when an external orchestrator already owns those steps.

For a caller-supplied workflow definition, use POST /api/v1/workflows/execute and its /api/v1/workflows/executions/* history routes. That path also runs the workflow inside AxonFlow, but it does not ask MAP to generate the plan.

Key docs:

• Multi-Agent Planning Overview
• Orchestration API Reference
• Workflow and Multi-Agent Planning API

WCP Path

1. External orchestrator registers a workflow record.
2. Before a step, it calls POST /api/v1/workflows/{id}/steps/{step_id}/gate.
3. It runs the real step only after an allow result.
4. It calls the step /complete route after the action succeeds.
5. It uses workflow lifecycle, checkpoint, and approval routes as enabled.

Use WCP when an external orchestrator owns execution but needs explicit policy gates, completion records, checkpoints, and approval-aware state. WCP does not replace LangGraph, n8n, Temporal, Airflow, or your internal workflow engine.

Key docs:

• Workflow Control Plane Overview
• Orchestration API Reference
• External Orchestrators

Direct Orchestrator Access

Direct Orchestrator access is appropriate when:

• the caller is a trusted internal service inside the same deployment boundary
• a platform service needs low-level process, plan, workflow, policy, provider, or audit APIs
• the team explicitly owns service authentication, identity propagation, retries, and network exposure

It is not a shortcut around the Agent for public application traffic. Direct access changes which service receives the request; the selected Orchestrator endpoint still determines whether the work is Proxy processing, MAP, WCP, workflow execution, or a control-plane operation.

Key docs:

• Orchestrator API Endpoints
• Authentication and Header Matrix
• Infrastructure Details

Common Combinations

Architecture	Recommended combination
Existing application with model calls and database tools	Gateway Mode plus MCP governance
New application with AxonFlow-managed model calls	Proxy Mode, adding MCP governance for connector work
Existing LangGraph or Temporal workflow	WCP, adding MCP governance at tool steps
AxonFlow-generated multi-agent execution	MAP, adding MCP governance for connector steps
Shared enterprise gateway estate	Decision Mode, adding MCP governance where connector-specific controls are required
Internal platform control surface	Agent for application traffic, Direct Orchestrator only for trusted platform automation

Control-Plane Operations Are Not Another Mode

Audit search, decision inspection, policy CRUD, provider configuration, connector administration, and evidence export are control-plane operations. Reach them through the Agent proxy where supported, or through a trusted Orchestrator connection. They do not define who executes an LLM call, tool call, or workflow step, so they are not an eighth runtime mode.

The human approval queue sits in the same category. Every governed path above can return needs_approval: the request is held rather than allowed or denied, and a reviewer resolves it through the Agent's /api/v1/hitl/queue routes or the portal. Because the queue is shared across paths rather than belonging to any one of them, it is a cross-cutting surface and not a mode of its own.

Note the edition boundary, because it changes what you observe rather than only what you are licensed for: creating queue entries requires Professional or above. On Community and Evaluation a require_approval action still holds the request, but no reviewer entry is created and the response carries approval_enqueue: "tier_disabled". See HITL Approval Gates.

Related Docs

• Governance Architecture and Coverage
• Choosing an Integration Mode
• Runtime Surface Map
• Architecture Overview
• Failure Modes