Choosing an Integration Mode

AxonFlow supports three primary integration patterns:

• Proxy Mode for full request mediation through AxonFlow
• Gateway Mode for pre-check plus explicit audit around your existing LLM calls
• Workflow Control Plane (WCP) for governed, multi-step workflow execution

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

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
already has step-based workflows or orchestrators	Workflow Control Plane

How The Three Modes 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

Workflow Control Plane

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

The Agent remains the single entry point, while /api/v1/plan* routes are proxied to the Orchestrator.

Primary endpoint family:

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

Feature Comparison

Capability	Proxy Mode	Gateway Mode	Workflow Control Plane
Single request entry point	Yes	No	Yes
Automatic LLM audit capture	Yes	No	Workflow-level audit
Your app controls direct LLM call	No	Yes	Usually yes
Response-side governance by AxonFlow	Yes	No	Step-level, not direct response filtering
MAP / plan generation	Yes	No	Plan/workflow execution surface
Step-level approval gates	No	No	Yes
Works with external orchestrators	Sometimes	Yes	Yes

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
Does AxonFlow own the actual model call?	Yes	No	Usually not
Are LLM call audits automatic?	Yes	No	Workflow-level only
Does AxonFlow filter the returned LLM response?	Yes	No	Not as a generic response filter
Do UI/API policy changes for model calls apply cleanly?	Best fit	Limited	Workflow-specific

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

Audit Logging Comparison

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

Compliance Implications

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

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.

Related Docs

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