Ask ChatGPT to bring you up to speed on recent developments in an industry. To answer your question, it might search the web, retrieve relevant documents, consult previous conversations, and synthesize what it finds into a response. From the user’s perspective, the interaction is straightforward. You ask a question, and the application answers. There’s quite a bit happening behind that exchange, however, that is worth understanding because it governs most of the experience we have with AI applications.
First, consider the model. A large language model receives instructions and context, processes that input, and generates an output. That output might be a response to the user, or it might be a request to perform an action, such as searching the web or executing code. The model doesn’t independently maintain a persistent conversation, operate a search engine, run code, or interact with a database. Those capabilities come from the application surrounding it.
In the web search example, the application determines which tools are available to the model. When the model requests a search, another component executes it, retrieves the results, and returns them to the model for further processing. The model can then incorporate that information into the generation of its response. OpenAI’s function-calling documentation describes this interaction cycle in some detail.
Context management works in a similar way. Each model invocation receives a collection of instructions, conversation history, and potentially other information, which is all referred to as context. This is subject to the model’s context limits, which is the amount of information the model can process at once. The application determines what to include, whether to retrieve material from earlier interactions, and how to handle a conversation that has grown beyond those limits.
What feels like one continuous exchange may involve numerous separate model invocations, each receiving a constructed view of the conversation. The model itself is stateless between invocations, so this interaction looks very much like a web application, in which the application manages state for the web server. I liken it to first-generation ASP.NET Web Forms apps that sent huge ViewState chunks on every round trip.
The application also manages permissions, handles errors, and presents the results. Some of this is conventional application engineering. Other aspects, particularly context management and the coordination of model-generated actions, introduce problems specific to AI, but not unprecedented. Context management, for example, can begin to look a lot like memory management in something like a C program.
The software responsible for much of this orchestration is often described as the harness, particularly in terms of AI agents. The terminology varies across implementations, and the harness is generally part of a larger application. For the purposes of this post, though, it’s a reasonable name for the software that wraps the model and manages its interactions with its operating environment. Conversational AI has worked this way for some time, but as applications perform more substantial tasks, the responsibilities of the harness become more involved.
There are different ways to organize that process. In a predefined workflow, software controls the sequence of operations and invokes a model where needed. An agent generally gives the model greater discretion over which actions to take and when. Anthropic explored this distinction in its December 2024 discussion of building effective agents, describing approaches that range from relatively simple workflows to more autonomous systems. The harness governs the environment in which either approach operates.
Harness design isn’t static. Models and the practices surrounding their use are evolving rapidly. In its March 2026 discussion of harness design for long-running applications, Anthropic described how improvements in model capabilities allowed researchers to eliminate orchestration mechanisms that had previously been necessary. As models improve, we can reconsider which responsibilities require explicit software controls and which can be handled reliably by the model.
Suppose we ask an AI application to identify parcels within a specified distance of a proposed transmission corridor, exclude those intersecting designated flood hazard areas, and rank the remaining candidates according to land-use and infrastructure constraints. A capable language model could probably describe a reasonable approach. It might identify the datasets, explain the required spatial operations, and produce SQL or Python code to carry them out, but actually performing the analysis requires considerably more.
The application needs parcel boundaries, the proposed corridor, flood hazard data, and land-use information. It needs to establish whether those sources are appropriate for the task and whether their geographic and temporal characteristics are compatible. The distance calculations must use suitable units and coordinate reference systems. The exclusions need to be applied consistently, and the ranking criteria have to reflect the analytical objective.
These are bread-and-butter GIS requirements. They’re the kinds of details that can consume much of an analyst’s time, even when the underlying spatial operations are relatively simple. Software and professional practices for handling such requirements have been developed over several decades. A geospatially capable harness can provide a way to connect those resources to a model.
The model could interpret the objective and propose an analytical sequence. The harness could provide access to the required datasets, invoke spatial operations, maintain intermediate results, and apply defined checks. Established tools such as PostGIS and GDAL would perform the computations. For example, PostGIS provides ST_DWithin to evaluate whether geometries are within a specified distance. The operation is mathematically defined, but using it correctly still requires attention to coordinate systems, measurement units, and the nature of the input geometries.
Distance calculation is a good example of why geographic expertise remains necessary. A query can execute without error while producing results that make little geographic sense. Using the wrong coordinate reference system, misunderstanding the units, or applying a planar calculation where a different approach is needed can undermine the analysis without producing an obvious software failure. I’ve often had a query run without error and return an empty data set only to discover I had forgotten to transform the input data to a common coordinate system.
The same applies to data selection. Two datasets might represent the same geographic phenomenon while differing substantially in resolution, currency, attribution, or intended use. A flood hazard boundary and an elevation model may both contribute to an exposure assessment, but they aren’t interchangeable representations of flood risk.
A harness designed for geographic analysis would incorporate rules for selecting datasets, validating geometry, checking coordinate systems, preserving provenance, and recording analytical parameters. It would execute some of these checks automatically and identify others that require review from the user.
Those capabilities need to be designed and implemented. Connecting a model to spatial tools doesn’t automatically produce geographically sound analysis. The analytical methodology, data requirements, and validation procedures still have to come from somewhere, and this begins to look like regular application development. All software, regardless of what it does, is an encapsulation of human expertise and a harness that governs proper performance of spatial analysis by an AI model is no different.
There’s some recent research that helps establish how much the surrounding system can contribute. In October 2026, Google Research published an evaluation of its Geospatial Reasoning Agent. The researchers compared standalone language models with configurations that added general-purpose tools, specialized Earth AI capabilities, and planning.
Access to specialized geospatial tools substantially improved performance across several evaluated benchmarks. Adding planning provided further improvements on more complex, open-ended tasks. The researchers also acknowledged limitations, particularly the difficulty of evaluating analyses for which several approaches might be defensible. It’s one experiment, and I wouldn’t extrapolate too much from its benchmark results, but the comparison is interesting because the researchers examined how different combinations of tools and orchestration affected performance.
Recent developments in geospatial AI have focused on specialized models, including Earth observation foundation models, spatial embeddings, and models trained to recognize geographic relationships. These extend the kinds of information AI systems can interpret and the problems they can address.
The same general principles apply to spatial foundation models. Their outputs still need to be integrated with data, analytical methods, and downstream processing to become part of an operational workflow. A harness can coordinate those elements, whether the underlying model processes language, imagery, spatial embeddings, or some combination.
The geospatial industry has spent decades making geographic data and computation accessible through interoperable software. PostGIS, GDAL, PROJ, QGIS, and other projects provide mature implementations of spatial operations. Standards such as OGC API – Features and STAC support the discovery and access of geographic information. Cloud-native formats have made it possible to work with large datasets through increasingly flexible computational environments.
Most of that infrastructure was built to solve problems involving data exchange, interoperability, processing, and access. Yet those same characteristics make it well suited to integration with AI systems. Model Context Protocol and similar mechanisms provide ways to expose software capabilities to AI applications. They offer another route through which existing geographic resources can be invoked, building on the interfaces and computational methods already available, with agent harnesses becoming another path for the diffusion of geospatial technology into other industries.
The interesting question is what happens when harnesses begin to incorporate geographic methodology rather than merely expose tools. Much of GIS practice involves judgments about source suitability, analytical assumptions, exceptions, and whether results warrant further review. Some of that expertise can be represented through explicit rules and repeatable procedures. Some of it can also be represented in skills that can guide how a model applies reasoning to analytical tasks. Other aspects will continue to require professional judgment.
I think this is where the next phase of geospatial AI development gets interesting. We’ve made geographic data and computation accessible to software. Agent harnesses offer a bridge to make the methods and expertise behind that software accessible to a much broader range of applications.
Header image: John Holmes, CC BY-SA 2.0, via Wikimedia Commons
