Every roadmap review this year has a slide with the word “agentic” on it. Fewer of them have a clear answer to the question that actually matters: how much autonomy should this thing actually have, and what happens when it’s wrong?
Autonomy is a spectrum, not a switch
It’s tempting to frame agentic features as a binary — either the AI does the task or it doesn’t. In practice, autonomy sits on a spectrum:
- Suggests — the agent proposes an action, a human executes it.
- Drafts — the agent performs the action but stages it for review before it takes effect.
- Acts with notification — the agent executes and tells you afterward.
- Acts silently — the agent executes with no human touchpoint at all.
Most products should launch at stage 1 or 2, even if the long-term vision is stage 4. Trust is earned by watching the agent be right repeatedly, not by promising it will be.
Reversibility determines the ceiling on autonomy
The single best predictor of how much autonomy is safe to grant is: how expensive is it to undo? An agent that drafts an email can operate at a higher autonomy stage than one that deletes production records or sends a wire transfer. Map every agent action to a reversibility score before deciding its default autonomy level.
Tool design shapes agent reliability more than model choice
A well-scoped tool with a narrow, validated interface prevents entire classes of agent errors. A tool that lets the agent do anything (“run_sql”) will eventually be used to do something you didn’t want. Constrain the action surface first; upgrade the model second.
Compare a dangerously broad tool definition to a properly scoped one:
# Too broad — the model can construct arbitrary SQL
def run_sql(query: str) -> list[dict]:
return db.execute(query).fetchall()
# Scoped — the model can only do what the product allows
def refund_order(order_id: str, reason: OrderRefundReason) -> RefundResult:
order = orders.get(order_id)
if not order or order.status != "delivered":
raise ToolError("Order not eligible for refund")
return payments.refund(order.payment_id, reason=reason)The second version can’t be misused into a destructive query, because the shape of the tool itself rules it out.
Failure needs to be visible, not just handled
An agent that silently retries, falls back, or gives up looks reliable in a demo and erodes trust in production because nobody can tell when it quietly failed. Build a visible audit trail of every agent action and its outcome — this is as important as the agent’s core capability.
Start with a narrow, high-frequency task
The agentic products that survive contact with real users are usually narrow: one task, done well, many times a day — not a general-purpose assistant that attempts everything. Resist the pressure to generalize before you’ve proven reliability on the narrow case.