Plan workflow automation

Completed

In this unit, you learn to distinguish two ways an agent can respond to a request: by reasoning through a response using its model and available context, and by running a workflow that follows a defined, repeatable process. Choosing the right approach for each part of an agent's behavior helps you build systems that are both flexible and reliable.

Priya's task notification agent must reason through questions like "Which tasks are overdue?" but must always send the same email format when a notification is needed. Understanding where generative reasoning helps and where deterministic automation serves better guides her design choices.

Understand agent reasoning

When an agent powered by the GitHub Copilot harness receives a request, it interprets the goal and creates a plan. The agent considers its instructions, conversation context, available knowledge, and tools. It can call tools, observe results, and adjust the plan as it works toward the goal.

Agent reasoning works well for:

• Answering questions whose answers change depending on context.
• Summarizing, classifying, or comparing information.
• Choosing between tools based on what the user requests.
• Gathering missing information before taking an action.
• Adapting phrasing and detail level to the user's question.

The agent produces different outputs for different inputs because the model interprets each request in context. This flexibility is the strength of agent reasoning.

Choose deterministic automation

A workflow runs a fixed sequence of steps in a defined order. Given the same inputs, it produces the same output every time. The agent calls the workflow with specific inputs, the workflow runs its steps, and it returns a result. The agent doesn't interpret or vary those steps.

Use a workflow when one or more of these conditions applies:

• The action requires specific fields, formatting, or step order.
• The process uses a connector to send a message or create, update, or retrieve a record.
• The process applies fixed validation, approval, or business rules.
• The action needs user confirmation before it runs.
• Audit or compliance requirements demand a consistent execution record.

A notification email with a prescribed format is a clear fit for a workflow. If Priya lets the agent compose the email freely, the format might vary between conversations, fields might be omitted, or the recipient address might be inferred incorrectly.

Compare the two approaches

Consideration	Agent reasoning	Deterministic workflow
Output consistency	Varies based on context and model interpretation	Same steps, same structure, same output
Input flexibility	Handles vague or partial input	Requires defined inputs
Transparency	Interpretation can be hard to predict	Steps are visible in the designer
Auditability	Conversation history	Workflow activity with step-level details and timestamps
Best for	Reasoning, summarizing, choosing	Executing, sending, creating, updating

Neither approach is universally better. Most useful agents combine both. The agent reasons about what to do; a workflow executes the predictable action.

Combine both approaches in a single interaction

Notification agents often use both approaches together:

1. The agent reasons through the conversation, collects the required details, and decides a notification is appropriate.
2. The agent calls a workflow with those details as defined inputs.
3. The workflow sends the notification the same way every time and returns a confirmation.
4. The agent uses the confirmation to acknowledge the outcome to the user.

This pattern keeps the agent's reasoning flexible while making the execution predictable and auditable. Priya uses this pattern for the Contoso task notification agent: the agent handles the conversation and decision, and a workflow handles the email.

Note

Think of an action your agent might need to perform. Does the outcome need to be the same every time, or should it adapt to the situation? Use that distinction to decide whether a workflow fits.

Design the workflow contract

A workflow needs a clear definition of the information it receives from the agent and the result it returns. This definition is the workflow's contract.

For example, the task-notification workflow receives a recipient email address, task title, task details, and due date. It uses those values to send an email, and then returns a status and confirmation message to the agent. Defining these values before building the workflow makes the workflow easier to configure and test.

A Copilot Studio workflow that an agent calls uses two fixed steps:

• When an agent calls the flow: Defines the inputs that the agent sends to the workflow.
• Respond to the agent: Defines the outputs that the workflow returns to the agent.

Actions run between the trigger and response steps. The trigger inputs are available to these actions as dynamic content. For example, the email action uses the Recipient Email input in its To field and the Task Title input in its subject. After the actions finish, the response outputs tell the agent what happened so it can give the user an accurate result.

Define trigger inputs

A trigger input is a named value that the agent provides when it calls the workflow. For each input, provide:

• Input name: A short noun phrase that identifies the value, such as Recipient Email, Task Title, or Due Date.
• Description: A plain-language sentence that explains the value and its expected format. The agent uses this description to find the value in the conversation or ask the user for it.

Choose an input type that matches the data:

Input type	Use for
Text	Names, email addresses, descriptions, and short strings
Number	Quantities, identifiers, and numeric values
Boolean	Yes or no flags
Date and time	Timestamps and calendar dates
File	Binary attachments used with file-capable connectors

Priya's notification workflow uses four text inputs:

Input name	Description
Recipient Email	The complete work or school email address of the person who should receive the notification. Do not guess or infer this value.
Task Title	The short title of the task being notified.
Task Details	A brief description of what the task involves, including relevant context.
Due Date	The due date stated as the user provided it, such as October 15, 2026.

Using text for the due date avoids date-format parsing issues and lets the workflow place the user's value directly in the email body.

Define response outputs

A response output is a named value that the workflow returns to the agent. For each output, provide an Output name and either a static value or dynamic content from a workflow step.

For a notification workflow, two outputs serve most scenarios:

Output name	Value	Purpose
Status	A static value such as Email sent	Tells the agent that the action completed.
Confirmation	A message composed from dynamic content	Gives the agent a meaningful result to relay to the user.

Keep the contract clear and minimal

The agent reads input descriptions to determine which conversation values to use. Compare Email address with The complete work or school email address of the person who should receive the task notification. Do not guess or infer this value. The second description specifies the purpose, context, and expected value.

Include only the inputs the workflow needs. If the email format never changes, embed the template in the connector action instead of adding a template input. A minimal, well-described contract reduces missing and misinterpreted values.