Enterprise Orchestration

AxonFlow Enterprise adds an operating surface around the same planning and workflow runtime that powers the public product. The important difference is that enterprise teams can manage agent definitions in PostgreSQL, run approval-aware workflows at scale, and inspect live and historical executions through portal flows and protected APIs.

For a platform team, the orchestration surface is best understood as four connected layers:

1. Agent registry APIs for database-backed agent definitions and version history
2. Multi-Agent Planning (MAP) for GeneratePlan -> ExecutePlan
3. Workflow Control Plane (WCP) for gated workflow lifecycle and approvals
4. Execution visibility APIs for replay, export, streaming status, and cancellation

What Enterprise Adds Beyond Community

Area	Community	Enterprise
Agent inventory	File-based registry	File registry plus database-backed agent catalog
Agent write APIs	No	CRUD, activate/deactivate, sandbox test, and versions
Workflow approvals	Tier-limited	Full protected operating model and enterprise limits
Execution visibility	Runtime basics	Replay, export, unified execution streaming, and portal operations
Governance rollout	Public APIs	Portal-backed policy and approval workflows tied to orchestration

Main Runtime Surfaces

Agent registry

The enterprise agent registry extends the public read-only agent endpoints with create, update, delete, activate, deactivate, sandbox test, and version-history operations.

This is how large teams move from file-only prototypes to a managed agent catalog with change history and organization scoping. See Agent Registry.

MAP two-step execution

MAP uses the two-step lifecycle:

• POST /api/v1/plan
• POST /api/v1/plan/execute

In production, these requests are typically routed through the Agent or another trusted service path so user, client, and tenant context is present. Enterprise orchestration matters here because MAP plans can pause for approval, feed unified execution tracking, and operate alongside portal-managed governance controls.

Workflow Control Plane

WCP is the enterprise surface for workflow lifecycle and per-step governance:

• POST /api/v1/workflows
• GET /api/v1/workflows
• GET /api/v1/workflows/{id}
• POST /api/v1/workflows/{id}/complete
• POST /api/v1/workflows/{id}/fail
• POST /api/v1/workflows/{id}/abort
• POST /api/v1/workflows/{id}/resume
• POST /api/v1/workflows/{id}/steps/{step_id}/gate
• POST /api/v1/workflows/{id}/steps/{step_id}/complete
• POST /api/v1/workflows/{id}/steps/{step_id}/approve
• POST /api/v1/workflows/{id}/steps/{step_id}/reject
• GET /api/v1/workflows/approvals/pending

This lets external orchestrators, internal workflow engines, and complex multi-agent applications ask a governance question before each critical step.

Execution visibility

There are two execution views worth knowing:

Surface	Best for
/api/v1/executions/...	Historical replay, step inspection, and export
/api/v1/unified/executions/...	Live status across MAP and WCP, SSE streaming, and cancellation

Enterprise teams usually use both: replay APIs for incident investigation and exports, unified execution APIs for dashboards, review consoles, and live workflow tracking.

Authentication and Scope

Enterprise orchestration is not an anonymous public surface. In practice, teams use one of two patterns:

• a customer portal session when the request originates from the protected UI
• a trusted internal service that forwards organization, tenant, and user context to the runtime

Headers to expect across the orchestration estate include:

• X-Org-ID
• tenant context derived from authenticated credentials where applicable
• X-User-ID
• X-Request-ID when you want traceability across systems

Agent management endpoints use X-Org-ID and accept tenant context derived from Basic auth for compatibility. WCP primarily keys off tenant and organization context supplied by headers or trusted middleware.

Patterns That Work Well

MAP two-step with human confirmation

Generate a plan first, inspect it, run policy checks against the intended path, and execute only when the request is ready. This fits financial assistants, regulated research workflows, and developer-agent systems where humans want to inspect a proposed plan.

MAP materialized into WCP governance

MAP and WCP are not competing architectures. In enterprise usage, MAP can decide the plan shape while WCP governs the execution path with workflow creation, per-step gates, approval pauses, and unified execution tracking.

External orchestrator with step gates

If your team already has a workflow engine, internal orchestrator, or LangGraph-style control layer, use AxonFlow as the governance plane:

1. create a workflow record with POST /api/v1/workflows
2. call POST /api/v1/workflows/{id}/steps/{step_id}/gate before each critical step
3. perform the step only if the gate decision allows it
4. record completion with POST /api/v1/workflows/{id}/steps/{step_id}/complete
5. complete, fail, abort, or resume the workflow through lifecycle endpoints

Approval-gated execution

require_approval turns policy evaluation into a workflow pause instead of a binary allow/block decision. Reviewers inspect the request, approve or reject the step, and the workflow resumes or aborts with an audit trail.

Live execution operations

Use unified execution APIs when you need a live operations dashboard, streaming status to a portal, one execution index across MAP and WCP, or cancellation during incidents.

Replay first, then export evidence

When something goes wrong, start with execution surfaces already in the platform:

• replay APIs under /api/v1/executions/...
• unified execution status under /api/v1/unified/executions/...
• evidence export for governance packs

That keeps incident response faster and leaves a cleaner trail for security, risk, and audit teams.

Governed code-generation loop

Enterprise code governance becomes more useful when paired with orchestration:

1. an agent proposes code changes
2. policy checks inspect code-secrets, code-unsafe, and code-compliance patterns
3. high-risk output can pause for approval
4. approved output is turned into a pull request through /api/v1/code-governance/prs
5. metrics and export surfaces track downstream change activity

This pattern fits platform engineering, internal developer copilots, and regulated SDLC workflows where generated code should become reviewable change evidence rather than untracked text.

Pattern Selection Guide

If you need to...	Pattern to start with
review a generated plan before running it	MAP two-step
govern another workflow engine	external orchestrator with WCP step gates
pause high-impact steps for review	approval-gated execution
run a live workflow console	unified execution APIs
investigate failures with evidence	replay plus export
govern AI-generated code	governed code-generation loop

Practical Enterprise Advice

The most successful enterprise teams do not treat MAP, WCP, approvals, and policy management as separate features. They treat them as one operating model:

• define agents in a governed registry
• enforce organization and tenant policies before execution
• pause high-impact steps for review
• stream and replay execution state during incidents
• export evidence when risk, audit, or compliance teams ask for it

That is the core difference between a demo workflow and a production multi-agent platform.

Related Docs

• Agent Registry
• Orchestration API Reference
• Execution Operations Playbook
• HITL Approval Gates
• Policy Management