Academy

Agents that act, not just answer — safely

The real leap is when a system doesn't just answer but gets something done in a real system. And acting makes mistakes costly — so 'safely' has to be structural.

The Felesh team 4 min

From answering to acting

An assistant that only answers leaves the burden of deciding and doing on you. The shift occurs when a system not only advises but takes action in a real setting: it creates and routes a ticket, finalises an order, or moves a transaction forward. Unlike simple answering, executing actions carries a far higher cost of error — and that is exactly where acting safely becomes a structural necessity.

Answering versus acting on one damaged parcelA customer reports that the parcel for order #5218 arrived cracked. An answering assistant replies with advice to file a claim on the Orders page, and the customer must then fill in the form, attach a photo and send it. An acting system opens ticket T-2041, routes it to Shipping, and a replacement is queued without further work from anyone.customerorder #5218:parcel camecrackedanswersreply: file a claimon the Orders pageactsopens ticket T-2041routes to Shippingyou fillthe form,photo, sendswap queuedno re-typingthe answer ends with you; the action ends with the job done
An answer hands the work back to you; an action opens the ticket, routes it and leaves the job done.

Clear boundaries

The first precondition for safe action is a clear boundary. Each agent has a defined scope of responsibility and acts only within it. A strict separation of duties prevents agents from intervening directly in one another’s work; all communication is routed through a message queue so that no message is lost. An agent whose access is limited strictly to what the task requires cannot easily overstep its bounds.

Scoped agents talking only through a queueThree agents, each with one scope: the tickets agent may open and route tickets, the orders agent may finalise orders, the payments agent may move money. They have no direct line to each other. The tickets agent puts the message T-2041, replace order #5218, into the message queue; the queue holds it, and the orders agent picks it up, so no message is lost.tickets agentmay: open, routescope: ticketsorders agentmay: finalisescope: orderspicked up T-2041payments agentmay: move moneyscope: paymentsmessage queueT-2041: order #5218T-2041: order #5218no direct line between agents: every message is queued
Each agent holds one narrow scope, and a message between agents waits in the queue until the right agent picks it up.

A safety net

Acting without a mechanism to detect failure is dangerous. An independent layer is designed to do just one thing: judge whether a process is genuinely complete. This completion monitor identifies delays and unexpected states, guaranteeing that a failure in one agent will not bring down the entire system — the user always receives a sensible response. Verifying that a task is finished is a structural step in the design, not an after-the-fact reaction to errors.

A completion monitor catches a step that never finishesTicket T-2041 runs three steps: opened, routed to Shipping, confirmation sent. The first two finish with a tick. The third, send confirmation, never finishes, so the failure shows as a rust mark. The completion monitor, a separate layer, watches the clock bar fill, flags the process as overdue and not complete, and the customer receives a sensible reply: claim filed, Shipping is checking, we will update you today.1 · ticket T-2041 opened2 · routed to Shipping3 · send confirmationcompletion monitoris the process complete?step 3 has gone quietoverdue, opento the customerClaim filed. Shipping checks; we update you today.
An independent monitor asks one question, is it complete, and when a step goes quiet the customer still gets a sensible reply.

A human in the loop, and a trail that remains

Acting safely never means removing the human operator. In processes that require judgement, the human remains in the decision loop and the system defers the work to them. Because every action passes through a defined path, you can always retrace which agent acted, at which step, and with exactly what input. That clear trail is precisely what makes an acting system trustworthy and auditable.

The trail of one ticket, with a person in the loopFive rows of the trail for ticket T-2041. 14:03, tickets agent, opened T-2041, input: cracked parcel photo. 14:03, tickets agent, routed to Shipping, input: category damage. 14:04, shipping agent, handed to a person, input: a refund ask. 09:26, the shipping lead, a person, approved the credit, input: the lead’s call. 09:26, shipping agent, ships the swap, input: the lead’s ok. The two rows where the person took over are highlighted as the human in the loop.timewhostepinput14:03tickets agentopened T-2041parcel photo14:03tickets agentrouted: Shippingdamage14:04shipping agentto a personrefund ask09:26lead (person)approved creditlead’s call09:26shipping agentships swaplead’s okjudgement goes to a person; every step stays retraceable
Every row of the trail names who acted, when, at which step and on what input, including the moment a person took over.