- AI agents are not chatbots: they can generate, execute, and validate candidate geospatial code in bounded environments
- Results require iterative validation, human review, and a record of failure cases
- Multi-agent orchestration is one possible design pattern, not a guarantee of accuracy or autonomy
In Part 1, we argued that tool-using AI workflows differ from chat interfaces. This post records a retained architecture example, failure modes, and - most importantly - situations where automation can make a GIS workflow worse.
If you have not read Part 1, start there for context on why generic LLMs fail at GIS. This post assumes you understand the difference between a chatbot that suggests code and an agent that executes it.
What AI Agents Actually Do
The distinction matters because it determines what you can realistically expect. A chatbot mainly returns a response. An agent workflow may call tools, execute code, and return a candidate result, but its permissions, checks, and human review boundary must be explicit.
| Chatbot | AI Agent |
|---|---|
| Answers questions about GIS | Generates GIS code |
| Suggests approaches | Executes code in a sandbox |
| Requires human to implement | Validates output against expected results |
| Stateless (each message independent) | Stateful (remembers workflow context) |
| Generic (no domain knowledge) | Domain-specific (CRS, topology, spatial joins) |
The key difference: A bounded agent workflow can propose a spatial join, run candidate code, and compare geometry counts, CRS, and schema when those checks are configured. It must stop for unresolved errors or human review; no autonomous operation is established by this note.
The Architecture
This is a retained pipeline pattern, not a current deployment record. Each stage needs a defined input boundary, runtime, model choice, permission scope, output check, and human handoff before it can be used.
PIPELINE ARCHITECTURE
Analyses workflow, builds SmartDAG (dependency graph). Identifies inputs, outputs, transformations, decision points.
Generates open-source equivalent code. Uses GeoPandas, rasterio, Shapely, pyproj.
Runs generated code in isolated environment. Captures output data, execution time, memory usage, errors.
Compares source vs generated output. Checks geometry count, CRS, attribute schema, spatial accuracy.
Three architectural decisions drive the reliability of this pipeline.
Specialised models per agent
Each agent uses a model optimised for its role. The Builder uses a code-generation model, the Auditor uses a different model for spatial validation. Different models catch errors that a single model systematically misses.
Sandbox execution
Code runs in an isolated sandbox, not on the user's machine. The environment, dependency set, input boundary, and output checks must be defined for the current runtime.
Stateful orchestration
Stateful orchestration can route failed checks back for revision. The workflow must define the checks, retry boundary, audit record, and human escalation rather than relying on prompt chaining alone.
Multi-Agent Orchestration
Multiple specialised stages are one possible design pattern. They can separate planning, code generation, checking, reconciliation, and documentation, but the benefit must be measured on the target workflow. This note does not present a current Axis Spatial pipeline or a general performance result.
| Metric | Single Agent | Multi-Agent |
|---|---|---|
| First-attempt accuracy | Workflow-specific | Workflow-specific |
| Accuracy after refinement | Requires measured baseline | Requires measured result |
| CRS errors caught | Depends on checks | Depends on checks |
| Missing edge cases caught | Depends on scope | Depends on scope |
| Average iterations to pass | Retained illustration | Retained illustration |
A separate review stage can reduce some blind spots, but it can also introduce more orchestration, cost, and failure points. Compare the target workflow with a simpler human-reviewed implementation before adding specialised stages.
Why it can help: A review stage can report a concrete mismatch, such as a changed geometry count, CRS, or NULL-handling rule. Record the input, expected result, failure, and reviewer decision; do not treat an illustrative message as evidence of a current run.
Sandbox Execution
Generating code is the easy part. The hard part is knowing whether it produces correct output. That requires actually running it.
Isolated sandbox - a bounded Python environment with the required geospatial dependencies and explicit input/output controls.
Explicit isolation - A sandbox should define access to data, network, and filesystem. Confirm the actual policy and reset behaviour for the selected runtime.
Real validation - Do not ask only whether the code looks right. Compare geometry counts, CRS, schema, spatial behaviour, and domain outputs against a named source and reviewer-approved expectation.
A configured auditor could validate the following after a sandbox run:
Use explicit pass, fail, or review states. A wrong CRS can materially shift features, so the tolerance and escalation rule must be defined for the target workflow rather than assumed.
Failure Modes
Some workflows do not pass on the first attempt. The failure modes below are retained research observations, not a current failure-rate benchmark.
CRS CONFUSION
The agent generates code assuming EPSG:4326 when the source data is in a projected CRS. The Auditor catches this by comparing output extents, but it adds an iteration.
TOPOLOGY COLLAPSE
Dissolve operations that produce invalid geometries - self-intersections, holes. The fix is always buffer(0) or make_valid(), but the agent does not always add this preventatively.
ATTRIBUTE LOSS IN JOINS
Spatial joins that drop attributes because of column name collisions. The agent does not always handle lsuffix/rsuffix correctly.
MEMORY OVERFLOW ON LARGE DATASETS
Generated code that loads entire datasets into memory. The fix is chunked processing, but this requires understanding the data size - which the agent does not always have upfront.
DATE/TIME HANDLING EDGE CASES
Time-zone aware vs naive datetimes, date format mismatches between source systems. A persistent headache in any data pipeline.
GENUINE FAILURES
Some workflows are too complex, too poorly documented, or too dependent on proprietary ESRI logic for AI agents to migrate. These require human expertise.
THE FULL PICTURE
Some workflows will remain poor candidates for automation because of proprietary spatial algorithms, undocumented business logic, data-quality limits, safety requirements, or missing validation evidence. Those cases need human expertise and a different delivery path.
When AI Agents Make Things Worse
This is the section most AI vendors skip entirely. There are real scenarios where AI agents are the wrong tool. Using them anyway wastes time and money.
Simple, one-off tasks
If you need to run a buffer operation once, a direct GIS tool is usually simpler. The setup, permissions, checks, and maintenance for an agent workflow can outweigh the value of a one-off task.
Highly regulated workflows with audit trails
In some industries - nuclear, defence - every line of code needs human sign-off. AI-generated code adds a review burden that may exceed the time saved. The audit trail complexity alone can negate the efficiency gains.
Workflows with undocumented tribal knowledge
If the analyst's workflow depends on "I just know this step needs to happen before that step because of how the data comes in on Tuesdays," the AI agent will miss this. Tacit knowledge needs human capture first.
When the goal is understanding, not output
Junior analysts learning GIS should write their own code. Using AI agents to skip learning creates dangerous knowledge gaps. The person who does not understand the analysis cannot validate it.
Safety-critical real-time operations
Emergency response, real-time asset tracking, safety-critical infrastructure monitoring. AI agents should augment, never replace, human decision-making when lives or critical assets are at stake.
When your data quality is poor
AI agents amplify data quality issues. Garbage in, confidently generated garbage out. If your source data has inconsistent schemas, missing CRS definitions, or corrupt geometries, fix the data first. Automating a broken input just produces broken output faster.
What This Means for GIS Teams
AI agents do not replace GIS analysts. They replace the repetitive parts of their work. The distinction is critical because it determines how you plan adoption.
THE ANALYST ROLE SHIFTS
From "do the analysis" to "design the analysis and validate the output." The skill set evolves from tool operation to workflow architecture. Analysts become reviewers and designers, not button-clickers.
THE CAPACITY MULTIPLIER
Teams may increase capacity when they select bounded, repeatable workflows and invest in validation. The outcome depends on the workflow, runtime, staffing, and review model; this article does not provide a capacity multiplier.
The transition is not instant. Identify candidate workflows, validate an initial batch, and plan ongoing refinement. Teams that skip the review phase increase the risk of automating work that should have stayed manual.
For the business case behind automating GIS workflows, including the cost models and ROI timelines, read our workflow automation guide. For the open-source libraries our agents use for code generation, see the ArcPy to GeoPandas migration guide.
AI agents for GIS can be useful and imperfect. The important boundary is not a single accuracy number; it is whether each output has current evidence, validation, and human review appropriate to the workflow.
The architecture works because it treats AI-generated code with healthy scepticism. A proposed output should be executed in a bounded environment, checked against the source, and either accepted by a reviewer or flagged for further work. No blind trust. No hand-waving about accuracy.
Automation is best considered for repetitive, well-defined work. Complex or poorly documented work still needs experienced analysts. The question is whether the proposed boundary is supported by evidence.
Frequently Asked Questions
How accurate are AI agents at automating GIS workflows?
There is no general accuracy rate for AI-assisted GIS work. Use bounded execution, source comparison, geometry and schema checks, failure capture, and human review. The retained orchestration pattern is a research example, not a current performance guarantee.
When should you NOT use AI agents for GIS automation?
AI agents are a poor fit for simple one-off tasks where a direct GIS tool is simpler, highly regulated workflows requiring line-by-line audit trails, workflows dependent on undocumented tribal knowledge, learning scenarios where junior analysts need to build skills, safety-critical real-time operations, and situations where underlying data quality is poor. Fix data quality issues before attempting automation.
Get Workflow Automation Insights
Monthly tips on automating GIS workflows, open-source tools, and lessons from enterprise deployments. No spam.