{"slug": "loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex", "title": "Loop Engineering Visualized: A World Cup Fan Journey with SerpApi and Codex", "summary": "A new demo called World Cup Fan Journey, built with OpenAI's Codex and SerpApi, visualizes Loop Engineering by having an AI agent follow a football fan's exploration from one match through related players, highlights, and debates, producing a trace of the agent's decisions. The demo's source code is available on GitHub, and it illustrates how agents observe results, update state, and choose next actions in a human-in-the-loop loop rather than a fixed pipeline.", "body_md": "Prompt Engineering focuses on shaping a model call, while Loop Engineering focuses on what happens after that call: how an agent observes the result, updates its state, chooses the next action, and decides whether to continue.\n\nThe difference sounds simple. But it is hard to feel until you build something where the model has to keep going:\n\n**The easiest way to understand a loop is to watch one unfold.**\n\nSo I built a small World Cup fan demo with Codex and SerpApi to make Loop Engineering visible.\n\nThe product idea is intentionally simple: a fan starts with one match, and the agent follows the journey from there. It identifies an interesting player, discovers related matches, searches for highlights, reads fan debates, and keeps deciding what to explore next.\n\nEventually, it produces a trace showing how the entire journey unfolded. But under the surface, this is not just a football app. **The fan journey is the agent loop.**\n\nEvery discovery becomes a new context. Every action changes the state. And every result influences what the agent does next.\n\n## The Demo\n\nThe demo is called **World Cup Fan Journey**, and the full source code is available in the [Github repository](https://github.com/serpapi/world-cup-loop-engineering).\n\nThe journey starts with a simple natural-language request:\n\nShow me France vs Morocco\n\nor in Chinese:\n\n我想看挪威对法国的比赛\n\nThe app interprets the request, identifies the football matchup, and initializes the first journey state. From there, the agent starts building a fan pack around the match:\n\n- Live match context and upcoming games\n- Highlights and social content\n- Fan debates and trending stories\n- Related players and AI-generated match analysis\n\nThe important interaction is what happens after the user clicks a player.\n\nFor example, if the user follows Kylian Mbappé, the goal changes. The app no longer needs to explain only France vs Morocco. It now needs to explore Mbappé’s football trail: recent matches, videos, debates, memes, and related players.\n\nThe player clicks to update the goal. From there, the agent enters another loop: it searches, observes the results, updates the journey state, and decides what to retrieve next.\n\nThe user chooses the direction. The loop handles the exploration.\n\nFinally, when the user clicks **Generate my football graph**, the demo stops exploring and turns the accumulated journey into a **Loop Engineering trace**.\n\nThat final output is not meant to be a normal social graph. It is meant to answer:\n\nWhat did the agent know, what did it observe, what did it do next, and why?\n\n## Pipeline vs Loop\n\nA normal pipeline follows a predefined path:\n\nFetch the match → fetch videos → fetch players → render the page.\n\nThe next step is already known. However, this demo works differently.\n\nThe agent starts with a goal and builds a journey state around it. Search results introduce new matches, debates, and related players. These observations expand the state and create new directions the journey can take.\n\nIf the user follows Mbappé, the goal changes. The agent plans which of Mbappé's matches to explore, retrieves related football content, and adds new players and observations to the journey. The user can then follow another player, changing the goal again.\n\nThe loop continues:\n\nGoal → Plan → Search → Observe → Update State → Choose Next Direction → Goal Changes → Plan Again\n\nThis is a human-in-the-loop agent loop. The agent handles planning and exploration, while the user decides which direction is worth following.\n\nA pipeline says:\n\nDo A, then B, then C.\n\nThis loop asks:\n\nGiven the current goal and journey state, what should we explore next?\n\n## Mapping the Demo to the Loop\n\nThe easiest way to map the demo to the loop is to follow it iteration by iteration.\n\nEach iteration starts with a trigger and a goal. The agent plans what to explore, calls tools, observes the results, and updates the journey state.\n\nIn this demo, the next iteration begins when the user chooses a new direction.\n\nTrigger → Goal → Plan → Tools → Observe → Update State → Next Trigger\n\n### Iteration 1: Start with a Match\n\nThe first trigger is the user's search:\n\nShow me France vs Morocco.\n\nThe goal is:\n\nBuild a fan pack for France vs Morocco.\n\nThe app parses the request and uses sports, YouTube, news, trends, and player data to assemble the first fan journey.\n\nThe resulting observations include the match status, score, available videos, discussions, and related players. Those results become the current journey state.\n\n**At the end of the first iteration, the system has not just rendered a page. It has created possible directions for the next iteration.**\n\n### Iteration 2: Following Mbappé Changes the Goal\n\nThe user clicks **Follow Kylian Mbappé**. That click becomes the next trigger. In the code, this action starts a new planning step:\n\nThe LLM decides which three recent or trending matches are worth exploring:\n\nThe plan is then grounded with external search data by SerpApi. It retrieves the surrounding sports results, videos, news, and trends.\n\nThe agent observes three new match trails and discovers more related players. The state expands. Now the user has another set of possible directions.\n\nThe user chooses the direction. The agent explores it.\n\n### Iteration 3: The Loop Continues\n\nSuppose the user follows Erling Haaland.\n\nThe same loop structure runs again, but with a different goal and a different state.\n\nThe agent plans Haaland's match trail, retrieves new context, observes the results, and adds new match and player nodes to the journey.\n\nThis is why the demo is not a fixed pipeline. The structure repeats, but **the content of each iteration depends on the current goal and accumulated state.**\n\n### Iteration 4: Another Direction, Same Loop\n\nThe user follows Martin Odegaard.\n\nAgain:\n\nNew trigger → new goal → new plan → new observations → expanded state\n\nThe loop structure stays stable. The journey does not.\n\nBy this point, the system has accumulated multiple player trails, discovered matches, and possible next actions.\n\n### Final Iteration: Stop and Generate the Trace\n\nThe user clicks:\n\nGenerate my football graph.\n\nThis becomes the stop condition.\n\nThe agent stops exploring and turns the accumulated journey into a Loop Engineering trace.\n\nThe final output shows how each iteration changed:\n\n- the goal\n- the current state\n- the tools used\n- the observations\n- the memory carried forward\n\nThe graph is therefore not just a record of which players the user followed.\n\nIt is a visualization of how the loop changed from one iteration to the next.\n\n## Why SerpApi is Useful\n\nFor this demo, SerpApi acts as the observation layer. The LLM can plan what to explore, but the football world keeps changing: match status and scores change, new videos appear, and news and fan discussions evolve.\n\nThe loop needs a way to observe that external world.\n\nSerpApi provides that context through several search APIs:\n\n**Google Sports API****:** match scores, status, stage, venue, and time**YouTube Search API****:** highlights and shorts**Google News API****and**: debates, narratives, and rising topics** Google Trends API****Instagram Profile API****:** player profile context**Google Images API****:** player photos and visual fallbacks\n\nThe LLM decides what to explore. SerpApi gives the loop fresh context from the outside world.\n\n## Building It with Codex\n\nI built this demo with Codex, but the hardest part was not writing the code.\n\n**At the beginning, even the product goal was vague.**\n\nI knew I wanted to build a World Cup demo that made Loop Engineering visible. I did not yet know what that experience should look like.\n\nThe first version reflected that uncertainty.\n\nIt exposed almost every engineering concept directly: loop state, observations, memory, constraints, tool calls, validators, and a replay timeline.\n\n**Technically, the ideas were there. But as a product, it was painful to use.**\n\nA user had to understand Loop Engineering before they could understand the demo. The interface was explaining the architecture instead of letting the user experience it.\n\nSo the development process became iterative.\n\nI would inspect the UI, explain what felt confusing, and ask Codex to change the product around that observation. Codex would read the existing codebase, make a targeted change, run the build, and give me another version to react to.\n\nBuild → Observe → Rethink the goal → Patch → Verify → Repeat\n\nAfter several iterations, the product idea became much clearer.\n\nInstead of showing the loop as an engineering dashboard, the demo would hide most of the machinery behind a simple fan journey:\n\nStart with a match. Follow a player. Discover another match. Follow another player.\n\nThe user experiences the loop first.\n\nOnly at the end does the app reveal the Loop Engineering trace and show how each action changed the goal, state, observations, and next iteration.\n\nThat shift changed the entire interface.\n\nThe interesting part is that Codex was not simply implementing a finished specification. The specification itself became clearer through the implementation loop.\n\nEvery version gave me a new observation. Those observations changed what I asked Codex to build next.\n\nThe workflow itself became loop-shaped.\n\n## Two Failures That Made the Loop Clearer\n\nThe most useful lessons came from the parts that did not work. Some were ordinary UI bugs. Others exposed weaknesses in how I was thinking about the loop itself.\n\n### 1. The First Graph Showed Relationships, Not Iterations\n\nMy first version ended with a graph of players and matches. It showed that Mbappé, Haaland, and Ødegaard were connected to different matches, but it did not explain why the journey moved from one player to the next.\n\nIt showed relationships, but not:\n\n- What triggered each iteration\n- How the goal changed\n- What the agent observed\n- What state was carried forward\n\nIt was a relationship graph, not a loop trace.\n\nSo I redesigned the final output around iterations. The new trace shows the goal, current state, tools, observations, and memory for each step.\n\nA visualization should explain the concept, not just decorate the data.\n\nThis change also clarified the product itself. The fan journey was only the surface. The real output was the sequence of state transitions underneath it.\n\n### 2. Search Relevance Is Not Factual Correctness\n\nAt one point, a video title implied that Mbappé had scored in a match where he had not.\n\nThe player-trail search included his name:\n\n```\nfindYoutubeVideo(\n  `${planned.title} ${player.name} shorts memes`,\n  \"short\"\n);\n```\n\nThat made sense for retrieval. The goal was to find content related to Mbappé. But a relevant title could still imply incorrect facts, such as the wrong score or a goal he never scored.\n\nThe bug was simple:\n\nThe application treated search-derived copy as verified sports data.\n\nI added a deterministic fact guard before displaying those titles. Sports data verifies the score and match events; search and the LLM only shape how the content is presented.\n\nSports data owns the facts. Search and the LLM shape the narrative.\n\nThe broader Loop Engineering lesson is:\n\nA relevant observation is not always trustworthy enough to update factual state.\n\n## What I Would Improve Next\n\nThe demo makes the loop visible, but it is still a prototype. If I wanted to harden it, I would focus on three things.\n\n### 1. Unify the Loop State Model\n\nThe demo currently has two state models because the product evolved in stages.\n\nThe earlier replay-mode prototype derives a display snapshot from `SessionState`\n\nand `PersistentMemory`\n\n:\n\n``` js\nconst snapshot = buildLoopStateSnapshot(session, memory);\n```\n\nThe final fan journey uses `RabbitHoleState`\n\nas its main application state:\n\n```\nconst [state, setState] =\n  useState<RabbitHoleState | null>(null);\n```\n\nThis split reflects the development history: the replay dashboard came first, and the fan journey came later.\n\nIf I hardened the project, I would unify both flows around one sequence of loop-state transitions. The fan UI, execution logic, and final trace should all read from the same underlying history instead of adapting between separate representations.\n\nThe trace should come from the loop that actually ran, not from a parallel model built to explain it.\n\nThat would make each iteration easier to inspect, persist, and replay.\n\n### 2. Add Production Guardrails\n\nThe demo mostly relies on the user to decide when to stop.\n\nA production loop should also enforce operational limits, including maximum iterations, API timeouts, retry budgets, and graceful fallback behavior when a tool fails.\n\nInstead of retrying forever, the loop should be able to stop and return the best partial result available.\n\nA stop condition is also a reliability boundary.\n\n### 3. Persist the Journey Across Sessions\n\nRight now, the fan journey is mainly session-based.\n\nI would persist followed players, expanded trails, accepted content, and other useful memory so that a new session does not start from zero. That would let the loop carry context across a longer fan journey, rather than only across interactions on one page.\n\n## The Main Takeaway\n\nEveryone is talking about Loop Engineering right now, but people do not always mean exactly the same thing. Some use the term to describe the iteration inside a single AI agent: observe, update state, choose the next action, and repeat. Others use it at a higher level to describe systems that coordinate multiple agent runs over time.\n\nNeither view is necessarily wrong. They are looking at the same idea from different levels of abstraction.\n\nIn this demo, I focused on the **micro view**. The loop is human-in-the-loop: the user chooses a direction, the agent explores it, new observations expand the state, and the next user action starts another iteration.\n\nThe hard part is not making the model act once. It is designing how goals, observations, state, and decisions evolve from one iteration to the next.\n\nThat was also why football turned out to be such a useful example. The outside world keeps changing. A match moves from upcoming to live to full-time. Scores change. New videos appear. News and fan discussions evolve. The model cannot simply remember that world correctly. The loop has to be observed again.\n\nFor this demo, SerpApi's [ Google Sports API ](https://serpapi.com/google-sports-api)became the main source of match state: scores, match status, teams, schedules, and other sports context. That fresh data could then be written back into the loop state before the next iteration continued.\n\nCalling a tool is not enough. The result has to become a new observation, and that observation has to update the state the next iteration will use.\n\nIf you are building an AI agent or workflow around live sports data, try the SerpApi Google Sports API and see what kind of loop you can build around changing match state.", "url": "https://wpnews.pro/news/loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex", "canonical_source": "https://serpapi.com/blog/loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex/", "published_at": "2026-07-21 20:18:54+00:00", "updated_at": "2026-07-21 20:19:58.022108+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["SerpApi", "Codex", "OpenAI", "World Cup Fan Journey", "GitHub", "Kylian Mbappé"], "alternates": {"html": "https://wpnews.pro/news/loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex", "markdown": "https://wpnews.pro/news/loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex.md", "text": "https://wpnews.pro/news/loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex.txt", "jsonld": "https://wpnews.pro/news/loop-engineering-visualized-a-world-cup-fan-journey-with-serpapi-and-codex.jsonld"}}