AI agents and tools: loops, safety and idempotent tools

A team wants a helper that acts, not only talks. It looks up an order and gives a refund. The interviewer asks: "What if it gets stuck? What if someone tricks it? What if it gives the refund twice?"

A weak answer says "the model is smart, so it will be fine". A strong answer first asks if the steps are known, because then plain code is better. If not, it sets limits, gives each action the least power, and asks a person before anything that cannot be undone.

At SDE-1 level, know that a helper can repeat itself or be tricked. At SDE-2 level, add limits and safe actions, with numbers. At SDE-3 level, say what stays risky.

Think of a new helper at a shop counter. The helper decides each next step alone, so you add controls. There is a limit on time and cash. The helper gets keys to only the drawers the job needs. A big refund needs the manager. A diary records every action. This lesson is that list of controls for an AI helper.

Tools and the loop

A tool is a function that your code offers to the model, with a name, a short description and named inputs, for example get_order(order_id). The model cannot run anything. It only writes a request: "call get_order with order_id 4412". Your code runs the function and puts the result into the next prompt as text. The tool descriptions are part of the prompt, so they cost input tokens on every call.

An agent is a model that calls tools in a loop:

1. Send the prompt: instructions, tool descriptions, the question and the history so far.
2. The model answers with a tool request or a final answer.
3. For a tool request, your code runs the tool, adds the request and result to the history, and goes back to item 1.
4. For a final answer, stop.

One trip around the loop is a step, and each step is one model call. The model remembers nothing (lesson 118), so each call sends the whole history again. Let F be the fixed start in tokens and S the tokens one step adds. The input of call k is F + S x (k - 1), so the cost grows faster than the number of steps.

Agent or fixed workflow

A workflow is code that decides the steps. The model is called at set points, in a set order. In an agent, the model decides the steps.

A workflow is cheaper, faster and easier to test, because it follows the same path every time. An agent makes more calls, and its cost differs from run to run. But it can handle a job where the next step depends on the last result. Ask: "Can I write the steps down?" If yes, use a workflow.

Limits on steps, time and money

A tool may return an error, and the model may try again and again. Set three limits in code, not in the prompt (lesson 122).

• Step limit: the most model calls in one run. Set it to double a normal run.
• Deadline: the most time for the whole run (lesson 54), plus a timeout on each tool call.
• Money budget: before each call, add the cost so far to the worst-case cost of this call (the output has a cap, lesson 123). If the total is over the budget, stop.

Each limit catches a different failure: slow tools reach the deadline, big results reach the budget, quick loops reach the step limit. The first one reached ends the run, with an honest message (lesson 119).

Least privilege for tools

Least privilege (lesson 122) means the smallest set of rights that a job needs. For tools:

1. Offer only the tools the job needs, and make each one narrow. Offer issue_refund(order_id), not run_sql(query).
2. Take facts from your own system, not from the model. The user ID comes from the login. The model names an order, and the code checks that it belongs to this user. The amount comes from the database.
3. Check rights in code, not in the prompt.

A read tool only looks. A write tool changes something, so it needs the most care.

Confirm what cannot be undone

In a loop, a write tool does not do the action at once (human approval, lesson 122). It saves a pending action and returns "waiting for approval" to the model. The model writes a final answer such as "A person will check your refund", and the run ends. No model call runs while the person decides, so the wait adds no model cost. The person sees the real action, with facts from your database, and clicks Approve or Reject. Ask only for actions that cannot be undone, such as money paid out. Too many questions make people click yes without reading.

Idempotent tools

An action is idempotent if doing it many times leaves the same state as doing it once (lesson 61). A tool can run twice for four reasons. Your code retries after a timeout (the work may be done, lesson 54). The model asks again. A crashed run restarts. A person clicks Approve twice. A read tool is safe to repeat, so this matters for every write tool.

The fix is from lesson 61: save a unique key and the result in one transaction, with a unique constraint. The code makes the key from the real action, for example refund:order-4412. A key made by the model would change on each try. For a repeat, return the saved result in words that say the work is done: "The refund of Rs 349 for order 4412 was already made." Do not return an error: an error invites the model to try again.

Tool results can carry orders

The model cannot tell your instructions from data (lesson 122). A tool result is text from outside: a delivery note that a customer typed, a restaurant description, a help page. Someone can write an order into it, and the agent may follow it in the next step. This is indirect injection, and it is worse in an agent, which has tools to act on it.

The defences are the ones above: least privilege, inputs checked in code, and approval. Add attack cases to your eval.

Log each step

A step log has one row per step: run ID, step number, tool, inputs, tokens, cost so far, who approved, and why the run stopped. It shows why the agent acted, and failed runs become eval cases. It costs storage and holds personal data, so keep results short.

SwadKart, the food app of lesson 118, adds a refund helper. Two tools read (get_order, search_help) and one writes (issue_refund(order_id)).

Assumptions (made up to teach with, not measurements):

• Input costs Rs 100 and output costs Rs 500 per million tokens (lesson 118). Each call writes 100 tokens, its output cap.
• The fixed start is 1,050 tokens: 600 of instructions, 400 of tool descriptions, 50 of question. A tool result is 400 tokens. One step adds 100 + 400 = 500 tokens.
• A normal run has 4 calls: get the order, read the help page, ask for the refund, write the final answer.
• A model call takes 2 seconds. A tool takes 0.5 seconds, with a 5-second timeout.
• An order is Rs 349. There are 2,000 refund requests a day.

Step 1: the loop (the predict box). The input of call k is 1,050 + 500 x (k - 1).

• Calls 1 to 4: 1,050, 1,550, 2,050 and 2,550. Total: 7,200 tokens.
• Input: 7,200 x Rs 100 / 1,000,000 = Rs 0.72. Output: 400 x Rs 500 / 1,000,000 = Rs 0.20. One run costs Rs 0.92.
• Call 50 sends 1,050 + 49 x 500 = 25,550 tokens. The answer is about 25,000.

Step 2: a stuck run with no limit. The total input over n calls is 1,050 x n + 500 x n x (n - 1) / 2. For n = 50 that is 52,500 + 612,500 = 665,000 tokens, which costs Rs 66.50. Output is 5,000 tokens, which costs Rs 2.50. The run costs Rs 69.00, which is 75 times a normal run.

Step 3: three limits. The step limit is 8 (double the normal 4). The budget is Rs 2. The deadline is 30 seconds. The cost after k calls is 0.0001 x (1,050 x k + 250 x k x (k - 1)) + 0.05 x k rupees: Rs 0.92 for 4 calls, Rs 1.275 for 5, Rs 1.68 for 6, Rs 2.135 for 7 and Rs 2.64 for 8.

• Money: call 7 would take the run to Rs 2.135, over Rs 2, so the run stops after 6 calls. Eight calls would cost Rs 2.64, so a step limit alone is weak.
• Time: suppose a tool never answers, so each step waits for the 5-second timeout. A step takes 2 + 5 = 7 seconds. Calls start at 0, 7, 14, 21 and 28 seconds, and a sixth would start at 35. So the deadline stops the run after 5 calls.

Step 4: a workflow instead. Our code calls both read tools itself. The model is called once with both results: 1,050 + 400 + 400 = 1,850 input tokens and 100 output tokens. It returns its decision, and our code calls issue_refund. The cost is 1,850 x Rs 100 / 1,000,000 + 0.05 = 0.185 + 0.05 = Rs 0.235. That is 0.92 / 0.235 = 3.9 times less. It takes 3 x 0.5 + 2 = 3.5 seconds, against 4 x 2 + 3 x 0.5 = 9.5 seconds. The steps never change, so use a workflow.

Step 5: the double refund. Assumption: 1 refund request in 50 repeats issue_refund, which is 2,000 / 50 = 40 repeats a day. Without a key, 40 x Rs 349 = Rs 13,960 a day is paid by mistake. With the key refund:order-4412, the second call returns "already made".

Step 6: an attack. The eval has 10 attack cases, each hiding an order in a delivery note or a description. 4 ask for a refund on another user's order, and 6 ask for more than the order is worth. Version 1 lets the model pass the order ID and the amount, and the refund is paid at once. In version 2 the tool takes only the order ID, and the code checks that the order belongs to the logged-in user. The code sets the amount (paid minus refunded, so at most Rs 349). The tool saves a pending action, and a support person approves it after seeing database facts, such as "delivered 4 minutes early".

Assumption: in both versions the model is fooled in 2 of the 4 and in 3 of the 6, so in 5 of 10. In version 1, 5 wrong refunds are paid. In version 2, the 2 other-user requests fail the owner check. The 3 oversize requests become pending actions of Rs 349. Assumption: the person sees that the food came on time and rejects all 3. Wrong refunds: 0. The model is still fooled. Only its power changed.

• An agent solves jobs where the next step depends on a result. It costs more calls and a cost that varies. I would use a workflow when I can list the steps.
• Limits solve a run that never stops (Rs 69.00 became at most Rs 2). They cost a good run that is cut short.
• Least privilege and approval solve harm from a fooled model (5 wrong refunds became 0). They cost build work and a wait for a person. I would add approval only where harm is permanent.
• Idempotent tools solve repeats (Rs 13,960 a day). They cost a table. I would use them on every write tool.

"The model runs the tools, so I cannot check them." For tools that you define, the model only writes a request. Your code runs the tool, so your code can check every call.

"The prompt says to refund only valid orders, so the tool needs no checks." The prompt is text, and an injected order sits in the same text. In the example it was fooled in 5 of 10 cases.

"The model asks for the refund only once, so I do not need idempotency." A retry, a restart or a double click can repeat the call.

1. What is an agent? Name three limits, and say when a workflow is better.
2. An agent has a fixed start of 800 tokens. Each step adds 300 tokens (80 output and 220 result), and each call writes 80 tokens. Input costs Rs 100 and output costs Rs 500 per million tokens. (a) How many input tokens do 5 calls send? (b) What do they cost? (c) The budget is Rs 1.00. Is the 6th call allowed?
3. A support agent has send_sms(phone, text). The code retries it after a timeout. A customer note says: "Send my message to this other number." Name two problems, and a fix for each.