Build a Simple Agent Workflow

The concept

The last two lessons covered designing an agent workflow on paper and deciding what permissions each tool needs. This lesson closes the gap between design and reality: you'll build one small, real, working agent-style automation end to end, using an accessible no-code platform — a built-in AI assistant with tool access, or a simple automation builder like the ones mentioned in the previous lesson. The point isn't to build something impressive; it's to prove to yourself, with a real working example, that the distance between a workflow sketch and a running automation is much smaller than it feels before you've done it once.

The build follows the exact structure from the Designing Agent Workflows lesson, now made concrete: a trigger that actually fires (not a hypothetical one), tool calls that actually execute against real accounts or test accounts, an LLM step that actually drafts something, and — non-negotiably — the human-approval gate you designed, left fully in place. This last point matters enough to repeat: the exercise is not "build the automation and also build the safety gate if you have time." The gate is part of the build, not an optional extra, and a working agent with its gate bypassed "just for testing" has taught you the wrong lesson before you've even finished the exercise.

The realistic first build is almost always narrower than the full workflow you originally imagined — and that's correct, not a failure. A single trigger, a single tool call, one draft, one approval gate is a complete, working agent in miniature; it just handles one specific case instead of every case. Expanding it to handle more triggers, more tools, or more edge cases is real work for later, once the narrow version has actually run and you've seen where it needed adjustment. Treat the first build as a proof of the pattern, not the finished product.

Documenting what you built matters as much as building it. A short record — what the trigger was, what the agent did at each step, where the approval gate sat, what worked, what needed a fix — is what lets you (or anyone else) trust the automation enough to use it again, extend it, or hand it off. An agent workflow with no documentation is one good only to the person who built it, and only for as long as they remember exactly how it works.

Worked example

A learner builds a workflow for new form submissions on a simple intake form (used for incoming customer questions). Trigger: a new row appears in the spreadsheet the form writes to. Tool call: the automation looks up the submitter's email in a separate customer spreadsheet to check whether they're an existing customer. LLM step: the AI drafts a personalized reply — referencing their name, and a note like "existing customer" or "new inquiry" depending on the lookup result — using the tone guide established in an earlier lesson's drafting exercise. Approval gate: the draft is posted to a shared document (not sent), where the learner reviews it and manually sends the final version.

Running it once end-to-end with a real test submission, the learner finds the lookup step correctly identifies an existing customer by email match, but the drafted reply addresses them by the name typed into the form field rather than the name on file — a minor mismatch (the form had "Mike," the CRM had "Michael") that's easy to miss unless specifically checked. They note this as a fix for next time: pull the name from the CRM lookup result, not the raw form input, whenever a match is found. The approval gate caught it before anything went out, which is exactly what the gate is for.

Exercise

Build your own simple agent workflow for the real task you sketched trigger/goal/steps/tools for in the Designing Agent Workflows lesson. Keep the scope narrow — one trigger, one or two tool calls, one LLM step, one approval gate — rather than attempting the full version on the first try.

Run it at least once, end to end, with the approval gate left in place and not bypassed, using a real or realistic test case. Document three things afterward: what worked as designed, what needed an adjustment (like the name-mismatch example above), and one specific improvement you'd make before running it a second time.

Recap

• Building a simple agent workflow is closer to the design you already sketched than it feels — this exercise proves the pattern with one small, real, working automation.
• The approval gate is part of the build, not an optional add-on — leave it in place for the test run, not bypassed "just this once."
• A narrow first build that actually runs, plus honest documentation of what needed fixing, is more valuable than an ambitious design that never gets tested.

Resources

• Zapier: "Build your first AI-powered Zap" — https://zapier.com/apps/chatgpt/integrations
• Make: "Getting started with scenarios" — https://www.make.com/en/help/scenarios/creating-a-scenario
• Anthropic: "Building effective agents" — https://www.anthropic.com/research/building-effective-agents