Ask one AI model to summarize a document, and it may work well. Ask the same model to analyse satellite imagery, query a PostGIS database, compare flood boundaries, calculate road closures, and produce a safe route – the workflow starts to break. Even in narrower tasks such as land-use or land-cover change detection, different ways of comparing satellite embeddings can produce very different maps. The problem here is not intelligence alone – it is context. A GIS workflow usually involves multiple data sources, multiple tools, and many spatial rules for any single model to track all at once.

This is where data misinterpretation becomes dangerous. In a normal chatbot, a wrong answer is frustrating. In a geospatial system, a wrong answer can become a fake road, a missing flood zone, or a route that sends responders into risk. Making the model bigger doesn’t fix this. It is to split the work across specialized agents. One agent handles hydrology, another handles routing, another checks imagery, and another talks to the database. This is the practical next step after Agentic GeoAI: not one general agent, but a coordinated geospatial team.

Two protocols are designed to solve this problem.  Anthropic’s Model Context Protocol (MCP) gives an agent a standard way to connect to tools, files, APIs, and databases. Google’s Agent2Agent protocol (A2A) focuses on how agents communicate, delegate tasks, and coordinate across systems. In simple terms, MCP connects an agent to its tools. A2A connects agents to each other.

This article looks at how this “geospatial agent stack” works, why MCP and A2A solve different problems, how a post-disaster routing workflow could be designed, and why geometry data creates new bottlenecks when agents start working together.

Decoupling Collaboration from Capability

To build a reliable map assistant, developers have to separate teamwork from tool use. These are not the same aspects. One layer decides which agent should do the job. The other layer gives that agent access to the right data and tools.

A2A is the horizontal layer. It lets agents discover each other, describe their capabilities, and pass tasks across systems. An emergency response agent does not need to know how a flood analyst agent works internally. It only needs to read its Agent Card, understand what it can do, and send it a task. In GIS, that task might be: “Check whether this road segment intersects the latest flood boundary.”

MCP is the vertical layer. It gives one agent a standard way to use tools. Through MCP tools, an agent can query a spatial database, fetch a STAC item, run a routing function, or call a GIS API. The agent does not need a custom integration for every system. It asks the MCP server what tools exist, then calls the right one.

Relationship between A2A and MCP. Source: Gravitee

This split is already appearing in geospatial products. CARTO Agentic Tools let agents create layers, style maps, apply spatial filters, and control deck.gl visualizations. The Felt MCP server connects agents to databases such as Snowflake, BigQuery, Databricks, Postgres, and Redshift. Microsoft’s Planetary Computer Pro MCP tools bring natural-language geospatial workflows into VS Code.

Blueprint in Action: Building a Multi-Agent Spatial Pipeline

A practical version of flood-aware routing already exists. During the 2021 flood disaster in Germany and neighbouring countries, HeiGIT integrated Copernicus EMS flood data into openrouteservice, allowing routes to automatically avoid affected flooded areas. This is a useful real-world example because it connects satellite-derived flood information with routing decisions, which is exactly the kind of workflow disaster response teams need.

Screenshot of the openrouteservice flood-aware routing tool, showing how Copernicus EMS flood areas can be used to calculate routes that avoid affected zones. Source: HeiGIT 

Now imagine building a future agentic version of a similar workflow. Instead of one fixed application handling the entire process, the work could be split across specialized agents. A Coordinator Agent receives the emergency request and defines the area and time window. A Hydro-Analyst Agent evaluates flood extent from recent satellite or SAR imagery. A Geospatial MCP Server provides access to imagery search and water-detection tools. The resulting flood polygon is then passed to a routing service, which avoids flooded roads and generates a safer route. This is where MCP and A2A play different roles. A2A coordinates the handoff between agents, while MCP connects an agent to the tools and data it needs.

Simplified workflow for an agentic flood-aware routing pipeline

Similar ideas are also appearing in recent disaster-response research. DisasTeller uses multiple vision-language agents for post-disaster assessment, emergency alerts, resource allocation, and recovery planning. ResQConnect presents a human-centred, AI-powered multi-agent platform for flood response planning. These projects do not implement the exact MCP and A2A workflow shown here, but they point toward the same direction: disaster intelligence is becoming more modular, tool-connected, and agent-based.

The Distributed Bottlenecks: State, Tokens, and Geometry Data

Multi-agent GIS does not fail only because agents reason badly. It can also fail because they move the wrong data in the wrong way. A flood boundary, road network, or parcel layer can contain thousands of vertices. If one agent sends a full GeoJSON polygon to another agent as plain text, the system pays for every coordinate as tokens. This creates latency, cost, and context bloat before the model has even started reasoning.

The fix is to pass data by reference, not by value. Instead of sending a 50,000-vertex polygon inside an A2A message, the agent sends a small pointer: an S3 URI, a PostGIS record ID, or a STAC Item. The heavy geometry stays in the data layer. Agents only exchange the reference, then use MCP to fetch, update, or analyze the data when needed.

The efficiency gain: If a raw geometry payload costs P_tokens and the pointer costs R_tokens, then: E = ((P_tokens – R_tokens) / P_tokens) × 100%

For example, replacing a 45,000-token GeoJSON payload with a 25-token URI gives an efficiency gain of about 99.94%. The exact number will vary, but the principle stays the same: do not move heavy geospatial data through prompts.

Source: Medium

This is already how cloud-native geospatial systems work. Cloud Optimized GeoTIFFs allow clients to request only the parts of a raster they need, rather than downloading the whole file. STAC gives those assets searchable metadata and links. In an agentic GIS stack, A2A should carry the intent and the pointer. MCP should handle the actual data operation.

There is also a security benefit. Raw files can contain noise, hidden text, or untrusted metadata. Keeping large payloads in controlled storage reduces what the language model sees directly. Research systems such as Nightjar also point toward a broader pattern: agents should work with shared program state, not endless copies of the same data.

Good geospatial agents know what to carry, and a map reference is almost always enough.

The Protocol-Driven Future of GIS

The next generation of GIS infrastructure will not be defined only by bigger models or closed software suites. It will be defined by open communication layers that let agents, tools, databases, and maps work together without custom integrations for every workflow.

MCP and A2A show how this future can be structured. MCP gives each agent secure access to tools and spatial data. A2A lets agents coordinate with each other across systems. Newer extensions also point to a future where agents could purchase imagery, call paid APIs, or request commercial data under user-approved rules.

The bigger change is already visible in environmental data management. In EnviSmart, a multi-agent workflow processed 2,452 monitoring station datasets and 8,557 published files in two days, while also catching a coordinate transformation error before publication.

For GIS developers, this is the new skill set. It is no longer enough to train a model. The real challenge is learning how to choreograph agents, tools, protocols, and data references into workflows that are fast, secure, and spatially reliable.

Did you like this post? Read more and subscribe to our monthly newsletter!