This is a log, not a tutorial. Building an agent workflow for the first time teaches you things no framework documentation will, mostly because the documentation assumes the happy path and your queue does not. Below is what actually happened over one week, including the day I made a mistake that cost real cleanup time.
Picking the queue
I did not start with a tool. I started with a list of candidate tasks and ran the frequency times cost times stability formula against each one. The winner was a support ticket triage queue: high frequency, moderate cost per ticket, and stable enough in format that a model could parse it without guessing. The loudest complaint in the office was actually a different process, a monthly reporting job, and I almost built for that instead. It would have been the wrong target: low frequency means low leverage, no matter how annoying the task feels in the room.
Day one: confirming it needed to be an agent at all
Before writing any code I ran the ten-minute agent-or-workflow test, and the honest answer was mostly no. Triage has three branches (route to billing, route to engineering, or escalate), and two of those three are deterministic enough to be a fixed pipeline with a classification step. Only the escalate branch needed anything resembling judgment, where the model decides whether a ticket’s tone and history warrant skipping the queue. I built a workflow with one agentic decision point, not an agent for the whole thing. That distinction saved a week of flexibility I would otherwise have had to debug later.
Day two: building the thing
The build itself took less time than deciding what to build. Classification, a retrieval step to pull the customer’s last three tickets, and a routing action: three components, wired linearly, with the model only making a call on the escalate branch. The retrieval step mattered more than I expected going in. The model’s first-draft routing without ticket history was noticeably worse than with it. What I built is a workflow that fetches state before acting, not one that remembers anything across sessions, and that is a more honest description of it.
Day three: the mistake
On day three I removed the review step for anything the model routed to billing, because billing routing looked reliable in testing and I wanted to see the queue move without a human checking every ticket. That was the mistake. Billing and a related but different category, refund disputes, share enough vocabulary that the model started misrouting disputes as plain billing questions, and those tickets sat unattended until someone noticed the backlog growing. Nothing crashed. No error fired. It just quietly routed the wrong tickets to the wrong desk for most of a day before a human caught the pattern by eye.
The fix was not a smarter model. It was putting the checkpoint back in a smarter place: the ticket, not billing in general. That is the actual design question in designing the human handoff: not “should a human check this” in the abstract, but which specific decision is costly enough to be worth the latency of waiting for a person. I had treated the checkpoint as a blanket safety net instead of a targeted one, and removed it entirely instead of narrowing it.
Why I did not add a second agent to fix it
The instinct after a misrouting problem is to add a specialist: a second agent whose only job is catching dispute-shaped tickets before they hit the billing classifier. I did not do this, because a multi-agent system adds coordination cost immediately and capability only sometimes, and the dispute problem was a classification boundary issue, not a missing skill. Fixing the prompt and narrowing the review checkpoint solved it in an afternoon. Adding a second agent would have meant two components disagreeing about edge cases instead of one component being wrong in a visible, fixable way.
What the week actually cost
Scoping took longer than building. Building took less time than fixing the mistake I introduced myself on day three. That ordering is not unusual, and it is worth planning for: an agent pilot in production rarely fails on the first version. It fails on the first change you make after it looked stable. The honest estimate for a first workflow is not “how long to build it” but “how long to build it plus however long it takes to catch the first thing you removed too early.”
None of this required a platform, a vector database, or a second model. It required a queue worth automating, a narrow decision for the model to own, and a checkpoint sized to the actual risk instead of removed on the strength of a good afternoon of testing.