Create workflow instructions with your agent

You do not need to write a workflow instruction from a blank page. Start by completing a real task with your agent. Once the result is useful, ask the agent to turn the method you developed together into a reusable workflow.

The agent creates the first draft. Your role is to review its assumptions and decide where the workflow needs clearer constraints so another teammate can get a reliable result.

Every workflow belongs to one agent. The agent supplies the broader role and capabilities; the workflow captures the procedure and constraints for one repeatable task.

Start from a successful run

A workflow is easier to create after the agent has seen the task, the source material, your feedback, and an acceptable result.

1. Give the agent a real task and the actual input it needs.
2. Review the result and correct missing context, weak reasoning, or the wrong format.
3. When the result is good, ask the agent to extract the repeatable method.
4. Have the agent draft the workflow name, description, instruction, and any reference files it recommends.
5. Review the draft together before making the workflow public.

You can ask:

Turn what we just did into a reusable workflow for the team. Draft the name, description, and instruction. Separate the reusable method from details that only apply to this case. Before we finalize it, list the assumptions and constraints I should review.

This gives the agent the job of drafting. It gives you the job of deciding which parts must be controlled.

Instruction is a common place for constraints

The workflow instruction travels with the workflow and applies each time it runs. That makes it one of the most common places to define constraints such as required inputs, approved sources, output format, quality standards, and actions that need confirmation.

It is not the only control layer:

Do not rely on instruction text as a replacement for access controls. If an action must be technically restricted, use agent authorization and permissions as well as a clear instruction.

Review the agent's first draft

You do not need to rewrite every sentence. Focus your review on the decisions that matter to the team.

When should it be used?

• What request or situation should select this workflow?
• When should the agent not use it?
• Is the description specific enough to distinguish it from similar workflows?

What input is required?

• What must a teammate provide before the work starts?
• Which missing inputs should cause the agent to ask a question?
• Which details belong to each run instead of the permanent instruction?

Which sources and rules win?

• What is the system of record?
• Which attached file contains the approved rubric or template?
• If two sources conflict, which one takes priority?
• How should the agent label facts it cannot verify?

What must the output look like?

• Which sections or fields are required?
• What level of detail is useful?
• Does the output need citations, links, or a confidence label?
• Where should the result go when a destination is provided?

Where must the agent stop?

• Which actions require confirmation?
• Should the agent create a draft instead of sending or publishing?
• Which data must not appear in a public workflow or shared result?

These are the constraints worth making explicit. Let the agent handle the wording, then confirm that the wording reflects your decision.

A structure to review together

The agent can use the following structure for its first draft. Treat it as a review framework, not a form you must complete yourself:

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

A simple workflow may need only a few sections. A high-stakes workflow may need more explicit source, validation, and approval rules. Ask the agent to keep the instruction as short as it can be without hiding a decision the team depends on.

Example: co-create a lead qualification workflow

Suppose you ask the agent to research one inbound lead and draft a reply. During the run, you correct the company size, explain that the CRM is the system of record, apply the team's ICP rubric, and ask for a shorter email.

After the result is approved, ask the agent to turn the conversation into a workflow. The agent drafts the procedure. You then add the constraints that should survive beyond this lead:

• check the CRM before doing public research;
• use the attached ICP rubric for scoring;
• cite sources for company size, location, and current role;
• label an unverified required fact as Unknown;
• return Account summary, Evidence, ICP score, Risks, Recommended next step, and Reply draft;
• create an email draft and never send it without confirmation.

The agent can now incorporate those decisions into the instruction. You do not need to prescribe every research step. You need to make the team's sources, output contract, and approval boundary unambiguous.

Give constraint feedback in plain language

You can tighten the draft by telling the agent what must change:

• “Ask for the CRM record before starting if it is missing.”
• “Treat the CRM as the system of record when company names conflict.”
• “Every factual claim in the brief needs a source link.”
• “Keep the reply under 150 words, but adapt its tone to the inbound message.”
• “Create the email as a draft. Never send it automatically.”
• “This workflow should not run for existing opportunities.”

Ask the agent to update the workflow and summarize which constraint each change addresses. That makes it easier to catch a rule that was misunderstood or placed in the wrong section.

Keep the right things outside the instruction

Some information should not become permanent workflow text:

• customer names, one-time deadlines, and case-specific destinations belong in the run request;
• passwords, tokens, and private credentials do not belong in an instruction or attached file;
• schedules and events belong to an automation;
• technical access boundaries belong to agent authorization and permissions;
• personal feedback that only applies to one result can stay in that chat.

The instruction should carry the reusable method and behavioral constraints, not every detail surrounding the work.

Test and refine together

Run the workflow with at least two realistic inputs, preferably with a second teammate. After each run, ask:

• Did the workflow activate for the right task?
• Did it request the inputs it needed?
• Did it follow the intended source priority?
• Was the output consistent without becoming rigid?
• Did it stop at the required approval boundary?
• Is the problem repeatable, or does it only apply to this case?

Ask the agent to revise the instruction for repeatable gaps. Keep one-off corrections in the run. When the method works for someone other than its original creator, share the workflow with your team.