AI Agent Design Patterns: A Practical Guide for Solo Operators
Most solo operators try to bolt AI onto existing tasks and end up with fragile scripts that break when the prompt changes or the API rate limit hits. After reading this, you’ll know how to structure an agent so it handles retries, manages state, and stays within cost limits. You’ll also see a concrete example you can copy today.
What most guides get wrong about AI agent design patterns
Many tutorials treat an agent as a single prompt wrapped in a loop. They ignore state, error handling, and cost tracking. The result is a demo that works in a notebook but collapses under real load.
I’ve seen agents that keep re‑sending the same request because they never store a simple “last‑run” flag. That wastes tokens and can trigger rate limits fast.
One concrete gripe: the way Make hides the error log behind three clicks made me miss a failed webhook for two days. I only noticed when a client complained about missing leads.
On the love side: I love how the built‑in retry policy in Pipedream automatically re‑queues a failed step after 30 seconds, which saved me from manual retries during a weekend launch.
Price note: $29/mo is fair for the automation runtime on Pipedream, but $199/mo for the team plan feels ridiculous for what you get—most solo users never need the extra seats.
That’s the gap most tutorials leave.
Core patterns you actually need
Think of an agent as a small state machine with three layers: input handling, reasoning, and output dispatch. Each layer can be swapped independently.
First, the input layer normalizes whatever arrives—email, webhook, or chat message—into a clean JSON payload. A simple function that strips whitespace and validates required fields does the job.
Second, the reasoning layer calls the LLM with a prompt that includes the current state. Keep the prompt short; long prompts increase latency and cost. I’ve found that a system message plus a single user message works for most classification tasks.
Third, the output layer decides what to do with the LLM’s answer: send an email, update a CRM, or trigger another workflow. Wrap this in a try/catch and push failures to a dead‑letter queue for later inspection.
These three layers map neatly to tools you probably already use: a webhook endpoint (input), a serverless function that calls GPT‑4o (reasoning), and a step that posts to Zapier automations or Make (output).
How to debug when this breaks
When an agent stops working, start at the edges. Check the input payload first—did the webhook send the expected fields? A quick log of the raw request will show if something changed upstream.
If the input looks good, move to the reasoning layer. Look at the LLM response: is it empty, malformed, or hitting a safety filter? Most providers return an error code you can catch.
Finally, verify the output step. Did the HTTP call to your CRM return a 2xx? If not, the failure is likely a permission or rate‑limit issue.
I keep a one‑line health check that pings each layer and writes a timestamp to a Google Sheet. If any timestamp is older than five minutes, I know exactly where to look.