Satellite imagery is powerful, but using it effectively often requires knowing much more than how to ask a question.
A typical Earth-observation workflow can involve remote sensing concepts, GIS tools, image-processing pipelines, satellite sensors, geospatial datasets, computer vision models, and specialized analysis techniques. For an experienced geospatial engineer, that complexity is manageable. For everyone else, it can become the barrier between having a question and actually getting an answer.
That is the problem we are trying to solve with SatQuery AI.
SatQuery AI allows users to interact with satellite imagery and Earth-observation data using natural language. Instead of forcing users to understand the underlying tools first, we let them start with the question.
For example:
"Where has vegetation decreased in this area?"
"What changes occurred between these two satellite images?"
"Detect buildings in this region."
The system follows a simple conceptual pipeline:
Ask → Understand → Analyze → Verify → Visualize → Explain
But while building this kind of system, we found a problem that is easy to underestimate:
A chatbot is not truly conversational just because users can send multiple messages.
For analytical applications, the system needs to understand what previous messages mean in relation to the current request.
The Real Problem: Context, Not Chat
Consider this interaction.
User:
Analyze these two images for vegetation change.
SatQuery AI interprets the request, identifies the two images, understands that the requested analysis is vegetation change, and performs the appropriate analysis.
The user then says:
Now focus only on the northern region.
That sentence is incomplete by itself.
Northern region of what?
The current image? The previous image? The original study area?
A human would normally understand that this refers to the region being analyzed in the previous request. A conversational analytical system needs to make the same connection.
Then the user asks:
How much did it decrease compared with the previous image?
Now the system needs even more context. It needs to understand what "it" refers to, which region is currently selected, and which previous image is being used as the comparison baseline.
This is where conversational memory becomes an engineering problem rather than simply a chat feature.
How SatQuery AI Handles an Analytical Request
At a high level, we treat each natural-language request as an analytical task that needs to be translated into structured requirements.
For example:
User:
"Where has vegetation decreased in this area?"
↓
Target: vegetation
Analysis: change detection
Location: current area
Time: available imagery period
Output: changed regions + measurements
↓
Run analysis
↓
Verify result
↓
Visualize affected regions
↓
Explain findings
The system can perform or invoke workflows involving:
Object detection
Segmentation
Change detection
Image comparison
Vegetation analysis
Land-use and land-cover analysis
Object counting
Geospatial analysis
The important part is that the conversational layer does not replace the underlying analysis.
It acts as an interface to it.
If a user asks to detect buildings, the system needs to connect that request to an appropriate object-detection workflow. If the user asks about vegetation change, it needs to understand that this is a temporal comparison rather than simply an image-description task.
The resulting answer can contain detected regions, counts, change areas, percentages, confidence information, and geospatial information, depending on the analysis being performed.
We then visualize those results on the satellite imagery or map and explain them in natural language.
Before and After: Why Memory Changes the Interaction
Without useful conversational memory, a user may have to repeat information:
User:
Analyze these two images for vegetation change.
System:
Vegetation change analysis completed.
User:
Focus only on the northern region.
System:
Which images and study area should I use?
That technically works, but it creates a poor analytical workflow.
With useful context:
User:
Analyze these two images for vegetation change.
System:
I analyzed the two images and identified areas showing vegetation change.
User:
Now focus only on the northern region.
System:
I’ll restrict the analysis to the northern region of the previously analyzed area.
User:
How much did it decrease compared with the previous image?
System:
I’ll compare the vegetation in that selected northern region against the previous image.
The difference is not the number of messages.
The difference is that the system can maintain the meaning of the conversation.
What Should an Agent Actually Remember?
This is an important design question.
I don't think useful memory means simply storing every message forever.
For SatQuery AI, useful context can include things such as:
The images currently being analyzed
The selected geographic region
The current analysis type
The object or feature being investigated
The time period or comparison baseline
Previous analytical decisions
User-defined constraints
References such as "this region" or "the previous image"
For example, after the user says:
"Focus only on the northern region."
the useful information is not necessarily the entire sentence. The important context is that the current geographic scope has changed to the northern portion of the previously selected study area.
This distinction matters.
Conversation History Is Not Automatically Agent Memory
One of the assumptions I wanted to challenge while thinking about SatQuery AI was that keeping the entire conversation automatically solves memory.
It doesn't.
A conversation transcript is a record of what was said. Useful agent memory is about retaining information that helps the system make better decisions later.
Imagine a long satellite-analysis session containing dozens of messages:
"Show buildings."
"Actually exclude industrial buildings."
"Compare with the previous image."
"Zoom into the eastern side."
"Use the earlier boundary."
"Now count them."
If the system treats every message equally, it becomes increasingly difficult to determine which information is currently relevant.
Memory needs to help preserve useful context rather than simply accumulate text.
For this part of SatQuery AI, we use Hindsight as part of our conversational architecture. Hindsight provides an agent-memory layer that we can use to retain useful context across interactions.
Hindsight GitHub�
Hindsight Documentation�
The broader concept of agent memory is also described by Vectorize:
Vectorize: What Is Agent Memory?�
A Simple Mental Model
We think about the system roughly like this:
User message
↓
Understand intent
↓
Retrieve useful context
↓
Build analytical request
↓
Run satellite analysis
↓
Verify result
↓
Visualize
↓
Explain
↓
Store useful context for later
The memory layer sits around the conversation rather than replacing the analysis engine.
That separation is important.
The memory should help answer:
"What does the user mean right now?"
The analysis workflow should answer:
"What does the satellite data actually show?"
Those are different responsibilities.
The Risk of Remembering the Wrong Thing
Memory also introduces a new failure mode.
Suppose a user analyzes Area A and later starts working with Area B.
If the system incorrectly carries the previous geographic context into the new analysis, a perfectly valid analysis pipeline could produce an answer for the wrong area.
That is potentially worse than asking the user to repeat themselves.
This is why conversational memory should not be treated as unquestionable truth.
For analytical systems, remembered context needs to be relevant to the current request and should be checked against the current inputs whenever possible.
We want the system to be conversational without becoming blindly confident.
Verification Still Matters
SatQuery AI therefore follows an important principle:
Natural-language understanding should lead to analysis, not replace verification.
If the system identifies vegetation change, the result should remain connected to the underlying image-analysis process.
If it detects buildings, the user should be able to see the detected regions.
If it calculates a change percentage, that measurement should correspond to the analyzed region and comparison period.
The conversational response is the explanation layer—not the source of truth.
What We Learned
Building SatQuery AI has reinforced several lessons that apply beyond satellite imagery.
- Conversational UX is really a context-management problem Multiple messages do not automatically create a meaningful conversation. The system needs to understand references across turns.
- Memory should preserve meaning, not just transcripts Remembering everything is not the same as remembering what is useful. Analytical systems need relevant context.
- AI should connect language to deterministic analytical workflows The user should be able to ask naturally, but the resulting analysis still needs a concrete computational process behind it.
- Visualization is part of verification For geospatial analysis, showing the detected or changed regions on the imagery can make the result much easier to inspect than a text-only answer.
- Memory must be treated as fallible Incorrect remembered context can lead to incorrect analytical scope. We need mechanisms that keep conversational context aligned with the actual images, regions, and analysis being performed. Where This Leads Our goal with SatQuery AI is not simply to put a chatbot in front of satellite imagery. The more interesting challenge is building an interface where users can conduct an evolving analytical investigation through conversation without needing to repeatedly restate the entire problem. A user should be able to start with: "Find vegetation loss." Then narrow it: "Only in the northern region." Then compare it: "How much changed from the previous image?" Then investigate further: "Show me the areas with the largest decrease." Each request builds on the previous one. That is what we mean by making satellite analysis conversational. The difficult part is not making the system understand one question. The difficult part is making it understand the next question in the context of everything that matters from the questions before it.
Top comments (0)