Last year I was on a session with a client named Evan. He runs a company called Arena Hall and he wanted to automate his meeting processing — summaries, action items, follow-up emails, the whole thing.
He asked me what information I’d need to build the agents.
I told him: ” Forget the information. Show me what you want the output to look like.
He stared at me for a second.
“Like, what do you mean?”
“If you just finished a meeting with someone, what should the summary document look like? Just make me a fake one. Make it up.”
He spent five minutes typing. And when he handed it to me, the whole project became obvious. The fields were right there. The structure was right there. The logic was right there. Building the agent was almost mechanical from that point.
That single conversation changed how I teach agent design.
Why Most Agent Builds Stall
Here’s the pattern I see constantly in my workshops.
Someone decides they want to automate something. Maybe it’s meeting notes. Maybe it’s email triage. Maybe it’s a weekly report.
They open the AI tool, look at all the available actions and integrations, and immediately get overwhelmed. What should I connect? What should the trigger be? How do I prompt this thing?
They’re asking the tool what’s possible instead of telling the tool what they want.
It’s like walking into a kitchen and asking “what can I make with all this equipment?” instead of deciding you want to make pasta and working backwards from there.
The output has to come first.
The Fake Example Method
I call this “design backwards,” and it works for any kind of agent you want to build.
Step 1: Write out what the finished output should look like.
Don’t describe it. Don’t write requirements. Actually make a fake sample of it. If it’s a meeting summary, write a fake meeting summary. If it’s a daily briefing, write a fake daily briefing. Be specific — include the sections, the format, the level of detail.
This takes 5-10 minutes and is the most valuable thing you’ll do in the whole project.
Step 2: From the example, reverse-engineer the inputs.
Look at your fake output and ask: what information does the agent need to produce this? A meeting summary needs the transcript. A daily briefing needs your calendar. A deal tracker needs your CRM data.
Now you know exactly what to connect.
Step 3: Build the agent to reproduce your example consistently.
That’s really all an agent is. A machine that takes the inputs you identified and produces the output you designed. If your example is clear and specific, the agent’s job is easy to define.
Why the Output Has to Come First
A few months ago I showed a team at a real estate company what an automated meeting brief looked like — full context on the people, recent activity, relevant background. The guy I was demoing to immediately started naming 30 or 40 different applications across his business.
Before I showed him the output, he couldn’t imagine what was possible. After he saw it, the ideas were obvious.
This is what I’ve noticed working with clients across industries. People can’t spec something they’ve never seen. When you ask “what should the agent do?” you get vague answers. When you show them a sample output and ask “does this look right?” they can give you incredibly precise feedback.
The sample output is a design tool. It creates shared language between you and the system you’re building.
The Schema Follows the Sample
Once you have a good fake example, something else becomes clear: the structure.
If your meeting summary sample has a “Key Decisions” section, an “Action Items” section with owner names and deadlines, and a “Background on Attendees” section — you’ve just defined a schema. Those are your fields. That’s the consistent structure the agent will produce every time.
This is similar to how good database design works. Get the schema right and wiring everything together later is mostly execution. Skip the schema and you’ll be rebuilding constantly.
I’ve seen people spend weeks trying to get agents working “right” when the real problem was that they never defined what right looked like. The agent was improvising because it had no example to reproduce.
A Simple Test
Before you start building anything, ask yourself this: can I write a fake example of what the output should look like in 10 minutes or less?
If yes, you’re ready to build.
If no, you don’t have enough clarity yet. Keep talking to stakeholders, think through the use case more carefully, or just live with the process manually for a week and observe what you actually need.
The 10 minutes you spend on a fake example will save you hours of rebuilding later.
And if you’re teaching someone else to build agents — for their business or their team — this is the exercise that makes everything click. Show them the fake example first. The tool questions answer themselves.
Try This Today
Pick one thing you’ve been wanting to automate. Maybe it’s been sitting on your list for weeks.
Open a blank doc. Spend 10 minutes writing what the finished output should look like. Be specific. Include sections, format, level of detail.
Then look at what you wrote and ask: what does the agent need to produce this?
That’s your build plan.
