What Actually Happens Between an AI Agent’s First Thought and Its Final Answer?
Making sense of harnesses, memory, agent loops, tracing, and evaluations through one everyday request.
When someone says an AI agent can “handle a task,” I find it useful to ask what handling actually involves.
Imagine telling an assistant: “Find thirty minutes for me and Priya next week. Avoid mornings, and show me the options before sending anything.”
A language model can understand that request. But understanding it does not reveal your calendar, identify the right Priya, or establish permission to send an invitation. Those details belong to the application around the model.
That is the perspective I want to use here. We can understand the terminology by following this request from the first message to a result we can verify.
The request needs more than a good answer
Before choosing an action, the assistant needs context. Which calendar should it inspect? Does “mornings” refer to your timezone? Are there several contacts named Priya?
I think of the harness as the surrounding software that makes this work possible: assembling context, exposing tools, enforcing application rules, executing allowed actions, and carrying information between steps. Implementations differ. A harness is a system responsibility, rather than a universally fixed product architecture.
The model might request a calendar lookup. The application checks that request and runs the tool. Its result then becomes input to another model call. The model is choosing an action within an environment the application provides.
That boundary matters. A model proposing an invitation does not establish that the user approved it. Our application must preserve the instruction to show options first.
Remembering a preference is different from knowing what happened
Now imagine this is not the first conversation. The assistant already knows your timezone and usual working hours. It should not need to ask every time.
One useful memory vocabulary separates facts, experiences, and instructions. Semantic memory holds facts or preferences. Episodic memory preserves past events or examples. Procedural memory captures instructions about how to act. [LangChain’s memory guide] describes these categories alongside short-term and long-term memory.
For this example, your timezone is a fact. A record of a previous scheduling attempt is an episode. A rule requiring confirmation before invitations is procedural guidance.
These categories describe purposes, not a requirement for three databases.
There is also a distinction I would keep explicit: conversation memory and authoritative application state. A summary saying “we discussed Tuesday” does not prove a meeting exists. The calendar system must answer that question.
Otherwise, the assistant could turn a suggestion into a supposed fact simply by remembering its own earlier response.
Retrieval should answer the question the next step needs
Having stored information does not mean sending all of it to the model is useful.
For “Who is Priya?”, an exact contact identifier or a filtered lookup may be appropriate. For “What did we decide about these planning meetings?”, searching relevant notes may help. The retrieval method should follow the information need.
This is where retrieval-augmented generation, or RAG, fits: retrieve useful external information and include it in the model’s context. Semantic search can be one retrieval technique; it is not a substitute for every database query.
Get Kalgi Shah’s stories in your inbox
Join Medium for free to get updates from this writer.
In our proposed design, structured calendar facts come from calendar tools. Meeting preferences come from a scoped user record. Relevant past discussion can come from notes. Keeping those sources distinct makes disagreements easier to investigate.
If the assistant proposes a morning slot, we can ask whether the preference was missing, outdated, retrieved incorrectly, or present but ignored. Those possibilities call for different fixes.
The loop needs a definition of enough
Once the assistant can retrieve information and call tools, a single request may require several model calls.
It identifies the participant, checks availability, receives results, and decides whether anything is missing. That repeated action-and-observation cycle is the agent loop.
Loop engineering concerns how that cycle progresses and ends. I would define success for this request as presenting suitable options. Sending an invitation would exceed the requested task.
For longer tasks, progress must also survive interruptions. Anthropic’s harness research discusses structured progress artifacts and verification across sessions. A conversation summary alone does not establish that the underlying work is finished.
A trace explains the path; an evaluation checks the outcome
Suppose the assistant offers Tuesday at 9 a.m. despite the request to avoid mornings.
The final answer shows the mistake, but it does not explain its origin. A trace can reveal the supplied context, tool calls, returned data, model responses, and timing. Langfuse’s observability documentation describes this structured view of a request.
Perhaps the preference never reached the model. Perhaps a timezone conversion changed what the slot meant. Perhaps the right information was present and the assistant chose incorrectly.
An evaluation asks a separate question: did the system satisfy the task?
For our scheduling case, we could check whether proposed slots respect the requested duration and timezone, whether the assistant handled an ambiguous contact, and whether any invitation was sent without approval.
Some checks can be deterministic. Others, such as whether a clarification was understandable, may benefit from human review or an LLM judge with a clear rubric. A judge is another measurement mechanism with limitations. Anthropic’s evaluation guide discusses combining grading approaches and inspecting agent behavior.
Improving the system means testing the explanation for the failure
This is where I connect the pieces to LLM operations: observing runs, evaluating behavior, diagnosing failures, and deciding whether a change is ready to release.
If retrieval dropped the preference, I would investigate retrieval before rewriting every prompt. If a tool returned ambiguous timestamps, I would improve that contract. If the assistant ignored an approval boundary, I would examine the application’s enforcement.
Then I would rerun the failing case alongside existing tests. Fixing the morning-slot example should not make the assistant mishandle participant names or send invitations prematurely.
That gives the release decision something concrete to depend on. It also prevents “self-improvement” from becoming an unchecked cycle of changing behavior and assuming each change helped.
The same reasoning applies to a coding assistant investigating an issue or a support agent checking an order. The domain changes, but the questions remain recognizable: what information reached the model, which actions were allowed, what actually happened, and what evidence establishes completion?
Once those questions have clear answers, the terminology becomes easier to use. We can see where each component belongs and, when the system fails, where to start looking.
