I submitted a proposal for a demo at the Agentic AI for Earth Observation workshop in Berlin. It wasn’t selected, and after walking around the demonstrations for three days, I was almost relieved.
And that’s because my demo would have looked much like several of those on the screens. Many of them had a natural language interface with suggested prompts, through which a workflow was orchestrated to access data and return text, charts and maps showing the results. The underlying implementations were different, sometimes considerably so, but I recognised the experience they were trying to offer because I’d been working on much the same thing.
I could imagine getting used to a common interface across geospatial platforms, much as we have with other kinds of software. As I went through the demonstrations, I was looking for questions each system could answer that would previously have required considerable work, and trying to understand what an agent added to analyses we already knew how to run.
I kept thinking about Will Marshall’s 2018 TED talk, where he described his vision of searching the Earth’s surface the same way we search the internet: “abstracting out the imagery entirely and just having a queryable interface to the Earth”.
That was one of the first things that inspired me and helped draw me into EO. Planet and Microsoft demonstrated a version of it in their 2023 proof of concept, Queryable California, using natural-language questions to explore information derived from satellite imagery. Now, agentic systems are attempting more of the work behind those answers, including finding observations and choosing methods.
I believe the timing of the workshop was spot on! The Model Context Protocol (MCP), which provides a common interface for connecting AI systems to data and tools, had appeared in November 2024, followed in April 2025 by Agent2Agent (A2A), which supports communication between agents. People had time to build and test different approaches, while still disagreeing about fairly basic choices. How many tools should an agent have access to? How much freedom should it have to choose a methodology, and how would we evaluate the result? Those questions came up throughout the workshop, alongside implementations that gave us something concrete to discuss. ESA had also released Earth Virtual Expert (EVE) shortly before the event, with a public release focused on scientific questions and answers. The experimental integrations and open MCP registry presented at the workshop gave us a sense of what people were trying to build around it.
In the opening speeches, I kept hearing variations of “see more clearly, understand more deeply, act.” We’ve spent years trying to turn EO information into the “actionable insights” that appear in so many product descriptions, and I wasn’t sure how much of the difficulty in that final stretch — or rather, the marathon at the end of the triathlon— people expected agents to resolve. A customer usually has other information to consider and an existing process for making decisions, which the EO service will somehow have to fit into.
Is the agent the missing piece and perhaps the enabler of that integration?
What agents add to the workflow
Last December, I built a small FastMCP interface for discovering imagery through natural language in Microsoft Planetary Computer’s STAC catalogue, which follows the STAC standard for describing geospatial data. Getting it to the point where it somewhat worked wasn’t especially difficult. I’d have had considerably more work to do before trusting it with ambiguous requests or unavailable data, which made me curious about how the systems in Berlin handled cases beyond their prepared demonstrations.
One presentation used flood response to explain why agents were needed. Given a flood map, the system would identify affected schools, hospitals and roads, estimate exposure and help prioritise a response. I found the comparison with a flood map too generous to the agent, since intersecting it with infrastructure, calculating exposure and analysing a road network are established GIS operations that a conventional workflow could already carry out.
With known inputs and a recurring question, I’d prefer a tested workflow whose calculations are defined and reproducible. An agent could call perfectly deterministic GIS tools in the wrong order, or choose the wrong ones altogether, and still return a plausible map. I wasn’t convinced that having it decide on those steps each time would improve the analysis.
If I were to add something to that presentation, I’d focus on what happens when we need to integrate unfamiliar data. Suppose a local authority supplies a road network with different attributes and coordinate systems, or a new provider delivers the flood layer in a format our workflow doesn’t support. We might need to replace a source that has become unavailable. I can see an agent being useful in working through those changes and preparing compatible inputs for an analysis we’ve already developed and tested. We already have tools for routine format and coordinate conversions. More complicated schema adaptation can silently introduce mistakes in units, geometry or spatial reference systems. Still, I’d probably want those adapted inputs checked before they reached the tested workflow.
To me, that seems a more useful case than asking an agent to reconstruct the same sequence of GIS operations on every run.
There is another benefit that shouldn’t get lost in my scepticism about chat interfaces. Someone shouldn’t need to know Python, raster processing or how to access data to ask a legitimate question about their environment. Salman Khan, from Mohamed bin Zayed University of Artificial Intelligence, discussed small models, local languages and access for people with limited technical infrastructure, while Development Seed’s lightweight models and their work on Global Nature Watch reflected a similar interest in accessibility. Making an established analysis easier or cheaper to use can be valuable in itself, provided the person using it can also understand when the available data cannot support an answer.
Autonomy is a spectrum
For many of the open-ended EO and GIS questions in the demonstrations, there was broad agreement that a human in the loop is still essential. Even if an agent can run the tools, someone needs to judge whether the observations, methods and conclusions hold up.
The space-operations presentations offered an interesting comparison in terms of autonomy. CS Group described work connecting event detection with satellite tasking, while Steve Chien’s presentation of NASA/JPL’s Federated Autonomous Measurement (FAME) explored how spacecraft could coordinate follow-up observations. Chien spoke about humans-on-the-loop, supervising systems within agreed limits while systems handle acquisition windows and competing requests. With dynamic targeting, onboard analysis can change what a satellite observes during a pass, sometimes within seconds, when there may be little opportunity for human intervention. There is considerably more autonomy in these applications, although the decisions take place within defined mission objectives and operational constraints. Autonomous scheduling also predates LLM agents, and FAME’s wider federation plans extend beyond what has been demonstrated so far.
How we judge the result
If I had one euro for every mention of trust, reliability, transparency, provenance, traceability, reproducibility or uncertainty during the workshop, I could probably pay for another conference trip.
We’ve been discussing most of these things in remote sensing for years, and I remember similar conversations around explainable AI. With agentic systems, there’s more to inspect because the software may also be deciding which observations to use and which methods to apply. Most of the demonstrations I saw exposed logs and execution traces, making it possible to follow those decisions through the analysis.
After all the energy we’ve spent on “explainable AI”, I find it ironic how easily we can feel reassured by a list of tool calls, while still struggling to understand what the models have learned or what their embeddings represent.
In Salman Khan’s keynote, a rainfall calculation combined ERA5 with a vegetation mask. One agent returned 383.7 mm against a reference of 27.39 mm, about fourteen times as much, and received a higher workflow score than another agent whose answer of 27.31 mm was within the accepted tolerance. Scoring the recipe — the tool choices and execution — and scoring the output led to different conclusions about which run performed better.
Having access to the tool calls, inputs and intermediate outputs helps us identify a mistake, including one in an analysis that is perfectly reproducible but scientifically flawed. Mistral’s Jacopo Chevallard also made a useful point about preserving the data, processing environment and tool versions used in a run: if an archive has been reprocessed or a service has changed, a comparison between agents may also become a comparison between different versions of the data and services they accessed.
Axis Spatial’s EO Agent Arena reported much stronger results on guided GIS workflows than on autonomous tasks, with different task sets limiting how directly those scores can be compared. Adding image-processing tools helped some models and made others worse in the reported tests. I’d like to see tool selection evaluated as carefully as the agents themselves, especially as the registries of EO capabilities grow.
I also liked Christopher Forrest Brown’s criticism of how we benchmark these systems. We often give a model carefully prepared imagery, from an appropriate sensor and date, with the task already defined. In practice, deciding what data to use and whether the observations are suitable can take a substantial part of real EO work. Then there’s the other end of the process, where an improvement in model accuracy may be of little consequence if the analysis is too expensive, arrives too late or doesn’t satisfy the user’s actual requirements.
Brown, from Google DeepMind, illustrated another difficulty with a seemingly simple question: how much of Massachusetts consists of beaver swamp? An agent could put together a sophisticated workflow using wetland maps, satellite observations and statistical estimation, leaving us to decide whether those measurements could reliably identify wetlands created by beavers.
He also identified problems with the checks on the result. The National Wetlands Inventory (NWI) layer appeared as a reference and later as a cross-check, raising a question about the independence of that check, while visually labelling aerial-image samples brought us back to whether the imagery could establish that a wetland was created by beavers. We could validate each tool separately and still combine them into a scientifically questionable analysis. How many of our benchmarks would reward an agent for recognising that it needs more information, or that the available observations cannot support the requested conclusion?
The role of institutions
Andres Camero spoke about the trust organisations place in DLR. His comments got me thinking about the different pressures institutions and private companies face when adopting new technologies. In EO, companies are often under considerable pressure to turn new capabilities into demos, MVPs and eventually paying products. Institutions such as DLR have built their reputations over decades of scientific and operational work, and have to be careful when introducing new methods into services people already rely on.
I find ECMWF’s adoption of AI forecasting a particularly good example of this more deliberate approach. Its AI Forecasting System (AIFS) became operational in 2025 alongside the established physics-based Integrated Forecasting System (IFS), following extensive evaluation across different forecasting conditions and work with Member States and users. Both systems continue to be verified, and AIFS has been brought into ECMWF’s operational support arrangements. There’s something reassuring about that level of care when new AI capabilities can move from demonstration to commercial product so quickly.
Institutions such as ESA, DLR, ECMWF and EUMETSAT could play a much larger role in guiding the development of agentic EO. There was still a great deal of uncertainty in Berlin about which approaches were worth pursuing, and these organisations have decades of experience evaluating new methods and deciding when they are reliable enough for operational use. I’d like to see more independent comparisons, with results and failures shared openly, to help researchers and companies decide where to put their effort.
Building better scientific tools
Brown suggested that increasingly capable general-purpose agents might eventually absorb much of the orchestration we’re currently building into specialised systems. I wouldn’t take that for granted when deciding where to put our effort now. Khan’s planner-and-executor results and Mistral’s work on specialist tools and verification gave us reasons to keep investigating those approaches as general models improve.
During the discussion after Brown’s keynote, I asked where our domain expertise should enter a system whose steps we don’t want to prescribe in advance. I was thinking about how we’d help it choose appropriate observations and methods, and whether that knowledge belonged in the prompt, the tools or the verification. His answer, as I understood it, was that it should be incorporated throughout.
STAC helps us describe and discover datasets, openEO provides process graphs, and OGC API - Processes provides a standard way to describe and execute processes. An MCP server can expose those capabilities to an agent, while EVE’s registry gives developers a place to share the tool interfaces. An agent choosing a burned-area mapping tool needs to know which sensors and processing baselines it supports, what observations it requires before and after a fire, and where it has been evaluated. That includes conditions under which harvesting or seasonal changes might be mistaken for burning, and how independently the reference data were collected.
Suppose its only available post-fire image falls outside the method’s validated time window. The code could still run and produce a plausible polygon, so a check built into the tool could flag the unsupported input before processing begins. The agent could then look for another method or additional observations, explaining when a reliable estimate isn’t possible with what it has. Documentation would help it make the initial choice, while executable checks could catch specified problems during the run, leaving scientific review to address questions those checks cannot resolve.
Some of this information already exists in documentation, process metadata and testing systems, although it isn’t always easy for an agent to find and use. Common conventions could help make it available through existing standards. We could compare agents given ordinary tool descriptions with agents given evaluation results, known limitations and relevant checks, and see how often they select a suitable method or recognise a use outside its validated conditions.
In the workshop’s “Subway Takes” session, someone argued that we already have too many geospatial foundation models. Brown also questioned how far the growing number of published models had translated into operational use. A poster comparing TerraMind and THOR looked at performance and computational requirements across downstream tasks. Comparisons like that can help us understand what the existing models do well, and where they fall short.
My sympathy with the “too many foundation models” argument comes mostly from the economics of it. Training a large geospatial foundation model can run into millions of euros once compute, data preparation and engineering are included. Before making that investment, we should be able to explain what the existing models and conventional methods still fail to do, and what another model would improve.
James Zou’s presentation of Paper2Agent had me thinking about how much published EO work remains difficult to reuse. The project turns papers and code into executable tools and tests whether they reproduce the original results. Someone in the hot-take session worried that research might become less scientific as LLMs take on more of it, and I share the concern about a kind of paper-to-paper commentary, where systems consume publications and help produce new ones with little independent testing along the way. Reproduction and reanalysis can help us examine what a method actually measures and whether the results justify the conclusions. We were quite capable of publishing sloppy science before 2024. Some of that flawed literature may now be among the material agents draw on when choosing methods, so a faithful implementation can carry an old methodological weakness into new work.
Coding agents could also help with methods we’ve struggled to develop or apply. There are observations in archives beyond the familiar Sentinel-2 and Landsat workflows that remain difficult to exploit, and scientific work that takes considerable effort to implement or repeat. We could spend some of the time saved on programming working with those observations and investigating new ways of making measurements.
Operational context
Linda Sheard from Xoople spoke about agents needing access to an organisation’s operational context, and I recognised the problem from EO work. We often talk about EO services delivering “actionable insights”, but the map or statistic we produce is usually one input into somebody else’s process. A company may already combine information from several EO providers with its own records, policies and procedures. Much of what determines the next action sits in those systems, which the EO provider may have little access to.
One conversation at the workshop concerned detecting individual solar panels from high-resolution imagery. Even at around 25 cm resolution, models can struggle when moved from one country to another. Suppose an insurer wants to find installations missing from the records of properties it covers. The detections would have to be matched to the correct buildings and insurance records, then compared with what the company already knows. A suspected installation might warrant a review, but the detection alone wouldn’t tell the insurer what to do. A missed panel and a false detection have different consequences, and investigating false alarms across a large portfolio can become expensive. Whether the information is worth buying depends on what the insurer already knows, how else it could obtain that information and whether it would actually change a decision.
I don’t see a reason to put an agent in the middle of every part of that process. If the records are consistent and the business rules are known, conventional software can do much of the matching, checking and routing. An agent might be useful when records are incomplete, sources change or a case requires looking up information across several systems. But an agent could match a detection to the wrong property, too, or decide to update a record that should have gone to someone for review. We’d need to be just as careful about those choices as we are about the EO analysis itself.
That also raises the question of whose agent would do the work. An EO provider could make a tested analysis available as a tool, perhaps through MCP, for the customer’s own systems to call. If an agent is coordinating what happens next, it probably needs to sit closer to the company’s records and procedures, where the relevant context is. The customer would still have to decide what information the agent can access, what should trigger a review and which changes require approval. Making an EO service callable doesn’t settle any of that.
In the insurance example, the detections might be ready in minutes, while the insurer still has to match them to its records and decide which cases need a closer look. I’d want to know whether an agent reduces that work, including the checking and corrections it introduces.
Marcin Detyniecki’s comments about AXA’s scale brought home how different the costs can look once an analysis runs across a large portfolio and several countries. By the time we’ve paid for imagery, processing and reference data, checked the results and connected them to customer systems, the LLM bill may be one of the smaller expenses. Even a small false-positive rate can leave a large number of cases to review at that scale.
Julia Gottfriedsen from Constellr stressed instrument-specific expertise and human review before information reaches a customer. That seems especially important if the result can pass directly into the customer’s own systems. I kept thinking about the pressure to turn a demonstrator into a product that brings in revenue, and how easily a convincing interface can make the work behind it look ready. If methods haven’t been tested for the places and conditions in which they’re sold, sloppy work can end up inside the customer’s procedures, creating more work for them and consuming credibility we may struggle to rebuild.
When was the last time you wrote a line of code?
During a coffee break in Berlin, someone asked when we’d last written a line of code ourselves. For several people in the group, it had been months. Coding agents have changed my own work too; much of my time now goes into reviewing and testing code I haven’t typed. As Brown put it: “It’s simply faster to be a code reviewer than a code editor.”
I’ve used Star Trek as a comparison before. A conversation with the ship’s computer gives you access to an enormous amount of information and computing power, while Spock and Scotty understand enough about the science and instruments to question what it tells them.
We agreed that having developed our experience and expertise before LLMs has left us better equipped to work with these tools, even when their outputs are unreliable. We can review code we haven’t written because we know something about what it’s supposed to do. I wonder how people entering EO now will acquire that judgement if they rarely have to implement the methods themselves.
I still find the idea of a queryable Earth extraordinary, and Berlin gave me plenty to think about. I enjoy attending these early workshops. Last year’s ESA–NASA International Workshop on AI Foundation Models for EO was the first on that topic, and Berlin was a similar gathering for agentic AI. It’s interesting to see people presenting their work while the field is still figuring out where to go next. Some were sceptical about what agents could actually add, while others seemed to see them as a missing piece in bringing EO into wider commercial use.
I’m curious to see which EO questions become easier to explore as we spend less time writing code and connecting services. There are methods worth revisiting and observations we’ve struggled to work with, and perhaps agents will make some of that work more practical.
I’ve also been noticing the attention given to industry at ESA events. At the Living Planet Symposium, alongside the exhibition booths and panels, there were sessions on bridging the last mile with end users and connecting EO with people from insurance, energy and finance. We’ve spent years discussing how to bring EO into other industries, but we don’t always hear much about what happens to our information once it reaches them. These companies understand their own systems, procedures and costs much better than we do. I’d welcome more opportunities to hear about those processes and the difficulties of integrating EO into them