Start with the workflow, not the model
Your first agent project succeeds or fails on the workflow you pick. How to choose one by volume, clear rules, systems access, a measurable baseline and contained risk.
- KKK Manoj KumarCo-founder
4 min read
The first question most teams ask us is which model to use. It's a fair question with an unhelpful answer: for your first agent, it barely matters.
What matters is the workflow. Pick the right one and a mid-sized model will do the job, and you'll have numbers to show for it within weeks. Pick the wrong one and no model will save it, because the problem was never the model.
Why the model is the least important early decision
Models change every few months. Prices fall, context windows grow and the leaderboard reshuffles. Any choice you make now will be revisited within a year, and it should be. Build so that swapping the model is a configuration change, and it stops being a decision you have to get right on day one.
The workflow is the opposite. Once you've connected the systems, written the rules down, built the eval set and shown people how to review the agent's work, that investment stays. It's also where nearly every stalled pilot we've seen went wrong: the task was too vague to evaluate, the data lived somewhere the agent couldn't reach, or nobody could say what "better" meant.
What a good first workflow looks like
After six years and 170+ automation projects, we look for five things. A workflow doesn't need all five to be worth automating eventually. Your first one should have all five.
Volume
The work happens often: dozens or hundreds of times a week, not once a quarter. Volume gives you enough cases to evaluate the agent honestly, and enough time saved for the result to matter. A task someone does twice a month is a poor first project, even if it's painful.
Rules you can write down
Ask the person who does the work today to explain how they decide. If the answer is a set of rules with a few exceptions, that's a good sign. If it's "it depends", followed by ten minutes of context only they have, the workflow needs documenting before it needs automating.
Agents handle judgment well inside clear boundaries. They handle unwritten boundaries badly, because nobody can tell whether they got it right.
Access to the systems
The agent has to read from and write to the places the work lives: the ERP, the ticketing tool, the shared inbox, the document store. Check this early. "We'll sort out API access later" is the most common reason a promising project stalls in week three.
A system with no API isn't automatically a dead end, but it is a cost. It belongs in the plan, not in a surprise.
A measurable baseline
Before you change anything, measure how the work runs today: how long each case takes, how many a person handles per day, how often something goes wrong, how long the queue gets. Without a baseline, "the agent saves time" is a feeling. With one, it's a number you can show the people who fund the next project.
Keep it simple. A week of timestamps from the existing system usually beats a month-long study.
Risk you can contain
The first workflow should be one where a mistake is cheap to catch and cheap to undo: drafting replies a person sends, matching invoices a person approves, triaging tickets a person can re-route. You want the agent's errors to show up as an approval someone rejects, not as a message a customer receives.
Higher-stakes work comes later, once you've watched the guardrails, the audit trail and the eval set do their jobs on something lower-stakes.
Workflows to skip at first
Some candidates look attractive and usually go badly as a first project:
- The rare, painful task that happens a few times a year and depends on context nobody has written down.
- Anything customer-facing with no review step. Start with the agent drafting and a person sending.
- Work spread across many teams with no single owner. The agent will raise questions, and someone has to answer them.
- A process that's about to change. Automating a workflow in the middle of a reorganization means building it twice.
A quick way to compare candidates
List three to five workflows. For each one, answer five questions with a yes or a no:
- Does it happen at least weekly, in volume?
- Could the person who does it write the rules on one page?
- Can we reach every system involved?
- Do we know how long it takes today?
- Is a mistake easy to catch before it causes harm?
Start with the one that has the most yeses. Ties go to the workflow with the clearest owner, because an owner is who makes the hundred small decisions every project needs.
Then pick the model
Once the workflow is chosen, the model becomes a practical question with a practical answer. Run your eval set against two or three candidates, compare accuracy, speed and cost per run, and choose the cheapest one that clears the bar. Revisit the choice when the next generation ships, using the same eval set.
The teams that get value from agents quickly aren't the ones with the best model. They're the ones that picked a workflow they could measure, connected it to the systems it needs, and drew the boundaries before they started.