An agent is a configuration, not a colleague
Agents have names because a list of identical roles is unusable, not because a person stands behind them. They get abstract marks instead of faces, deliberately.
Most of this product is one decision repeated: a person should be able to read what is about to happen, before it happens.
Handing work to software is easy to sell and hard to trust. The usual pitch is that you stop looking — assign the work, close the tab, hope. That is the part we did not build.
A run drafts its plan first: the steps, and which agent owns each one. Then it stops and waits. You approve it, edit it, or throw it out, and only then does anything execute or cost anything. Teams doing work you have already checked a hundred times can approve confident plans on their own, and still stop when a plan is not confident enough.
See how a run worksAgents have names because a list of identical roles is unusable, not because a person stands behind them. They get abstract marks instead of faces, deliberately.
Approval is the default, auto-approval is the opt-in, and the confidence threshold under which a team stops anyway is yours to set.
Thumbs down teaches nothing. What you write becomes one imperative sentence handed to later runs, so the same mistake does not come back.
The features page carries a section on what these agents are not, for the same reason: a claim we cannot show you inside the product does not belong on the site.
Describe it once and it gets done every time it arrives. Before the colleagues start, they show you exactly what they will do.
The free plan is there. No card to start.