GEgetaxonflow
Multi-Agent Planning

Execute multi-agent plan

Multi-Agent Planning (MAP) endpoint for complex, multi-step tasks.

How MAP Works

  1. Decomposition: LLM analyzes query and breaks into sub-tasks
  2. Planning: Creates workflow with dependencies
  3. Execution: Runs tasks (parallel when possible)
  4. Aggregation: Synthesizes results into final response

Provider routing

The organization's route rows (allowed_providers, preferred_provider) bind every LLM call a plan makes, as they bind /api/v1/process (#4249): the two calls that generate the plan and each llm-call step when it runs, decided over the prompt the call sends. When several applying rows name a preferred_provider, the last applying row in evaluation order (priority descending, then newest first) wins it; allowed_providers intersect across every applying row. Rows that permit no provider refuse the call before any provider is called (no_compliant_provider, or segment_not_established), and a route that cannot be established refuses it (segment_resolution_failed, decision_enforcement_unavailable). Plan generation answers such a refusal 403; a refused step fails with the reason.

Execution Modes

  • auto: Automatically determines parallel/sequential (recommended)
  • parallel: Force parallel execution of all independent steps
  • sequential: Force sequential step-by-step execution
  • balanced: I/O-bound connector steps parallel, LLM steps sequential
  • confirm: Every step requires explicit approval (Enterprise only)
  • step: First step auto-executes, subsequent require approval (Enterprise only)

Domains

  • travel: Flights, hotels, itineraries
  • healthcare: Medical queries
  • finance: Financial analysis
  • generic: General-purpose tasks

Plan steps are automatically routed to matching connectors based on capabilities. Community: Subject to connector limits (2 connectors). Enterprise: Unlimited connectors with multi-connector fallback support.

Requires authentication: Requests must come through the Agent.

post/api/v1/plan

Request

Request body

querystring required

Natural language task description

domain'travel' | 'healthcare' | 'finance' | 'generic'

Task domain for specialized handling

execution_mode'auto' | 'parallel' | 'sequential' | 'balanced' | 'confirm' | 'step'

How to execute sub-tasks.

  • auto: Automatically determines parallel/sequential (recommended)
  • parallel: Force parallel execution of all independent steps
  • sequential: Force sequential step-by-step execution
  • balanced: I/O-bound connector steps parallel, LLM steps sequential
  • confirm: Every step requires explicit approval before execution (Enterprise only)
  • step: First step auto-executes, subsequent steps require approval (Enterprise only)
clientobject
contextobject

Response

Plan executed successfully

successboolean
plan_idstring
versioninteger

Plan version number (for optimistic locking)

workflow_execution_idstring
resultunknown
errorstring
engine'anchored'

The engine that decided a refused plan: anchored, the ADR-065 decision plane (PRD v11 §1.1). Present on the policy refusal (HTTP 403) only, with the same meaning as on /api/v1/process.

subject_typestring

The type of principal the plan was decided for. The orchestrator admits the client credential the agent's proxy authentication forwards, so it is Client on every edition. Omitted on a refusal made before a subject was admitted, and wherever engine is.

policy_bundlestring

The digest of the policy set that decided the plan. Omitted wherever subject_type is.

verdict'blocked'

blocked on the policy refusal. Omitted wherever engine is.

complexitystring

Plan complexity hint inferred from query characteristics (e.g. simple/medium/complex). Surfaced from the planning engine so callers can apply complexity-aware UI hints.

domainstring

Inferred query domain (e.g. travel, finance, healthcare). Echoes the request's domain field if provided, otherwise populated by the planning engine's domain classifier.

parallelboolean

True when the planning engine produced steps that can execute in parallel. Callers may choose to render parallel-step UIs differently from sequential ones.

statusstring

Plan lifecycle status (e.g. created, in_progress, completed, failed). Mirrors the WorkflowStatusResponse.status field for plans the orchestrator returns synchronously alongside the plan body.

Example response

{
  "version": 1,
  "complexity": "medium",
  "domain": "travel"
}

Changes

No recorded changes to this operation across all 1 revision of this API.