How Agents and Workflows Call Each Other in Conductor

Agents and workflows can be combined so that language models handle conversational judgment while workflow engines execute predictable, durable processes with established retries, timeouts, approvals, and notifications. Using an expense bot example on Conductor, the agent identifies whether an employee is submitting a travel reimbursement or equipment request, asks for only the missing information through a human-pause tool, then starts the appropriate workflow and returns a tracking ID rather than waiting for long-running approvals; a shared status tool can later check either workflow. Workflow-launching tools implemented as typed Python functions are recommended when workflows require structured inputs such as amount, employee ID, and category, while Conductor’s more direct sub-workflow delegation is limited to a single text request field and suits workflows that can interpret unstructured prompts. The relationship also works in reverse: a workflow can use an AGENT task to obtain an agent’s judgment, such as assessing whether a low-cost expense appears suspicious, and then branch based on a concise result like FLAG or OK alongside conventional rule-based routing. This division allows agents to decide when information is sufficient or judgment is needed, while workflows retain responsibility for consistent operational execution.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.