DEV Community

Sufiya Maheen
Sufiya Maheen

Posted on

Engineering the Scan and Recommendation Agents for a Memory-Driven GEO System

The AI pipeline turns a brand name into two things: a measurable GEO visibility result and a recommendation for what to do next. I worked on both the Scan Agent and the Recommendation Agent, and we kept them as separate modules because they solve two different problems.

• Scan Agent: Gathers and structures evidence.
• Recommendation Agent: Reasons over that evidence and the history stored in Hindsight.

MODULE A: SCAN AGENT

The process starts with a brand name and category. Instead of simply asking a model, “Do you know this brand?”, the agent generates questions based on what a customer would actually search for.

These questions are sent to models representing search engines such as ChatGPT and Perplexity. Each response is then analyzed to determine:

  1. Whether the target brand was mentioned.
  2. Which competitors were mentioned.

The raw responses are also preserved. The scan produces a fixed structure:

{
  "brand": "Acme",
  "timestamp": "2026-01-15T10:00:00Z",
  "queries_tested": ["..."],
  "mentions": 3,
  "total_queries": 20,
  "competitors_mentioned": ["..."],
  "raw_snippets": ["..."]
}
Enter fullscreen mode Exit fullscreen mode

WHY USE STRUCTURED DATA?

It would be easy to pass raw model responses directly into the next prompt. We chose not to do that because a scan should be reusable evidence.

A structured scan can be:

• Stored for later use
• Displayed in the frontend
• Compared with another scan
• Passed to the Recommendation Agent

It also gives the frontend a predictable structure and allows the Recommendation Agent to work without knowing how the original responses were collected.

MODULE B: RECOMMENDATION AGENT

The Recommendation Agent takes two inputs:

  1. The current scan
  2. The Hindsight record containing scan history and the actions log

The actions log is especially important because it records not only what was recommended, but also what was actually tried and what happened afterward.

One rule is built into the system:

“If the actions log is empty, we are at Scan 1. Give a baseline recommendation and clearly acknowledge that there is no previous history yet.”

When previous actions exist, the recommendation must consider what was already tried and whether those actions produced useful results.

WHY KEEP THE AGENTS SEPARATE?

The two agents answer different questions:

• Scan Agent: “What is the current visibility situation?”
• Recommendation Agent: “Given the current situation and what happened before, what should we recommend?”

Keeping them separate makes the system easier to test and integrate.

For example:

• The Scan Agent can be tested using sample inputs without running Hindsight.
• The Recommendation Agent can be tested using a fake scan and progressively richer histories.
• Problems can be isolated as either data collection issues or recommendation reasoning issues.

TESTING SCAN 1, 5, AND 10

The important question is not simply:

“Does the system produce a recommendation?”

The more important question is:

“Does the recommendation change when the memory changes?”

We test this using different stages of history:

• Scan 1: Empty history. The recommendation should be general and honest about the lack of previous evidence.

• Scan 5: Earlier actions and outcomes are available. The agent should begin identifying useful patterns.

• Scan 10: More history is available. The recommendation should become more specific and refer to previous actions and their measured outcomes.

This allows us to test whether Hindsight is actually influencing the recommendation instead of simply being stored in the system without affecting the output.

USING SIMILAR PRECEDENTS

Hindsight also provides a similar-precedent function.

Given a new scan, an AI call can identify a relevant past action or outcome from the same brand or a similar situation. It also provides a short explanation of why that precedent is relevant.

This means the agent does not have to depend only on fixed rules. A previous situation can provide useful guidance even when it is not exactly identical to the current one.

FAKE DATA FIRST

We first built the pipeline using hardcoded data before connecting all the real components.

This helped us identify problems in the data flow and recommendation logic before dealing with integration issues.

The core interface is intentionally simple:

--> Current Scan + Remembered History → Recommendation

The Scan Agent does not need to know how Hindsight stores its data, and Hindsight does not need to generate scans.

This separation gives us a cleaner architecture, makes testing easier, and most importantly, gives us a way to verify whether memory actually changes the recommendations produced by the system.

Top comments (0)