Skip to main content
Time required: 30–45 minutes
You will build: a support-ticket workflow that classifies a request, drafts a response, and pauses for approval before an external action.
This is a workshop, not a reference page. You will make decisions, run the workflow, inspect what happened, and improve one part of the design. By the end, you should be able to explain why each node exists and where a human should remain in control.

​
What you will learn

You will practice how to:
  • Turn a business goal into a workflow that can be inspected.
  • Choose an AI connection and model for a specific job.
  • Review generated agents, prompts, tools, and connections instead of accepting them blindly.
  • Add a human checkpoint before a sensitive or irreversible action.
  • Test normal, ambiguous, and adversarial inputs.
  • Use the execution trace to improve the workflow.
  • Save a private version that another teammate can safely review.

​
Before you start

You need:
  • A Blueprint account and access to a workspace where you can create Blueprints.
  • An active AI connection. A platform-managed connection is fine for this workshop.
  • Permission to create and execute Blueprints.
  • Synthetic sample data only. Do not paste a real customer record or secret into the exercise.
Open Blueprint, then choose Blueprints or use Create a Blueprint.

​
The learning challenge

Build this workflow:
When a new support ticket arrives, classify it by urgency and topic, draft a suggested reply using the support policy, and pause for a human to approve before sending anything.
Keep this goal visible while you work. It has five useful parts:
Why this matters: A vague goal produces a vague workflow. A good goal tells Blueprint what starts the work, what information is allowed, what “done” means, and where judgment belongs.

​
Lab 1: Start from a precise goal

The creation page lets you describe the outcome in plain English. Start with the goal above rather than with a list of technologies. Blueprint goal selection screen
  1. Open Create a Blueprint.
  2. Enter the workshop goal in the goal field.
  3. Read the goal once as if you were the person who will approve the final response.
  4. Add the phrase “do not send or change anything until a human approves” if the workflow could reach an external action.
  5. Confirm that the goal names the information the workflow may use.

​
Pause and predict

Before selecting Generate Blueprint, predict the steps you expect to see:
  1. Input or trigger
  2. Classification
  3. Policy retrieval or context
  4. Drafting
  5. Human approval
  6. Final action or handoff
Write your prediction down. Comparing it with the generated design will teach you where Blueprint’s suggestions are helpful and where they need review.

​
Lab 2: Choose the AI connection deliberately

Select an active AI connection and model. For this workshop, choose a model that can follow structured instructions and produce consistent text. Ask yourself:
  • Does the connection belong to me, my organization, or the platform?
  • Is the selected model approved for the data this workflow will handle?
  • Do I need structured output, tool use, vision, or a larger context window?
  • What will happen if the connection reaches a quota or becomes unavailable?
Do not put a provider key in the goal, a prompt, a node input, or a screenshot. Connections are configuration, not content.

​
Lab 3: Generate, then review the design

Select Generate Blueprint and read the proposed workflow from left to right. Do not run it yet. Blueprint editor workflow For every node, answer three questions:
  1. Responsibility: What single job does this node perform?
  2. Input: Which fields does it need, and are they actually available?
  3. Output: What does the next node receive, and how will you know it is valid?
Look for common design problems:
  • One agent is trying to classify, retrieve, draft, and send at once.
  • A node receives the entire payload when it needs only one field.
  • The workflow can send an external message without an approval step.
  • A model is asked to invent policy instead of using an approved source.
  • A branch has no explicit fallback for low confidence or missing data.
Try it: Rename one generated step so its purpose is obvious to a new teammate. If the name becomes a paragraph, split the responsibility.

​
Lab 4: Compare generated mode with manual mode

Open Manual Creation (expert mode) in a second tab or inspect it after reviewing the generated design. Blueprint manual creation mode Manual mode is useful when you already know the workflow shape or when governance requires an explicit design from the start. It is not automatically safer: a manually assembled workflow still needs inputs, output validation, permission review, and testing. Sketch the workshop workflow manually:
  • A trigger or input
  • A classification step
  • A policy or knowledge step
  • A drafting step
  • A human approval step
  • A final handoff
Then compare your sketch with the generated design. Which version is easier to explain? Which one exposes the risky action more clearly? Keep the version that makes the control points easiest to inspect.

​
Lab 5: Add a human checkpoint

The approval step is the most important learning moment in this workshop. Place the checkpoint before any step that could:
  • Send a message or email.
  • Create, update, or delete a record.
  • Publish content.
  • Spend money or change a customer’s status.
  • Expose information to a new audience.
Define what the reviewer should see:
  • The original ticket.
  • The classification and confidence.
  • The policy passages used.
  • The proposed response.
  • The exact recipient and action.
  • Approve, revise, reject, or escalate choices.
A human checkpoint is not just a button. It is a decision boundary. If the reviewer cannot see enough context to make a good decision, move more evidence into the review step or redesign the workflow.

​
Lab 6: Run three test cases

Use synthetic inputs that exercise different paths.

​
Case A: routine request

Expected behavior: classify as a routine account or technical request, draft a response using the approved support policy, and wait for approval.

​
Case B: sensitive request

Expected behavior: route to a higher-risk path and stop at human approval. The model should not claim that deletion happened.

​
Case C: prompt injection attempt

Expected behavior: treat the message as untrusted input, refuse the unsafe instruction, and keep tools and private context out of the response. Run each case through Test & Debug. Change one input at a time so you can tell which behavior caused an improvement or regression. Blueprint Test & Debug view

​
Lab 7: Read the execution trace

Do not judge a Blueprint only by its final answer. Inspect the path it took. For one run, record:
  • The input received by each node.
  • The output produced by each node.
  • Which model and connection were used.
  • Latency or duration where shown.
  • Token or usage information where shown.
  • Any retrieved source or tool response.
  • Where the human checkpoint paused the run.
  • The first node that failed or produced an unexpected result.
Then ask:
  • Did the workflow pass more data than necessary?
  • Did a later node receive a well-formed output?
  • Did the model use evidence or rely on unsupported assumptions?
  • Did the approval step show the information a reviewer needed?
  • Could a smaller, clearer prompt produce the same result?

​
Lab 8: Improve one thing and rerun

Make exactly one change:
  • Clarify the classification labels.
  • Require a structured response.
  • Add a confidence threshold.
  • Narrow the policy source.
  • Move the human checkpoint earlier.
  • Remove a tool that the workflow does not need.
Run the same three cases again. Compare the first and second runs. You are learning to improve a system, not to chase one perfect answer.
Reflection: Which change improved reliability? Which change only changed the wording? Which behavior still needs a human decision?

​
Lab 9: Save a private version

When the workflow is understandable and the three cases behave as expected:
  1. Save a private version with a meaningful description.
  2. Record the model, connection, Knowledge Base, tools, and approval point.
  3. Share it with one reviewer rather than publishing it broadly.
  4. Give the reviewer the three test cases and the expected behavior.
  5. Define how you will restore the last known-good version if the next change is worse.
Do not publish an unfinished workflow to Public Libraries. A reusable asset should explain its inputs, outputs, dependencies, permissions, and limitations.

​
Completion check

You are finished when you can answer yes to all of these:
  • I can explain the workflow in one sentence.
  • Each node has one clear responsibility.
  • The selected model and connection are approved for the intended data.
  • The workflow uses only the inputs and sources it needs.
  • Unsafe or irreversible actions pause for a human.
  • I tested routine, sensitive, and adversarial inputs.
  • I inspected at least one execution trace.
  • I changed one instruction and compared the rerun.
  • I saved a private, reviewable version.

​
If your result is not what you expected

  • The generated workflow is too broad: rewrite the goal with an explicit outcome and control point.
  • The model invents policy: connect an approved Knowledge Base and require evidence-backed answers.
  • The workflow skips approval: move the checkpoint immediately before the external action.
  • The output changes shape: define a small, explicit output contract and test several inputs.
  • A run fails: inspect the first failing node, input type, connection, model availability, and plan limits before retrying.

​
Next practice

Fork or open a related asset from Public Libraries, then compare its graph and test cases with the workshop design. Continue with Build a Searchable Knowledge Base: A Learning Lab or Build and Publish a Grounded Chatbot: A Learning Lab.