SatQuery Al: Building a Conversational System for Satellite-Image Analysis

shanmukhamanidhar — Mon, 28 Sep 2026 15:40:10 +0000

SatQuery AI: Building a Conversational System for Satellite-Image Analysis
I built SatQuery AI around a simple idea: I wanted users to interact with satellite and Earth-observation imagery through natural language rather than having to translate every question into a sequence of specialized image-processing and geospatial operations.
A user should be able to ask:
“Where has vegetation decreased?”
or:
“What changed between these two satellite images?”
or:
“Detect buildings in this region.”
But building a system that answers these questions reliably is fundamentally different from building a chatbot.
The distinction I kept coming back to was:
A language model can explain an answer, but the satellite-analysis pipeline has to provide the evidence.
That distinction shaped the architecture of SatQuery AI.
From Questions to Evidence
A conventional conversational AI system can take a question, generate an answer, and return it directly. That approach is not sufficient when the answer depends on information contained in an image.
Suppose I ask:
“Show me the areas where vegetation decreased between these images.”
A language model can generate a plausible explanation of vegetation change. But generating a sentence is not the same as detecting vegetation change.
For SatQuery AI, the workflow is closer to:
Ask → Understand → Analyze → Verify → Visualize → Explain
The natural-language layer first needs to understand what the user is asking. The system then needs to determine what type of Earth-observation analysis is appropriate and execute that analysis against the available imagery.
Depending on the request, that could involve object detection, segmentation, change detection, image comparison, vegetation analysis, land-use and land-cover analysis, object counting, or other geospatial operations.
The important part is that the analytical pipeline produces an actual result.
For the vegetation example, that result might contain regions identified as changed, measurements associated with those regions, percentages, confidence information, or other relevant geospatial information.
Only after that evidence exists does the conversational layer have something meaningful to explain.
Separating Understanding from Execution
One architectural decision I found important was keeping natural-language understanding separate from analytical execution.
Conceptually, the system can be viewed as several layers:
Natural-Language Query
↓
Query Understanding
↓
Analysis Planning
↓
Analytical Execution
↓
Evidence / Results
↓
Visualization
↓
Natural-Language Explanation
The language model is therefore not treated as the source of truth for visual analysis.
Its job is to understand the request and communicate the result. The specialized analytical pipeline is responsible for producing the underlying evidence.
A simplified representation of the routing logic looks like this:
query = "Show me the areas where vegetation decreased"

intent = understand_query(query)

if intent.type == "vegetation_change":
result = run_change_analysis(
image_a,
image_b
)

answer = explain_result(result)
The actual implementation can become considerably more complex, but the separation is important. It prevents the conversational component from becoming responsible for calculations and visual conclusions it cannot independently establish.
Making the Result Visual
Another important part of the system is that the result should not end as text.
If an analysis identifies regions of vegetation change, those regions need to be represented on the imagery or map.
Conceptually:
result = analyze(images)

visual_layer = create_visualization(
image=images,
regions=result.regions
)

return {
"evidence": result,
"visualization": visual_layer
}
This gives the user two complementary forms of information.
The visualization answers:
“Where did this happen?”
The analytical result answers:
“What did the system measure?”
And the natural-language explanation answers:
“What does this result mean?”
Keeping these three responsibilities distinct makes the interaction easier to reason about.
Before and After: Turning a Query into an Analysis
Without this separation, a conversation might look like this:
User
Show me the areas where vegetation decreased between these images.
AI
Vegetation decreased in several areas between the two images.
That answer sounds reasonable, but it provides little evidence.
With the SatQuery approach, the interaction is intended to become:
User
Show me the areas where vegetation decreased between these images.
System
Identifies the request as a vegetation-change analysis.
Analysis pipeline
Processes the two images and identifies relevant regions.
Visualization
Highlights those regions on the satellite imagery.
System
Reports the resulting measurements and relevant confidence information.
AI
Explains what the analysis found in natural language.
The difference is subtle from the user's perspective, but significant from an engineering perspective. The second workflow has an explicit analytical stage between the question and the answer.
Adding Conversational Memory with Hindsight
Once the system can perform individual analyses, another problem appears: users naturally want to continue the conversation.
For example:
User
Show me the areas where vegetation decreased between these images.
After receiving the result, the user might ask:
Now compare those regions with the previous analysis.
The second question depends on context from the first interaction.
I integrated Hindsight as the agent-memory layer for this part of SatQuery AI. Hindsight is designed to provide persistent memory for AI agents, allowing useful information from previous interactions to remain available instead of treating every interaction as completely isolated.
Hindsight on GitHub⁠�
Hindsight Documentation⁠�
Vectorize — What is Agent Memory?⁠�
The distinction I found useful is that memory should preserve context, while the analytical pipeline should preserve evidence.
For example, memory can help establish that “those regions” refers to regions identified during an earlier vegetation analysis. It does not mean that memory itself becomes the source of the satellite-analysis result.
Conceptually:
context = hindsight.retrieve(query)

analysis_request = understand_query(
query=query,
context=context
)

result = execute_analysis(analysis_request)

hindsight.remember(
query=query,
result_context=result
)
This makes the interaction conversational without collapsing the boundaries between memory, reasoning, and analysis.
The Architecture I Ended Up Thinking About
I think about SatQuery AI as six cooperating components rather than one large AI system.

Natural-Language Understanding This layer interprets what the user wants. It extracts the intent and relevant parameters needed to construct an analytical request.
Analytical Execution This is where the actual image and geospatial processing happens. The appropriate operation is executed against the supplied Earth-observation data.
Evidence and Results The output of the analytical pipeline is treated as the evidence layer. This can include detected regions, object counts, change areas, percentages, confidence information, and geospatial information.
Visualization The analytical results are translated into visual overlays or other representations that can be displayed on satellite imagery or a map.
Conversational Memory Hindsight provides persistent agent memory so that subsequent interactions can refer to relevant previous context.
Natural-Language Explanation Finally, the conversational layer turns the analytical result into an explanation that a user can understand. This separation gives each component a relatively clear responsibility. A Design Challenge: Memory Is Not Ground Truth One of the challenges I had to keep in mind is that persistent memory can make an agent feel more intelligent while also creating another source of potential confusion. If a previous interaction says that a particular region was important, a later query may depend on that context. But remembered context should not automatically be treated as a fresh analytical conclusion. This is especially important for Earth-observation systems because the underlying data can change, the user can switch datasets, and the meaning of a query can depend on the imagery being analyzed. I therefore see memory as a mechanism for continuity, not a replacement for analytical verification. The same principle applies to the language model itself. A model can interpret: “Compare those regions with the previous analysis.” But it should not invent what “those regions” contain. The system needs to connect that reference to previously established analytical context and, where necessary, perform the appropriate analysis again. What I Learned Building It
AI reasoning and evidence should be separate A language model is very good at interpreting language and explaining information. That does not make it an image-analysis engine. Keeping those responsibilities separate makes the system easier to reason about.
Visualization is part of the answer For geospatial problems, coordinates, regions, overlays, and measurements can communicate information that text alone cannot. A textual answer without a corresponding visual result can leave an important part of the user's question unanswered.
Conversational memory needs boundaries Persistent memory makes multi-step interactions much more natural, but remembered context should not be confused with verified analytical evidence.
The analytical pipeline should remain modular Object detection, segmentation, change detection, vegetation analysis, and other operations should be treated as capabilities that can be composed rather than embedding every operation directly inside the conversational layer.
The hardest part is connecting the layers The interesting engineering problem is not simply adding an LLM to a satellite-image application. It is designing the interfaces between language understanding, analytical execution, evidence, visualization, memory, and explanation. Conclusion SatQuery AI changed how I think about conversational interfaces for visual and geospatial systems. The goal is not to make a language model pretend that it can answer every question about an image. Instead, the language model becomes the interface through which a user describes an analytical task. The underlying Earth-observation pipeline produces the evidence. The visualization makes that evidence inspectable. The memory layer preserves conversational continuity. And the language model explains the resulting information. That separation leads back to the principle that shaped the project: A language model can explain an answer, but the satellite-analysis pipeline has to provide the evidence.

DEV Community: shanmukhamanidhar

SatQuery Al: Building a Conversational System for Satellite-Image Analysis