Skip to main content

Workflow Control Plane

"LangChain runs the workflow. AxonFlow decides when it's allowed to move forward."

The Workflow Control Plane provides governance gates for external orchestrators like LangChain, LangGraph, and CrewAI. Instead of modifying your orchestrator's code, you simply add checkpoint calls to AxonFlow before each step executes.

Overview​

External orchestrators (LangChain, LangGraph, CrewAI) are great at workflow execution, but enterprises need governance controls. The Workflow Control Plane solves this by providing:

  1. Step Gates - Policy checkpoints before each workflow step
  2. Decision Types - Allow, block, or require approval
  3. Policy Integration - Reuses AxonFlow's policy engine
  4. Audit Trail - Every step decision is recorded

How It Works​

Key Point: Your orchestrator runs the workflow. AxonFlow provides governance gates at each step transition.

Quick Start​

1. Start AxonFlow​

docker compose up -d

2. Create a Workflow​

curl -X POST http://localhost:8080/api/v1/workflows \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_name": "code-review-pipeline",
    "source": "langgraph"
  }'

Note: total_steps is optional. Omit it — the server automatically sets it to the actual step count when the workflow reaches a terminal state (completed, aborted, or failed). This supports dynamic workflows like LangGraph where the number of steps is not known upfront.

Response:

{
  "workflow_id": "wf_abc123",
  "workflow_name": "code-review-pipeline",
  "status": "in_progress"
}

3. Check Step Gate​

Before executing each step, check if it's allowed:

curl -X POST http://localhost:8080/api/v1/workflows/wf_abc123/steps/step-1/gate \
  -H "Content-Type: application/json" \
  -d '{
    "step_name": "Generate Code",
    "step_type": "llm_call",
    "model": "gpt-4",
    "provider": "openai"
  }'

Response (allowed):

{
  "decision": "allow",
  "step_id": "step-1"
}

Response (blocked):

{
  "decision": "block",
  "step_id": "step-1",
  "reason": "GPT-4 not allowed in production",
  "policy_ids": ["policy_gpt4_block"]
}

4. Complete Workflow​

curl -X POST http://localhost:8080/api/v1/workflows/wf_abc123/complete

Gate Decisions​

DecisionDescriptionAction
allowStep is allowed to proceedExecute the step
blockStep is blocked by policySkip or abort workflow
require_approvalHuman approval requiredWait for approval (Enterprise)

Step Types​

TypeDescriptionExample
llm_callLLM API callOpenAI, Anthropic, Bedrock
tool_callTool/function executionCode execution, file operations
connector_callMCP connector callDatabase, API integrations
human_taskHuman-in-the-loop taskManual review, approval

Workflow Sources​

SourceDescription
langgraphLangGraph workflow
langchainLangChain workflow
crewaiCrewAI workflow
externalOther external orchestrator

API Reference​

MethodEndpointDescription
POST/api/v1/workflowsCreate workflow
GET/api/v1/workflows/{id}Get workflow status
POST/api/v1/workflows/{id}/steps/{step_id}/gateCheck step gate
POST/api/v1/workflows/{id}/steps/{step_id}/completeMark step completed (optional output + usage metrics)
POST/api/v1/workflows/{id}/completeComplete workflow
POST/api/v1/workflows/{id}/abortAbort workflow
POST/api/v1/workflows/{id}/failFail workflow
POST/api/v1/workflows/{id}/resumeResume workflow
GET/api/v1/workflowsList workflows

Step Completion Payload​

POST /api/v1/workflows/{id}/steps/{step_id}/complete accepts an optional JSON body. You can send:

  • output -- structured step output object
  • tokens_in -- actual input tokens consumed
  • tokens_out -- actual output tokens produced
  • cost_usd -- actual cost for the step

If omitted, the endpoint still succeeds and marks the step complete. The response is 204 No Content.

Fail Workflow​

failWorkflow() terminates a workflow as failed with an optional reason. Unlike abortWorkflow(), which indicates a manual cancellation (e.g., due to a policy block), failWorkflow() indicates an error condition -- the workflow encountered an unrecoverable problem during execution.

After a workflow is failed, its status becomes failed and it cannot be resumed.

POST /api/v1/workflows/{id}/fail

Request Body:

{
  "reason": "optional failure reason"
}

Response:

{
  "workflow_id": "wf_abc123",
  "status": "failed",
  "reason": "optional failure reason"
}

SDK Examples:

// Go
err := client.FailWorkflow(workflowID, "pipeline error: step 3 timed out")
# Python
await client.fail_workflow(workflow_id, reason="pipeline error: step 3 timed out")
// TypeScript
await client.failWorkflow(workflowId, "pipeline error: step 3 timed out");
// Java
client.failWorkflow(workflowId, "pipeline error: step 3 timed out");

Community vs Enterprise​

FeatureCommunityEnterprise
Step gates (allow/block)YesYes
Policy evaluationYesYes
SDK support (4 languages)YesYes
LangGraph adapterYesYes
require_approval actionReturns decisionRoutes to Portal HITL
Org-level policiesNoYes
Cross-workflow analyticsNoYes

Troubleshooting​

Gate Returns "allow" When Expected to Block​

  1. Check if the policy exists and is enabled
  2. Verify the policy scope is workflow
  3. Check if conditions match the step request

Workflow Stuck in "in_progress"​

  1. Ensure you call complete_workflow() or abort_workflow()
  2. Check for unhandled exceptions in your code
  3. Use the context manager for automatic cleanup

Connection Refused​

  1. Ensure AxonFlow Agent is running: docker compose ps
  2. Check the endpoint URL matches your configuration
  3. Verify network connectivity

Examples​

See the complete examples in examples/workflow-control/:

  • http/workflow-control.sh - HTTP/curl example
  • go/main.go - Go SDK example
  • python/main.py - Python SDK example
  • python/langgraph_example.py - LangGraph adapter example
  • python/langgraph_tools_example.py - Per-tool governance example
  • typescript/index.ts - TypeScript SDK example
  • java/WorkflowControl.java - Java SDK example
Last updated on