Answers are not loops.

Parse the rows that prove a workflow took a goal, planned, used a tool, observed a result, and iterated. Keep named support stages visible without pretending a CSV executed anything.

Declared trace evidence is not provider telemetry. This validator checks structure, not live model behavior.

Trace CSV

Use one row per observed step. The sample includes retrieval inside its tool action.

Waiting for the pinned parser.

Execution tape

No trace validated.

WAITING

Parsed rows0

Observed phases0

Parser errors0

Parse the CSV to turn declared rows into inspectable execution evidence.

A completed trace will explain whether the required goal-plan-tool-observe-loop stages are present and why that still does not prove live execution.

Agent Loop Trace Validation Architecture

How does this trace validator evaluate whether an agent workflow exhibits a closed loop?

This tool inspects user-provided CSV rows representing an agentic execution trace using Papa Parse. It checks whether the trace contains eight declared phase identifiers (goal, plan, tool, observation, memory, guardrail, loop, final), verifies that at least one observation phase precedes a loop phase in row sequence, and tests tool actions against regular expression keywords for retrieval evidence.

The validation is purely syntactic and checks only static declared text rows in client memory. It does not connect to live foundation models, vector stores, Model Context Protocol (MCP) servers, or runtime telemetry. It cannot prove that external tools actually executed, that API calls returned factual data, or that guardrail checks evaluated actual prompt outputs.

Try a worked example

With the default eight-step trace loaded in the editor, click 'Parse trace'. The status badge changes from 'WAITING' to 'CLOSED LOOP', 'Parsed rows' updates to '8 TRACE ROWS', and 'Observed phases' displays '8 PHASES OBSERVED'. If you delete row 7 ('loop') and click 'Parse trace', the badge changes to 'LOOP OPEN' and a missing execution warning highlights the missing loop phase.

Phase Requirements and Sequence Matching

The script defines a fixed array of eight required lifecycle phases: 'goal', 'plan', 'tool', 'observation', 'memory', 'guardrail', 'loop', and 'final'. Input phase names undergo normalization where strings like 'answer' or 'final_answer' map to 'final', 'observe' or 'result' map to 'observation', and 'safety' maps to 'guardrail'.

A trace is flagged as a 'CLOSED LOOP' only when every required phase is present in the CSV, an observation row exists at an index greater than or equal to zero, and a subsequent loop row appears after that observation row. In addition, the tool checks whether any tool row mentions retrieval-related keywords such as 'search', 'rag', 'retriev', 'vector', or 'embedding'.

Declared Traces vs. Verified Runtime Telemetry

In production autonomous agent architectures, verifying loop closure requires observing live operational telemetry, including network payloads, sandbox tool execution exit codes, and model token streams. In contrast, this browser-based validator operates solely on static user-typed CSV text.

Declared phases and the limits of closed-loop labels

Read the explanation

The validator parses CSV rows and normalizes phase labels. It requires goal, plan, tool, observation, memory, guardrail, loop and final. All eight names must occur for the first closed-loop condition. This counts distinct required names, not total rows, and repeats do not add coverage. Answer and final answer normalize to final; observe and result normalize to observation; safety normalizes to guardrail. Declared text does not prove that a provider executed any system. The ordering check finds the first observation and first loop rows. With observation at zero based index three and loop at six, loop comes later and passes that condition. If a loop row precedes the first observation, it fails even if a later loop follows. The source does not validate every transition, numerical step ordering or whether evidence statements are true. It checks names and this one ordering relationship. A tool row is marked as retrieval evidence if its action or evidence matches retrieval, search, RAG, vector or embedding. The source computes closed loop before adding a missing retrieval message to the gaps list. Therefore a trace can display closed loop while also showing a retrieval evidence gap. This is a lexical heuristic, not a verified retrieval call. Exports preserve declared rows, input CSV and limitations. No backend, model, vector database, memory store or guardrail service was contacted.