Choosing an Integration Mode

AxonFlow supports several runtime paths. They are not competing products; they are different places to put governance in the execution path.

• Proxy Mode for full request mediation through AxonFlow.
• Gateway Mode for pre-check plus explicit audit around your existing LLM calls.
• MCP governance for tool and connector requests that need input/output policy checks.
• Multi-Agent Planning (MAP) for AxonFlow-generated plans and orchestrated agent execution.
• Workflow Control Plane (WCP) for step-level governance around existing orchestrators and durable workflows.
• Direct Orchestrator API for teams building their own control surface on top of the Orchestrator.
• Decision Mode for centralized policy enforcement at the infrastructure gateway layer.

Most deployments use more than one. For example: Gateway Mode for existing model calls, MCP governance for tool access, and WCP for the few workflows that need pause/resume semantics.

The right choice depends less on language and more on who owns the LLM call and where you want governance to happen.

Choosing a mode as part of a real production evaluation?

If you are already comparing deployment models, approval workflows, or enterprise operating boundaries, use the free 90-day Evaluation License for self-hosted validation. If you already need full enterprise features or rollout help, apply for the Design Partner Program.

The Short Version

If your application...	Start with...
is new and you want AxonFlow to own routing + audit	Proxy Mode
already makes direct LLM calls and you want minimal disruption	Gateway Mode
needs governed connector/tool access	MCP governance
wants AxonFlow to generate and execute an agent plan	MAP
already has step-based workflows or orchestrators	WCP
needs low-level orchestration APIs for a custom control surface	Direct Orchestrator API
already runs its own gateway layers and wants structural enforcement	Decision Mode

Request Paths At A Glance

Path	Primary surface	Best for	Main trade-off
Proxy Mode	Agent /api/request and proxy routes	New apps, automatic audit, provider routing	AxonFlow owns the model-call path
Gateway Mode	Agent pre-check + audit routes	Existing apps and frameworks	You must reliably send the audit call
MCP governance	Agent MCP check-input/check-output routes	Data/tool access through connectors	Governs tool boundaries, not the whole app
MAP	Orchestrator plan routes proxied through Agent	AxonFlow-generated multi-agent plans	Best when AxonFlow owns planning
WCP	Step-gate and workflow APIs	Existing orchestrators, approvals, resume	You model workflow steps explicitly
Direct Orchestrator	Orchestrator API	Custom internal control planes	More responsibility for auth, routing, and audit wiring
Decision Mode	Decision API called by gateway layers	Enterprise gateway enforcement	Policy decision only; no model-call capture

For endpoint-level routing, see Runtime Request Paths.

How The Main Paths Differ

Proxy Mode

Your app sends the request to the Agent, and AxonFlow handles:

• policy evaluation
• provider selection and routing
• audit capture
• orchestration handoff where needed

Primary endpoint: POST /api/request

Gateway Mode

Your app keeps the LLM call. AxonFlow handles governance around it:

1. pre-check the request with the Agent
2. execute the LLM call in your app
3. send the audit result back to the Agent

Primary endpoints:

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

MCP Governance

Use MCP governance when the immediate risk is connector or tool access: SQL queries, SaaS writes, file/object retrieval, message sends, or API calls.

Primary endpoint families:

• POST /api/v1/mcp/check-input
• POST /api/v1/mcp/check-output
• GET /mcp/connectors

MCP checks compose with every other mode. A common production pattern is Gateway Mode for model calls and MCP governance for the tool calls those models initiate.

Multi-Agent Planning

Use MAP when you want AxonFlow to turn an objective into a governed plan and execute the plan through the Orchestrator.

Primary endpoint family:

• POST /api/v1/plan
• POST /api/v1/plan/execute
• GET /api/v1/plan/{id}

MAP is most useful when the application wants AxonFlow to own planning and execution structure rather than only checking individual requests.

Workflow Control Plane

Use WCP when the workload is a durable, multi-step workflow rather than a single model call.

The application or external orchestrator owns the workflow. AxonFlow owns the step-gate decisions, approvals, checkpoint boundaries, and execution records.

Primary endpoint family:

• POST /api/v1/workflows to register the workflow
• POST /api/v1/workflows/{id}/steps/{step_id}/gate before each governed step
• POST /api/v1/workflows/{id}/steps/{step_id}/complete after each completed step
• POST /api/v1/workflows/{id}/complete, /fail, /abort, and /resume for lifecycle control
• GET /api/v1/workflows/approvals/pending plus step approve/reject endpoints for reviewer queues
• GET /api/v1/workflows/{id}/checkpoints and checkpoint resume endpoints where checkpointing is enabled

Direct Orchestrator API

Use direct Orchestrator APIs only when you are building an internal platform surface that needs low-level control over planning, workflow APIs, or execution state.

Most application teams should still enter through the Agent because it centralizes auth, policy checks, and routing. Direct Orchestrator usage is for platform teams that understand those responsibilities and want to wire them explicitly.

Feature Comparison

Capability	Proxy	Gateway	MCP	MAP	WCP	Direct Orchestrator	Decision
Single request entry point	Yes	No	Tool-level	Yes	Step-level	No	Gateway-level
Automatic LLM audit capture	Yes	No	No	Plan-level	Workflow-level	Depends on caller instrumentation	No
Your app controls direct LLM call	No	Yes	Usually	No	Usually	Depends on chosen Orchestrator endpoint	Yes
Response-side governance	Yes	No	Tool output only	Step-specific	Step-specific	Depends on explicit post-step checks	No
Plan generation	Optional	No	No	Yes	No	Yes	No
Step-level approval gates	No	No	Tool-specific	Yes	Yes	Depends on using WCP/MAP gate APIs	No
External orchestrator fit	Sometimes	Yes	Yes	No	Best fit	Advanced	Yes
Gateway-layer enforcement	No	No	No	No	No	No	Best fit

Decision Guide

When Proxy Mode Is The Best Fit

Choose Proxy Mode when you want AxonFlow to be the runtime control plane for the whole model call.

Best fit:

• greenfield applications
• teams that want fewer moving parts in app code
• systems that need automatic audit capture
• projects that want MAP without stitching together multiple APIs manually

Representative flow:

curl -X POST http://localhost:8080/api/request \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "local-dev",
    "user_token": "demo-user",
    "query": "Summarize the last five failed runs",
    "request_type": "llm_chat",
    "context": {
      "provider": "openai"
    }
  }'

When Gateway Mode Is The Best Fit

Choose Gateway Mode when your application or framework already owns the model call and you want to add governance with the least architectural change.

Best fit:

• existing LangChain, CrewAI, or direct SDK integrations
• latency-sensitive paths where you want minimal extra mediation
• teams that want to adopt AxonFlow incrementally

Representative flow:

# 1. Pre-check
curl -X POST http://localhost:8080/api/policy/pre-check \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "local-dev",
    "user_token": "demo-user",
    "query": "Draft an email to a customer about their refund"
  }'

# 2. Your app calls the LLM directly

# 3. Report the audited outcome
curl -X POST http://localhost:8080/api/audit/llm-call \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "local-dev",
    "context_id": "replace-with-context-id",
    "response_summary": "Refund response drafted",
    "provider": "openai",
    "model": "gpt-4o",
    "latency_ms": 420
  }'

Important trade-off:

• Gateway Mode is only as complete as your audit discipline.
• If you skip the audit call, you create a gap in the trail.

When Workflow Control Plane Is The Best Fit

Choose WCP when your work is a workflow with multiple steps, approvals, and lifecycle events rather than a single model request.

Best fit:

• long-running plans
• step-based agent systems
• external orchestrators that need governance at step boundaries
• flows that need pause, resume, cancel, and approval decisions

Representative flow:

# Create or store a plan
curl -X POST http://localhost:8080/api/v1/plan \
  -H "Content-Type: application/json" \
  -d '{
    "query": "Investigate a suspicious payment, gather context, and draft a summary"
  }'

# Execute it
curl -X POST http://localhost:8080/api/v1/plan/execute \
  -H "Content-Type: application/json" \
  -d '{
    "plan_id": "replace-with-plan-id"
  }'

LLM Governance Differences

This is the key nuance that most teams care about:

Question	Proxy	Gateway	WCP	Decision
Does AxonFlow own the actual model call?	Yes	No	Usually not	No
Are LLM call audits automatic?	Yes	No	Workflow-level only	No (policy decisions only)
Does AxonFlow filter the returned LLM response?	Yes	No	Not as a generic response filter	No
Do UI/API policy changes for model calls apply cleanly?	Best fit	Limited	Workflow-specific	Yes (same engine)

MCP Connectors Across Modes

MCP is mode-independent in practice.

You can use connector endpoints and connector policy checks alongside any of the three integration styles:

• GET /mcp/connectors
• GET /mcp/health
• POST /api/v1/mcp/check-input
• POST /api/v1/mcp/check-output

That means a common pattern is:

• Gateway for existing LLM calls
• MCP for governed data access
• WCP only where step-level workflow control is needed

Approval Behavior

Approval behavior depends on both the mode and the tier:

• Gateway Mode does not magically create a queue in Community
• WCP can produce require_approval decisions, but queue-backed handling only activates in Evaluation or Enterprise tiers
• Enterprise removes the evaluation-tier operational limits around pending approvals and related controls

If approval workflows are central to your design, validate the target tier before you standardize on the path.

Migration Advice

Gateway to Proxy

This is the most common upgrade path.

Start in Gateway when:

• you need low-friction adoption
• your app already makes provider calls directly

Move to Proxy when:

• you want automatic audit capture
• you want AxonFlow to manage provider routing
• you want simpler request handling in application code

Proxy and WCP Together

This is also valid.

Many teams use:

• Proxy Mode for single-shot governed requests
• WCP for high-value or long-running workflows

Latency Comparison

Mode	Typical Overhead	Best For
Proxy (public endpoint)	50-100ms	Most applications
Proxy (VPC / in-region)	20-40ms	Enterprise deployments
Gateway	10-20ms	Latency-sensitive apps
Decision	10-20ms	Infrastructure gateways (same policy engine as Gateway)

Audit Logging Comparison

Audit Aspect	Proxy Mode	Gateway Mode	Decision Mode
Policy decisions	Automatic	Automatic (pre-check)	Automatic (per-decision)
LLM call details	Automatic	Requires explicit auditLLMCall()	Not captured (gateway enforces)
MCP connector access	Automatic	Automatic	Policy decision only (tool-stage)
Response content	Captured (with PII redacted)	Not captured (direct LLM call)	Not captured
Token usage and cost	Automatic tracking	Manual reporting	Not captured
Decision chain tracing	Full step-by-step trace	Pre-check decision only	Multi-layer via traceparent

Compliance Implications

Requirement	Proxy Mode	Gateway Mode	Decision Mode
100% audit coverage	Guaranteed (automatic)	Depends on SDK discipline	Guaranteed where gateways are mandatory
Response sampling	Built-in	Not available	Not available
Cost attribution	Automatic	Manual reporting	Not captured
EU AI Act Article 12	Full compliance	Requires proper SDK integration	Policy-decision audit only
SEBI/RBI audit trail	Complete	Requires proper SDK integration	Policy-decision audit only

Recommended Defaults

If you want a practical default:

1. Use Proxy Mode for new products.
2. Use Gateway Mode for existing apps that already call providers directly.
3. Use WCP only when the problem is actually workflow execution.

Decision Mode

If you already operate your own gateway infrastructure (agent gateway, MCP gateway, LLM gateway) and want centralized policy enforcement without per-application SDK integration, see Decision Mode.

Decision Mode sits on a different axis from the modes above. Gateway Mode, Proxy Mode, and WCP describe how your application talks to AxonFlow. Decision Mode describes how your infrastructure gateway talks to AxonFlow -- the gateway calls the Decision API per request and enforces the verdict. They can coexist: use Gateway Mode for services where deep, context-rich checks matter, and Decision Mode at your gateway layers for enterprise-wide structural enforcement.

Related Docs

• Getting Started
• Proxy Mode
• Gateway Mode
• Workflow Control Plane Overview
• Decision Mode
• MCP Connectors Overview