THE CORE AGENT LOOP

EXAMPLES Example 1: A ReAct run, step by step. A user asks: "What is the weather in the city where the 2024 Summer Olympics were held?" The agent has two tools: a search tool and a weather tool. Loop one begins with a Thought. The agent writes: "I need to find which city hosted the 2024 Summer Olympics before I can check any weather." Then comes an Action. The agent asks the harness to call the search tool with the text "2024 Summer Olympics host city." The harness runs the search and returns an Observation: "Paris." Loop two begins with a new Thought. The agent writes: "The city is Paris. Now I need the current weather in Paris." The Action this time is a call to the weather tool with the input "Paris." The Observation that returns says, for instance, that it is 18 degrees Celsius and partly cloudy. Loop three has a Thought: "I have everything I need." Instead of another tool call, the agent writes the final answer: "The 2024 Summer Olympics were held in Paris, where it is currently about 18 degrees Celsius and partly cloudy." The harness sees a final answer rather than a tool request, and it ends the run. Notice that the think-act-observe cycle ran twice with tools, and the third pass produced the answer. Notice too that the second action depended on the first observation. The agent could not have known to ask about Paris until the search returned. That dependence is exactly why a reactive style fits this problem. Example 2: Plan-and-execute compared with reactive. Suppose the task is "Analyze last quarter's sales and give me a one-page summary." A plan-and-execute agent first writes a plan: "1. Find the sales data. 2. Clean the data. 3. Analyze it. 4. Make a chart. 5. Write the summary." A person can read those five lines in ten seconds and say "yes, that is what I want" or "skip the chart." Then the harness carries out step one, step two, and so on in order. A purely reactive agent given the same task would decide only the first move, perhaps "search for the sales file," see what turned up, and then decide the next move. It might end up in the same place, but there was no early moment where a person could check the whole approach. On the other hand, if step one reveals that the sales data is split across three confusing files, the fixed plan may no longer fit, and a good plan-and-execute harness lets the agent revise the plan. Example 3: A termination condition. A harness is told to stop whenever it sees the marker TASK_COMPLETE in the model's message. The agent finishes writing a report and ends its message with "TASK_COMPLETE." The harness spots the marker and breaks out of the loop. A cautious engineer adds a second rule: before accepting the marker, the harness checks that the report file really exists and is not empty. If the file is missing, the harness tells the model "You said you were complete, but the report file does not exist," and the loop continues. This is a small example of the principle that the harness verifies instead of simply trusting. Example 4: A step-limit safeguard. An agent is capped at 25 iterations. On iteration 25 it is still searching for a missing customer record and has not found it. The harness does not let a twenty-sixth iteration start. Instead it forces a stop and returns a message such as: "I reached my limit of 25 steps before finishing. I located 3 of the 4 documents you asked for. The remaining one is the customer record for account 8841, which I could not find. Here are my notes so far." The user gets useful partial progress, a clear reason, and a suggestion for next steps, instead of silence or an enormous bill.