SatQuery AI: Making Satellite Analysis Actually Conversational
I’ve always found the phrase “natural-language interface” slightly misleading when applied to technical analysis systems.
A user being able to type a question in plain English does not, by itself, make the system conversational.
For satellite imagery, the distinction matters. A useful system has to understand not only what the user is asking now, but also what previous requests mean in relation to the current one.
That is the problem we designed SatQuery AI around.
SatQuery AI allows users to interact with satellite imagery and Earth-observation data through natural language. Instead of requiring users to understand remote sensing, GIS, image processing, satellite sensors, computer vision, or geospatial datasets, we let them describe the analysis they want.
For example:
“Where has vegetation decreased in this area?”
“What changes occurred between these two satellite images?”
“Detect buildings in this region.”
The intended workflow is straightforward:
Ask → Understand → Analyze → Verify → Visualize → Explain
The interesting engineering problem is what happens between those steps—and particularly what happens when the user asks a follow-up question.
The interface is easy. The context is not.
Suppose I start with:
User: Analyze these two images for vegetation change.
The system has to translate that request into analytical requirements: which images are being compared, what “vegetation change” means for the selected workflow, which region is relevant, and what type of result needs to be produced.
The analysis can involve image comparison and vegetation analysis. The output may include regions where vegetation changed, percentages, confidence information, and geospatial information.
We then visualize the result on satellite imagery or a map and explain what was found in natural language.
So far, this looks like a conventional AI interface.
Then I say:
User: Now focus only on the northern region.
This is where the conversational problem appears.
What does “the northern region” refer to?
It could mean the northern part of the original geographic area. It could refer to a region previously identified by the analysis. It could even be a region mentioned earlier in a longer conversation.
The system cannot safely treat this as an entirely new request.
It needs to connect the new instruction to the previous analytical state.
Then I might ask:
User: How much did it decrease compared with the previous image?
Now the system needs even more context.
“It” refers to vegetation.
“Decrease” refers to the vegetation-change analysis.
“The previous image” refers to the temporal comparison already established.
The geographic scope should remain the northern region I just selected.
A system that understands only the latest message has lost most of the meaning.
That is why I consider conversational memory an architectural component rather than a convenience feature.
What SatQuery AI actually needs to remember
The obvious solution is to keep the entire conversation and send it back to the model on every request.
I don’t think that is equivalent to useful agent memory.
A conversation transcript is a record of what was said. Memory is about retaining information that remains useful for future reasoning.
For SatQuery AI, useful context can include things such as:
- The imagery currently being analyzed
- The geographic area under discussion
- The current analytical task
- The objects or phenomena being investigated
- Previous analytical results
- User-selected regions or constraints
- References such as “this area,” “that image,” or “the previous result”
- Relevant conclusions established earlier in the conversation
Not every sentence deserves to become persistent memory.
For example, if I say:
“That result looks interesting.”
There may be little durable analytical information in that sentence.
But if I say:
“For the rest of this analysis, focus on the northern region.”
that constraint can materially affect subsequent requests.
This distinction is important because memory affects the system’s interpretation of future requests.
Where Hindsight fits
We use Hindsight agent memory as part of SatQuery AI’s conversational architecture.
Hindsight is designed for persistent agent memory, allowing an agent to retain and retrieve useful information across interactions rather than treating every request as completely isolated.
The project is built around the idea that an AI system should be able to accumulate relevant context over time and use it when interpreting new requests.
For reference, the Hindsight project is available on GitHub, with documentation at hindsight.vectorize.io. Vectorize also provides an overview of agent memory.
The important architectural distinction for us is this:
User message
↓
Understand current request
↓
Retrieve relevant conversational context
↓
Combine current request + useful memory
↓
Determine analytical requirements
↓
Run analysis
↓
Verify result
↓
Visualize + explain
↓
Store useful new context
The memory layer therefore sits around the analytical conversation rather than replacing the analysis itself.
Before and after: the difference is subtle
Without useful conversational memory, an interaction can look like this:
User: Analyze these two images for vegetation change.
System: [performs vegetation-change analysis]
User: Focus only on the northern region.
System: Which images and analysis are you referring to?
User: The ones we just analyzed.
The user is now doing the work the system was supposed to do.
With useful context:
User: Analyze these two images for vegetation change.
System: [performs analysis and visualizes changed vegetation regions]
User: Focus only on the northern region.
System: [interprets "northern region" in the context of the
previous analysis and updates the relevant geographic scope]
User: How much did it decrease compared with the previous image?
System: [interprets "it" as vegetation and "previous image"
as the earlier image in the established comparison]
The second interaction feels conversational because the user can refer to concepts indirectly.
That is the real value of memory: it changes what the user has to repeat.
Memory should support analysis, not replace verification
There is an important distinction here.
A remembered statement is not automatically ground truth.
Suppose the system previously interpreted “northern region” incorrectly. If that interpretation is stored and repeatedly retrieved, the error can become persistent.
That creates a particularly dangerous failure mode for analytical systems.
Imagine:
User: Analyze vegetation loss in this area.
The system incorrectly associates “this area” with the wrong geographic boundary.
Later:
User: Now calculate the percentage decrease there.
If the memory system faithfully retrieves the wrong region, the conversational experience may look excellent while the analytical result is wrong.
That is why SatQuery AI needs a separation between remembering context and verifying analytical facts.
Memory can tell us what the conversation was referring to. The underlying analysis still needs to establish what the imagery actually shows.
In other words:
Memory provides context; analysis provides evidence.
I consider that separation essential.
The analytical layer remains the hard part
Natural language is only the entry point.
Once SatQuery AI understands a request, it may need to invoke workflows for:
- Object detection
- Segmentation
- Change detection
- Image comparison
- Vegetation analysis
- Land-use and land-cover analysis
- Object counting
- Geospatial analysis
The request therefore needs to become something more structured.
Conceptually:
request = {
"target": "vegetation",
"analysis": "change_detection",
"location": current_region,
"time_comparison": {
"previous": image_a,
"current": image_b
}
}
The exact implementation can vary, but the architectural idea is consistent: the conversational layer should extract analytical requirements rather than directly pretending that a language model has performed the geospatial analysis.
After the workflow runs, the system can produce structured information such as changed regions, counts, percentages, confidence information, and geographic information.
That information can then be visualized and explained.
A useful conversation creates state
This changes how I think about the interaction model.
A conventional request-response system looks like:
Request → Response
A conversational analytical system is closer to:
Request
↓
Context
↓
Analytical state
↓
Analysis
↓
Verified result
↓
Updated context
↓
Next request
The state is not necessarily a giant object containing everything ever said.
It is the subset of information that helps the system correctly interpret what comes next.
That makes follow-up questions much more natural.
Instead of:
“Analyze image B against image A for vegetation change in the northern section.”
every time, I can say:
“What about the southern section?”
The user is communicating like a person because the system maintains enough context to make that communication meaningful.
The failure mode I care about most
The most subtle memory failure is not forgetting something.
It is remembering something incorrectly and confidently reusing it.
For a general chatbot, an incorrect remembered preference might be annoying.
For satellite analysis, an incorrect remembered location, image reference, time period, or analytical assumption can affect the meaning of an entire result.
This means memory retrieval should not be treated as unquestionable truth.
We need to consider questions such as:
- Is this memory actually relevant to the current request?
- Is it still applicable?
- Did the user explicitly change the scope?
- Is the remembered information a user instruction or an analytical conclusion?
- Does the current imagery contradict the remembered interpretation?
- Should the system ask for clarification rather than infer?
There is a point where asking a clarification question is better engineering than making a clever guess.
For example:
“When you say the northern region, do you mean the northern half of the original study area or the northern change region detected in the previous analysis?”
That may feel less magical, but it is considerably safer.
What I learned building around this model
- Conversational UX is fundamentally a state-management problem
Supporting multiple messages is easy.
Maintaining the correct meaning across those messages is much harder.
- Not everything deserves memory
A transcript contains everything. Useful memory should contain information that can improve future reasoning.
- Memory and evidence are different things
Remembering that the user asked about vegetation loss does not prove vegetation loss occurred. The analytical workflow still needs to produce and verify the result.
- Ambiguity should sometimes trigger clarification
A system that always resolves ambiguous references automatically can appear intelligent while silently producing incorrect analyses.
- Visualization closes the loop
For geospatial questions, a textual answer alone is often insufficient. Showing detected regions, changes, counts, or other results on the imagery gives the user something concrete to inspect.
Where I think the architecture matters
The interesting part of SatQuery AI is not simply putting a chatbot in front of satellite imagery.
The useful abstraction is:
natural language → analytical intent → geospatial workflow → verified result → visual explanation → persistent context
Hindsight fits into that loop because analytical conversations are inherently stateful. Users naturally build on previous questions, and phrases such as “there,” “that region,” “the previous image,” and “only those buildings” are meaningful precisely because something happened earlier.
If we treat every message as independent, the user has to repeatedly reconstruct the state.
If we remember everything indiscriminately, we risk carrying irrelevant or incorrect context forward.
The engineering challenge is therefore somewhere in between: retain the context that makes the next analytical question understandable, while keeping verification anchored to the underlying Earth-observation data.
That is what makes SatQuery AI conversational in a meaningful sense.
Not the chat box.
The continuity of reasoning behind it.
Top comments (0)