Academy

Agents that act — safely

When an agent moves from retrieving information to executing actions, its utility increases. So does the blast radius of a mistake.

The Felesh team 3 min

Once an agent answers a query correctly, the natural next step is execution. If a user asks about availability and the system confirms it, the user should not have to context-switch to book it. A human operator should not have to manually log the interaction. Answering is a feature; acting is an operation.

Answering versus actingA customer writes a new address, Elm 12, for order #7715 and the assistant replies that it has it. From the reply the path forks. Answering stops there. Acting goes on to call set_address for order #7715, and the order record changes from Oak St 4 to Elm St 12.customerassistantNew address: Elm 12Got it, Elm 12answering endsacting goes onset_address(#7715)order #7715ship toOak St 4Elm St 12
Answering ends at the reply; acting carries on and changes the order record.

Agents that mutate state — booking slots, updating records, triggering workflows — create tangible leverage. But the moment an agent touches a production system, the stakes shift. A hallucinated answer is a bad user experience. A hallucinated action is a data integrity issue.

Wrong answer versus wrong actionTwo columns, both starting from order #7715, whose address is Oak St 4 On the left, a wrong answer says order #7715 ships Friday; the customer checks tracking, asks again and gets the right answer, so the next reply fixes it. On the right, a wrong action calls set_address with Elm St 12 that nobody asked for; the record Oak St 4 is overwritten by Elm St 12, marked in rust, and the parcel goes to the wrong door.wrong answerwrong action“#7715 ships Friday”customer checks trackingasks again, gets it rightset_address(#7715, Elm 12)order #7715ship to Oak St 4ship to Elm St 12fixed by the next replyparcel goes to the wrong door
A wrong answer is fixed by the next reply; a wrong action overwrites the address and breaks the record.

Where an agent can mutate state, the boundary we start from is suggest-mode. A human operator reviews the proposed action before the agent executes it. This is not friction, nor is it a workaround for unreliability. Autonomy is earned. Trust is built by letting humans inspect the receipts before a state change becomes irreversible.

Suggest-modeThe agent writes a proposed action as a receipt: action set_address, order #7715, to Elm St 12, why: customer asked in chat, status pending. The operator reads the order, the new address and the reason in turn, then approves. Only then does the status become executed and the order record change from Oak St 4 to Elm St 12.proposed actionactionset_addressorder#7715toElm St 12whycustomer asked in chatstatuspendingexecutedoperatorreads each fieldapproveorder #7715ship toOak St 4Elm St 12the state changes only after approve
In suggest-mode the operator reads the receipt field by field, and the order record changes only after approval.

Maximum autonomy is not the default objective. Setting the autonomy dial for any given workflow requires weighing two variables: our confidence in the execution path and the operational cost of an error.

The autonomy dial, by exampleExample settings for four workflows on the autonomy dial, from confidence in the path and cost of an error. Tag a conversation: high confidence, easy to undo, acts alone. Update a note: high confidence, old text is kept, acts, reports after. Change an address: medium confidence, wrong door risk, suggests, you approve. Delete a record: low confidence, cannot be undone, suggests, you approve.exampleconfidenceerror costdialautonomytag a chateasy to undoacts aloneupdate a noteold text keptacts, reports afterchange addresswrong door risksuggests, you approvedelete a recordcannot be undonesuggests, you approvehigh confidence and cheap errors earn more autonomy
In this example, confidence in the path and the cost of an error set where each workflow sits on the autonomy dial.

The following articles detail how safe execution works in production, and why human oversight is a core primitive: