At least six different kinds of software are being sold as "AI agents" right now, and most of the evaluations I'm seeing put products from different categories side by side, get confused when nothing lines up, and stall.
Here's the map.
The reason comparisons stall is that these aren't substitutes for each other. A dot and a Zapier Agent aren't competing for the same job any more than a new hire and a spreadsheet macro are, and a feature grid that puts them in the same columns is going to produce nonsense.
What all six have in common matters more than how they differ. Every one of these products, at every layer, has settled on the same unit: a named agent with a job description, a trigger or a schedule, a budget, a set of credentials, and an approval gate in front of anything with consequences. They each got there on their own.
So before you evaluate any product, check whether you can fill in those five fields for your own work.
This is where it usually falls apart. A company buys a seat on one of these, or stands up a pilot with a couple of engineers, and nobody has decided which of their dozens of recurring processes to hand it, who owns it when it's wrong, what it's allowed to touch, how they'll know if it's paying for itself, or what the person whose work it absorbed does on Tuesday. Comparing platforms is easier than answering those five questions, so that's where the time goes. But a vendor can't answer them for you. They've never seen your processes.
There's a timing problem too. Tool-specific advice has a shelf life of months. Every vendor on that list will ship something that reshuffles the comparison before your evaluation ends, and if the evaluation was about the tools, you get to start over. The answers to the five questions don't change when the products do. A job description for your intake queue is just as true after the next launch as before it.
We run this way ourselves. A chief of staff agent reads my email and meeting notes. Claude Code picks up tickets from our board and runs them in our CI pipeline, with a merge request as the approval gate. Our signal system produces nightly leads and drafts the first message. We didn't start any of it with a platform decision. We wrote down the job, the trigger, the budget, the credentials, and the gate for each one, then picked whatever runtime fit. The runtime underneath has already changed once and the written-down parts carried over.
The cost of doing it this way is that it's slower to start than buying a seat. Writing the delegation map takes a couple of weeks with the people who run the processes, and it's exactly the kind of work that feels skippable. The companies that skip it buy the seat, point it at nothing in particular, and cancel it three months later because it didn't do much, which is true, because nobody told it what to do.
Most of you are already running a pilot with a few people on something from that list, so the bet is already placed. The question is whether the next six months go to comparing vendors or to writing down the jobs.
Before you compare another platform, pick one recurring process and write the five fields for it:
If you can write all five, you're ready to buy, and the platform choice gets easy because you finally know what it has to do. If you can't, buying a platform won't help yet.
Which process would you hand an agent first, and could you write its job description today?