React Agent
By Ai Flowi · Published
A ReAct agent uses a pattern that combines reasoning about a task with actions and observations from tools. After an action returns a result, the agent can decide whether to answer, take another permitted action or stop. Here, “React Agent” refers to that AI pattern, commonly written ReAct, rather than a frontend user-interface component.
The useful evidence is the observable tool request and returned result. You do not need access to hidden chain-of-thought to evaluate whether the agent selected an appropriate tool, respected its boundary or supported its answer with the observation.
What the action-observation loop means
An ordinary fixed sequence determines its next step in advance. A ReAct-style design can choose the next allowed action in light of information returned by a tool. The task may finish after one useful observation, or stop because the available tools cannot resolve the question.
This flexibility introduces a control problem. Decide which tools are available, what evidence counts as sufficient and when another call becomes repetition. The loop is a task pattern, not permission to explore arbitrary services. It also does not prove the agent will recognise a bad observation.
Related: CrewAI integration for AI Flowi Workflow.
An observable read-only example
Imagine a question asking whether an approved document contains a cancellation condition. A read-only lookup tool can retrieve an authorised excerpt. The trace below describes possible events; it is illustrative and contains no recorded tool output.
| Event | Observable record | Acceptance check |
|---|---|---|
| Task received | A question and the approved source identifier. | The question is within the permitted read-only scope. |
| Tool requested | The lookup name and document identifier. | The operation and resource are authorised. |
| Observation returned | An excerpt, a not-found result or a technical failure. | The result is kept distinct from a model guess. |
| Next decision | Answer from evidence, request a permitted clarification or stop. | The agent does not claim evidence absent from the observation. |
If the excerpt answers the question, the final response should identify the supporting source. If it lacks the cancellation condition, the response should say that the supplied evidence is insufficient. An empty result does not establish that no condition exists anywhere else.
A failed request has a different meaning from an authorised search that found nothing. Keep both outcomes visible during review. Otherwise the final answer can quietly turn a service outage into a factual conclusion.
An observation that changes the next action
Extend the invented question with two approved sources: the main document and its cancellation appendix. The first lookup returns a passage saying that the condition is defined in the appendix, with no condition in the passage itself. The next permitted action is now to retrieve that appendix. Repeating the main-document lookup would add no relevant evidence. The appendix lookup is permitted only because its identifier was included in the initial approved set.
Contrast that with a first result stating that the requested passage is redacted. This observation provides neither the condition nor authority to obtain an unrestricted copy. The next decision should be to stop and report that the accessible source cannot answer the question. A generic “keep searching” instruction would be unsuitable for this branch.
Test the two branches with the same starting question and available tools. Save the initial request, first observation and next requested operation. If both branches produce the same second lookup regardless of the evidence, the trace demonstrates a fixed continuation, not observation-led selection. If the appendix returns the relevant passage, completion depends on that passage; the first document’s pointer alone was insufficient. These are evaluation cases, not observed model results.
Continue, stop or ask a person
| Observation | Next decision | Reason |
|---|---|---|
| Relevant supporting excerpt | Answer and identify the source. | The task’s evidence condition is satisfied. |
| Ambiguous source identifier | Ask for clarification. | Guessing can access the wrong source. |
| Repeated unhelpful lookup | Stop with unresolved evidence. | The same observation adds no new support. |
| Permission denied | Stop the attempted access. | A different prompt cannot grant permission. |
| Technical failure | Report failure under the defined retry policy. | The task has no usable observation yet. |
Set a work budget before running the loop. A cap can bound attempts but cannot guarantee a useful answer. For external writes, an uncertain result needs destination inspection before retrying; the read-only example avoids that action class entirely.
How the pattern relates to AI Flowi Workflow
The Agent component reference owns the task, model and tool interface for the configuration sketch.
The catalogue does not identify Agent as a native ReAct executor; evaluating this pattern requires observing whether returned evidence changes its next permitted action.
Use the function-calling contract for Flow as Tool and inspect the chosen lookup before assessing the loop.
A bounded configuration sketch
example configuration, not a recorded test
Agent
tools: connect the Tool output
system_prompt: Answer only from returned excerpts.
Stop on denied access or insufficient evidence.
max_iterations: 3
input_value: the synthetic question and approved source reference
This sketches intended action and stopping rules; it is not a verified loop implementation. The illustrative iteration value has no measured reliability meaning. Configure your own provider account and API key for the model and pay the provider separately. The described components are documented in the catalogue; not production-tested by Ai Flowi.
The export does not specify the exact behaviour of handle_parsing_errors, what verbose reveals or the termination response when the iteration limit is reached. Those gaps should become checks during a real trial. They cannot be filled by treating a field name as execution evidence.
What is the difference between ReAct, function calling and orchestration?
Function calling describes a structured request for an operation and the application’s execution response. ReAct describes a broader action-observation pattern in which results influence the next decision. A tool interface alone does not establish that a particular agent implements that pattern.
Multi-agent orchestration coordinates distinct task owners and their handoffs. One agent using several tools is not automatically a multi-agent system. AI agent state records what has been observed, what remains unresolved and whether completion is allowed.
Common mistakes when reviewing a loop
Do not ask for hidden reasoning as a substitute for an execution record. Review the operation name, arguments, outcome and supporting source. A persuasive explanation can coexist with an unsuitable tool call.
Do not treat retrieved instructions as higher authority than the task’s access boundary. Do not let repeated calls manufacture certainty from the same missing evidence. If the task is a fixed transformation with no decision-dependent retrieval, use a simpler path. Existing documented workflows can help identify that starting point.
Workflow usage
Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.