Agentic steps in a workflow

You can add large language model (LLM) reasoning to automation orchestrator workflows by using task agent steps. Task agent steps analyze data, classify inputs, and make decisions that you cannot encode as static rules.

When the workflow engine reaches a task agent step, it dispatches the configured prompt to an LLM and suspends the workflow until the model returns a response. The workflow maintains its durable state while waiting, without consuming worker resources.

You configure a task agent step with the following parameters:

  • A prompt that describes the task the model performs
  • The LLM model to use
  • Credentials for authentication
  • File attachments for additional context
  • A JSON response schema for structured output
  • A tool selection strategy
  • Integration connections for external tool access

Use task agent steps when the next action in a workflow depends on interpretation, analysis, or reasoning that you cannot express as a fixed conditional rule. Common use cases include:

  • Analyzing log files to identify root causes
  • Classifying incidents by severity or category
  • Recommending remediation actions based on observed symptoms
  • Generating Ansible Playbook parameters from natural-language requirements
  • Summarizing large data sets for human reviewers

LLM-based decision making in workflows

When a task agent step executes, the workflow engine sends the prompt to an agent that manages the LLM interaction. The agent supports three execution modes that determine how it processes the response.

You configure a system message that establishes the agent's role and behavioral constraints. Tools available to the agent are annotated with keyword relevance scores to help the model select the most appropriate tool.

Standard mode sends the prompt to the model and returns the text response. The model can call tools provided through MCP integrations, reason over the tool results, and produce a final response. Use standard mode for free-form analysis or when the output feeds into a human review step.

Structured output mode constrains the response to a JSON schema that you define in the step configuration. The workflow engine validates the response against the schema before storing it as the step output. Use structured output mode when downstream steps expect specific fields in a predictable format, such as a classification label, a confidence score, or a list of recommended actions.

Post-tool extraction mode combines tool usage with structured output. The model first calls tools and reasons over the results, then produces a final response that conforms to the JSON schema. Use post-tool extraction mode when the step must gather data from external systems before producing a structured decision.

Model-agnostic approach for LLM Providers

Automation orchestrator does not bundle or require a specific LLM provider. You bring your own model access by configuring LLM provider integrations with the credentials and endpoint information for your chosen provider.

The system works with any model endpoint that exposes an OpenAI-compatible API.

Each LLM provider integration stores the following configuration:

  • An API key for authentication
  • A base URL for the model endpoint
  • A model identifier
  • An optional provider hint

You manage LLM credentials through the same integration framework that handles other external system connections.

When you configure a task agent step, you select from the models available across your LLM provider integrations. You can assign different models to different task agent steps within the same workflow. This per-step selection lets you optimize for cost, latency, or capability based on each task. For example, use a smaller, faster model for classification and a larger model for detailed analysis.

The model-agnostic design also supports organizational requirements for data sovereignty and security. You can point LLM integrations at self-hosted model endpoints to keep data within your infrastructure, or use commercial endpoints that meet your compliance requirements. You can change providers or models without modifying your workflow definitions.

MCP (Model Context Protocol) for tool integration

Automation orchestrator implements MCP server integrations that connect task agent steps to external tool providers, extending the model's capabilities beyond text generation.

Model Context Protocol (MCP) is a standard protocol that enables LLMs to discover and call external tools during their reasoning process. You configure MCP server integrations at the environment level. Each integration points to an MCP server endpoint that exposes a set of tools. Automation orchestrator connects to MCP servers using streamable HTTP transport and authenticates with bearer tokens.

When you add or update an MCP server integration, Automation orchestrator automatically discovers the available tools on that server. During task agent step execution, the model can call any available tool as part of its reasoning process, receive the tool's response, and incorporate the results into its final answer. For example, a task agent step connected to an Ansible Automation Platform MCP server can query inventory data, check job status, or look up host variables during its analysis.

You control which tools a task agent step can access through the tool selection strategy:

All
Grants access to every tool from all configured integrations.
Selected
Grants access only to the specific tools you choose.
None
Disables tool access entirely.

Use the Selected strategy to limit the model's access to only the tools relevant to the step's purpose.

Balance AI decisions with governance and human oversight

Control AI autonomy in task agent workflows using governance features.

Automation orchestrator provides governance controls that balance AI autonomy with human oversight in workflows that include task agent steps.

Approval steps for human review. Place an approval step after a task agent step to require human review before the workflow continues. The approval step pauses the workflow and notifies designated approvers, who review the output and approve or reject it. You configure approval steps with approver users or groups, a timeout duration, and branching paths for approved and rejected outcomes. If the approval times out, the workflow stops unless the step is configured to continue on failure.

Tool selection governance. The tool selection strategy on each task agent step determines which external tools the model can access. Restrict tool access to the Selected or None strategy to prevent the model from invoking tools outside the scope of its intended task.

Prompt guardrails. Automation orchestrator validates and constrains prompts before dispatching them to the model, preventing malformed or excessively large prompts from reaching the LLM. The platform enforces a 10,000-token limit on prompts. You control prompt content in the task agent step configuration using the prompt text, system message, and optional attached files that you supply. You can add customized governance beyond the platform limit. For more information, see "Governance options" in Understand task agent nodes in workflows.

Credential isolation. Task agent steps reference credentials by identifier, not by their decrypted values. Decrypted keys are never included in the model's context or in the workflow definition.

Structured output enforcement. Define a JSON response schema on a task agent step to constrain the model's output to a predictable format. This prevents downstream steps from receiving unexpected data structures, reducing the risk of runtime errors when the response feeds into a conditional step or an API call.