Geospatial AI in ArcGIS operates within a larger AI ecosystem that includes LLMs, AI models, external agentic platforms, and the architectural constraints under which organizations deploy them.
This chapter covers how ArcGIS integrates with that ecosystem in exposing geospatial capabilities to external AI systems through open standards, supporting interoperability of AI tools and models, integrating with the LLMs that power assistants and agents, and operating across the deployment topologies organizations require.
MCP (Model Context Protocol) is an open interoperability standard for Agentic AI that defines how AI models and agents connect to external data sources and tools. By natively supporting MCP as a server, ArcGIS makes its geospatial capabilities available to any MCP-compliant AI client without that client needing native geospatial expertise.
For example, an agent running on any MCP-compliant platform can call ArcGIS to geocode an address, calculate a route, query feature layers, run a geoprocessing tool, search for content, export a map, geoenrich a location, retrieve elevation data, or find nearby places. The agent does not need to know how GIS works internally, it calls a “tool” in the ArcGIS MCP server and gets a result.
MCP support is rolling out across the ArcGIS foundational products:
ArcGIS Online - Esri’s Software-as-a-Service (SaaS) deployment option
ArcGIS Enterprise - Esri’s server software, self-hosted deployment option. Runs on the cloud or on-premises, and supports Windows, Linux, and Kubernetes
ArcGIS Location Platform - Esri’s Platform-as-a-Service (PaaS) deployment option
Each of these exposes a different set of capabilities initially, with the set of available tools, resources, and prompts expanding over time. Organizations should evaluate which deployment target aligns with their architecture and monitor release notes for capability additions.
Additional MCP support is also planned for adjacent use cases. This includes MCP for ArcGIS Monitor to support system observability and operations, as well as MCP for ArcGIS developers to support application development through coding agents.
For organizations that need additional or domain-specific agentic integration, Esri Professional Services and partners can deliver integration through extensions of the MCP services in the foundational products, or through direct integration with ArcGIS REST APIs and custom solutions.
AI assistants and agentic features in ArcGIS depend on large language models (LLMs) for reasoning. Today, those LLMs are accessed through a gateway in ArcGIS Online rather than called directly by applications.
The gateway pattern means that AI clients (assistants, agents, applications) call an intermediary service that handles routing to LLM providers, authentication, rate limiting, policy enforcement, observability, and cost attribution. Organizations do not configure or operate this layer directly, instead Esri manages it. The benefits include operational simplicity and consistent behavior across all AI features. The tradeoffs include requiring connectivity to ArcGIS Online.
Self-hosted LLM support is on the roadmap for ArcGIS Enterprise. When available, this will allow organizations to operate their own LLMs for AI workloads. This may be motivated by data residency, sovereignty, latency, cost, or other considerations. The scope of self-hosted LLM support is still being defined; however, it is expected to cover a defined set of models and capabilities, not arbitrary LLM use. Architects with self-hosted requirements should plan to evaluate the BYO model when its scope is published, and account for the operational burden of hosting, securing, and maintaining LLM infrastructure.
For self-hosted LLM support, Esri is planning to support a small, defined list of LLMs. Additionally, certain ArcGIS AI Assistants may only support the LLM gateway pattern.
The cross-cutting concerns that LLM gateways address, including cost attribution, policy enforcement, and observability, apply regardless of whether the gateway is Esri-managed or self-hosted. Learn more in the architecture pillars chapter.
Organizations may require that their AI tools and models work across environments, including models from ArcGIS used outside of ArcGIS, and models from outside of ArcGIS used in ArcGIS.
Models from ArcGIS. Pretrained models in Living Atlas are published as Deep Learning Packages (DLPKs). Each includes documented inputs, outputs, architecture, training data, and limitations. DLPKs are designed for ArcGIS but are built on standard frameworks (PyTorch), supporting use in other AI environments where appropriate. Models trained using the arcgis.learn module produce standard PyTorch artifacts. Models can be used for inference by calling ArcGIS tools such as an ArcGIS Notebook or a Raster Analytics workflow, which can work from DLPKs, scale with virtual GPU capacity, and publish results back to the organization’s ArcGIS Enterprise or ArcGIS Online system.
Models into ArcGIS. Deep Learning Studio provides a visual interface for bringing externally-trained models into ArcGIS. Organizations that train models in other environments (e.g., cloud ML platforms, research frameworks) can bring them into ArcGIS for inference on geospatial data, provided the model architecture is compatible.
Location embeddings and foundation models are positioned as building blocks that can feed workflows both inside and outside ArcGIS. Location embeddings are standard vectors usable in any ML pipeline. Geospatial foundation models will be adaptable to downstream tasks in multiple environments. Specific interoperability patterns are still emerging given the early maturity of these capabilities.
Many organizations operate in environments where AI workloads must function without persistent cloud connectivity. Geospatial AI operates in these environments as follows:
AI tools and models work across all deployment patterns. Pretrained models, organization-trained models, geoprocessing tools with embedded AI, and the arcgis.learn module all operate in cloud, hybrid, on-premises, and disconnected environments. They do not depend on LLMs and the LLM gateway. For organizations in constrained environments, AI tools and models are the geospatial AI capability most readily available today.
AI assistants and agentic features require connectivity today. These capabilities depend on LLMs accessed through the ArcGIS Online gateway; therefore AI assistants and Esri-hosted agentic capabilities are not currently available in fully disconnected, air-gapped, or sovereign deployments. Organizations needing agentic or assistant capabilities in these environments today can work with Esri Professional Services and partners on custom solutions.
Self-hosted LLM support is the path forward. The BYO LLM direction for ArcGIS Enterprise is the primary architectural path to supporting AI assistants and agentic features in environments that cannot connect to ArcGIS Online. Once available, customers will be able to deploy these capabilities within their own infrastructure boundaries. Timing and scope are still being defined.
Architects designing for constrained environments should build their near-term AI strategy around the capabilities that are available today (AI tools and models), plan for the capabilities that are coming (self-hosted LLM for assistants and agents), and engage Esri Professional Services for custom integration where the gap between current availability and organizational need is urgent.