Run Mistral Agent Workflows from Kestra with Completion Polling

Mistral workflows package agent logic, but something still has to start them with the right inputs, wait for the outcome, and react to it. This blueprint makes Kestra that something: io.kestra.plugin.mistral.RunWorkflow starts a registered workflow with an input map built from flow inputs, polls the execution until it reaches a terminal state, and exposes the status, remote execution ID, result, and timing as task outputs that flow straight into a Slack confirmation.

How it works

1. run_workflow (io.kestra.plugin.mistral.RunWorkflow) calls the Mistral API with workflowIdentifier from the flow input and an input map carrying the document text and language. With wait: true the task polls every pollInterval (five seconds) until the remote execution reaches a terminal state, and throws a timeout after waitTimeout (fifteen minutes).
2. On completion the task exposes {{ outputs.run_workflow.status }} (COMPLETED, FAILED, or CANCELED), {{ outputs.run_workflow.executionId }}, {{ outputs.run_workflow.totalDurationMs }}, the start and end timestamps, and the JSON serialized result.
3. notify posts the status, duration, and both execution IDs to Slack as plain scalars.
4. The errors block posts a distinct Slack alert on failure or timeout, so a hung agent workflow surfaces instead of silently waiting.

What you get

• One synchronous building block: start a Mistral workflow and hold the Kestra execution until the remote one finishes.
• The remote result and status as first-class outputs, ready for downstream branching or storage.
• Timeout protection: a workflow that never terminates fails loudly after fifteen minutes instead of blocking forever.
• Traceability from the Kestra execution ID to the Mistral execution ID in every notification.

Who it's for

• Teams embedding Mistral agent workflows inside larger data or business pipelines.
• Platform engineers who need agent runs to be scheduled, retried, and audited like any other job.
• Anyone replacing hand-rolled polling loops against the Mistral API.

Why orchestrate this with Kestra

Calling the run endpoint is one HTTP request; production needs the rest: secrets for the API key, typed inputs so anyone can launch a run from the UI, polling with a hard timeout, downstream tasks that consume the result, and a searchable history of every run and its outcome. Kestra declares all of it in one flow, and the same pattern chains agent workflows with databases, warehouses, and notifications.

Prerequisites

• A Mistral API key with access to Mistral workflows.
• A registered Mistral workflow whose name or ID matches workflow_identifier, accepting text and language inputs, or adjust the input map to your workflow's contract.
• A Slack incoming webhook for confirmations and failure alerts.

Secrets

• MISTRAL_API_KEY: Mistral API bearer token.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Set workflow_identifier to a workflow registered in your Mistral account and adjust the input map keys to match it.
3. Execute the flow and check the Slack message for the terminal status and duration.

How to extend

• Branch on {{ outputs.run_workflow.status }} with an If task to handle FAILED runs differently from COMPLETED ones.
• Parse {{ outputs.run_workflow.result }} with a small script task to extract structured fields for downstream tasks.
• Set wait: false for fire-and-forget starts and pair with the WorkflowEvents trigger blueprint to react on completion.
• Use deploymentName to pin runs to a specific workflow version during rollouts.

Links

• Mistral plugin documentation
• Mistral documentation