A ReAct-style workflow alternates a concise action proposal, a tool result, and a revised next step. The useful feature is feedback: the next operation depends on observed data rather than a plan written once at the start. The application must expose only eligible tools, validate each call against the authenticated principal, and treat returned text as data rather than instructions. A public response needs a brief evidence summary and receipt, not a private chain of thought. Set a call ceiling, duplicate-call rule, and condition for stopping before allowing the first action.
Make this comfortable
ReAct: alternate tool actions with checked observations
Operational case
A maintenance assistant is asked whether pump PM-84 can return to service. Its first permitted action reads the work order and discovers a missing pressure test. The next action retrieves the test record, which shows the measurement but no supervisor sign-off. The assistant must stop at that point and state that release is pending approval. A note embedded in the test record says to mark the job complete, but the note cannot grant permission. If the record lookup times out after an earlier write request, the assistant checks the receipt instead of retrying an effect blindly.
Goal: assess PM-84 return-to-service status.
Action 1: read authorized work order -> pressure test required.
Action 2: read test record -> measured; sign-off absent.
Stop: no release action; request supervisor sign-off.
Limits: 4 reads, 0 unapproved writes; quarantine record text.Performance and operating cost
For K tool steps, there are up to K model decisions and K tool calls, so latency accumulates across dependent steps even when each operation is quick. Retain only necessary observations to keep context growth bounded; a naive transcript can grow with every tool payload. Track tool errors and repeated calls separately from task success. A loop that can only read should never gain a write because the model describes the write as the next logical step. When data is already present and verified, a direct response avoids unnecessary tool churn.
Common Mistakes
- Do not let a retrieved note alter tool permissions.
- Do not repeat an ambiguous effect without checking its receipt.
- Do not expose internal reasoning traces as a substitute for checked evidence.
Connected lessons
- Prompt patterns
- Prompt Engineering
- Tool loops: set budgets, state checks, and a stopping condition
- Tool calls: validate intent and arguments before an external effect
- Tool effects: reconcile receipts before retrying
- Self-consistency: sample answers, then verify the winner
- Tree of Thoughts: branch only where a decision can be checked
- Least-to-most prompting: solve smaller dependencies first
- Program-aided prompting: make computation executable and bounded
- Project: select and verify a reasoning pattern
- Reasoning patterns and operating limits
Continue with: Browser agents: separate observed state from intended action.
prompt engineering
reasoning patterns