GeoAgent: One Agent Layer for leafmap, QGIS, STAC and NASA Earthdata

The duplication problem GeoAgent is built to remove

Every geospatial Python library that wants an agent ends up writing the same code. Bind an agent to a live map or a QGIS session. Turn package functions into tools with docstrings the model can read. Wire up OpenAI, Anthropic, Gemini, Bedrock, OpenRouter, LiteLLM, vLLM or a local Ollama server. Add a pause before anything destructive. The README states the goal plainly: GeoAgent is a shared agent layer so that projects such as leafmap, anymap, geoai, geemap, STAC and NASA Earthdata no longer each need to build and maintain their own agent stack. The intended audience is therefore library and plugin maintainers, not analysts looking for a chat box over a shapefile. If you are the person who would otherwise be writing an agent loop inside your own package, this is aimed at you.

Strands underneath, geospatial metadata on top

GeoAgent does not implement its own agent runtime. It is built on Strands Agents, and the README describes the high-level class as a facade around a Strands Agent. The geospatial part is the metadata and the bindings. A Python function becomes a tool through the @geo_tool decorator, and the GeoToolRegistry holds tool metadata, safety flags, categories and a fast-mode filter. A GeoAgentContext carries runtime objects such as a map or a QGIS iface, so the same tool can act on whatever session is currently open. Package-specific factories (for_leafmap, for_anymap, for_qgis, for_nasa_opera, for_stac) pre-bind the tools for a known object, and create_agent is the escape hatch for custom tools. The confirmation hook is the part worth reading closely: the README says the agent pauses before destructive, expensive or otherwise irreversible operations, naming layer deletion, file saving and heavy processing jobs as examples. Which calls actually trip that hook is a detail you should confirm in the source rather than assume.

Installation is core plus extras, and the extras are the real decision

The base install is deliberately thin:

pip install GeoAgent

The README states that core installs only the agent framework dependencies, mainly strands-agents and pydantic, with geospatial packages and provider clients kept as optional extras. In practice you almost always install at least two:

pip install "GeoAgent[leafmap,openai]"

Provider extras cover openai, anthropic, gemini, ollama, litellm, openrouter and openai-compatible servers such as llama.cpp, LM Studio and vLLM. Integration extras cover leafmap, anymap, stac, earthdata, nasa-opera, geoai, earthengine, ui and browser. There is a providers convenience extra and an all extra, but the README flags one exception: vllm is not included in providers or all and has to be requested explicitly, because it goes through a Strands community provider. QGIS is also outside the extras entirely; the README notes that QGIS itself remains system-installed. That split is sensible, but it means a broken environment usually traces back to a version conflict between an extra and a system QGIS rather than to GeoAgent itself.

Where the design constrains you

The optional-extras split is a genuine cost, not just tidiness. Provider clients and geospatial stacks are separate installs, so a working GeoAgent setup is a combination of pinned versions across strands-agents, pydantic and whichever geospatial libraries you bound. Upgrading one extra can move the others. The QGIS path is the sharpest example: the README says QGIS stays system-installed, so GeoAgent cannot control that version and you are testing against whatever the user already has. Multimodal input is conditional in the same way. The README describes pasted images and screenshots as supported when the selected model provider supports vision, which means a workflow built around screenshots silently degrades to text-only if someone switches to a model without vision. Nothing in the supplied material describes a fallback path for that case, so treat it as a configuration constraint rather than a handled failure.

GeoAgent against a general-purpose agent framework

The obvious alternative is Strands Agents directly, or another general agent framework, and the difference is not capability but packaging. A general framework gives you the agent loop, tool calling and provider adapters, and leaves you to define what a tool means in your domain. GeoAgent keeps the same runtime and adds the geospatial conventions: the @geo_tool decorator with structured metadata, the registry with safety flags and categories, the context object that binds a live map or QGIS iface to the agent, and factories that pre-wire known object types. If you use Strands directly you would rebuild those conventions yourself, and you would also rebuild the confirmation logic. If you only need an agent that calls a couple of functions on a pandas DataFrame, GeoAgent's geospatial layer is dead weight and a plain Strands setup is smaller. The trade is conventions for flexibility: GeoAgent makes the common geospatial case short and the unusual case slightly longer, because you route through create_agent instead of binding a factory.

Maintenance, release cadence and the MIT licence

The repository ships frequently. The supplied release list shows v1.9.0 in August 2026, v1.8.2 in June 2026 and v1.8.1 in May 2026, with the last push to main in September 2026. A cadence that tight is good for fixes and bad for anyone who pins loosely: minor releases can land within weeks of each other, so an unpinned extras list will drift. Budget for pinning your extras and re-testing after each GeoAgent bump, particularly across the QGIS boundary where you do not control one side of the stack. The licence is MIT, which is permissive and compatible with commercial and closed-source use, but MIT covers GeoAgent's own code only. The optional extras pull in geospatial packages and provider clients under their own licences, and those are what you actually need to check if you are shipping a product. That is a fact about the dependency tree, not legal advice; get your own review if the terms matter.

Who should take the dependency and who should not

Take it if you maintain a geospatial Python library or a QGIS plugin and you want tool exposure, provider switching and confirmation prompts without owning that code. The factory set is the tell: if your object is a leafmap.Map, an anymap.Map, a qgis.utils.iface session, a STAC catalog or NASA OPERA search, GeoAgent already has a binding and you are mostly writing @geo_tool functions. Skip it if you are an analyst who wants to ask questions of a dataset in a notebook; GeoAgent is plumbing, and the README's own framing is that it exists so other packages do not maintain an agent framework. Skip it too if your stack is a single library with a handful of functions and no live map or QGIS session, because the context and registry machinery buys you little there. Before installing, check two things against the current source: that your provider appears in the extras you can actually install (vllm is the documented exception), and which operations the confirmation hook intercepts, since the README names examples rather than an exhaustive list.

Editorial conclusion

Adopt GeoAgent if you maintain a geospatial Python library or a QGIS plugin and want tool exposure, provider switching and confirmation prompts without writing that layer yourself; the built-in factories for leafmap, anymap, QGIS, STAC and NASA OPERA only pay off when your objects match those targets. Do not adopt it as a desktop analysis tool or as a replacement for QGIS processing algorithms. Before committing, verify that the model provider you intend to use is covered by the extras you can install, and read the source of the confirmation hook to confirm which operations it actually intercepts.

Official sources

1. License: MIT
2. opengeos/GeoAgent on GitHub
3. Project website
4. README
5. Releases