A prompt is not a transaction boundary: designing reliable AI agent actions

Nikita Podelenko — Sat, 01 Aug 2026 23:30:47 +0000

Prompts are good at expressing intent. They are not good transaction boundaries.

That distinction matters when an AI agent can create appointments, transfer calls, send messages, or update a CRM. A model can decide that an action should happen, but the surrounding system still has to prove whether it happened once, failed safely, or needs human review.

Keep the model's job narrow

For a voice agent, a useful model output is a structured decision such as:

{
  "intent": "schedule_callback",
  "contact": { "name": "Sam", "phone": "+1..." },
  "preferred_window": "tomorrow afternoon"
}

The application can validate those fields, ask for missing data, and call the real scheduling service. This is safer than asking the model to narrate a successful booking before the provider has confirmed it.

The same separation helps prompt quality. The prompt describes what information matters and when to request an action. Deterministic code owns permissions, validation, retries, idempotency, and persistence.

Never let language become evidence

A sentence such as “Your appointment is confirmed” is not proof. Evidence is a successful provider response plus a durable identifier stored against the call. Likewise, “I am transferring you now” should not be the final state. The system needs attempting, connected, and failed transfer states.

This rule prevents a subtle class of errors: the conversation sounds complete even though the workflow failed. Those failures are easy to miss in transcript reviews because the language is fluent and reassuring.

Give tools typed outcomes

Agent tools should return small, explicit result objects rather than prose. For example:

{
  "ok": false,
  "code": "TIME_SLOT_UNAVAILABLE",
  "retryable": false,
  "next_options": ["2:30 PM", "4:00 PM"]
}

The model can then explain the outcome and ask the caller to choose an alternative. Operators can aggregate the result code, and tests can assert behavior without interpreting natural-language logs.

A good tool contract also distinguishes an uncertain timeout from a definitive rejection. A timeout may require an idempotent status check before retrying; blindly calling the provider again can create duplicates.

Design the recovery prompt too

Teams often spend most of their time on the happy-path system prompt. Production quality depends just as much on the recovery instructions:

What should the agent say when a tool times out?
Which actions may be retried automatically?
When should it stop and capture a message?
What must never be promised without confirmation?
Which failure details are safe and useful to tell the caller?

These rules should match real tool result codes. Generic instructions such as “handle errors gracefully” are too vague to produce consistent behavior.

Evaluate workflow truth

Prompt evaluation should include more than transcript style. For each test call, compare what the agent said with what the system persisted and what the provider confirmed.

Useful checks include:

Did the agent collect every required field?
Did each external action execute at most once?
Did spoken confirmation match the recorded result?
Was an unresolved outcome assigned to a human or exception queue?
Could an operator reconstruct the final state from durable events?

We use this separation while developing SkipCalls, an AI receptionist and phone-workflow product. The practical lesson is broader than voice: prompts decide and communicate, while transactional code proves and records.