ANASSA: From High-Level Framework to Low-Level Architecture for Spatial Agentic AI

Constantinos Papantoniou; Brian Hilton

cs.AIOct 9, 2026

ANASSA: From High-Level Framework to Low-Level Architecture for Spatial Agentic AI

Authors: Constantinos Papantoniou, Brian Hilton

Organizations: Anassa.ai USA · Research Scientist USA

Abstract

Agentic AI systems operating over geospatial data require more than autonomous reasoning and tool use; they must also support explicit orchestration, spatial validation, governance, provenance, failure handling, and human decision authority. Prior work introduced ANASSA, an agentic AI orchestration framework for spatial intelligence that established high-level components and responsibility boundaries for governed agentic execution (arXiv:2609.14824). However, the framework did not specify how those high-level responsibilities should be systematically decomposed into an implementation-facing low-level architecture. This paper addresses that gap by applying Design Science Research (DSR) to refine the ANASSA framework from high-level architectural (HLA) responsibilities into a low-level architecture (LLA). The resulting design preserves the responsibility boundaries of the foundational framework while translating them into executable architectural structures, including 47 logical roles, versioned task graphs, capability-based agent selection, typed contracts, explicit runtime states, spatial validation mechanisms, governance controls, failure and recovery paths, and provenance records. The architecture is demonstrated through an end-to-end execution trace and analytically evaluated for requirements traceability, internal consistency, responsibility preservation, and technology independence. The resulting high-level-to-low-level design provides an implementation-facing bridge between the ANASSA framework and future system implementations, defining how governed spatial agentic workflows can be made inspectable, reconstructable, and testable without binding the architecture to a specific AI model, geospatial platform, communication protocol, or deployment environment.

Figures & tables

System	Workflow representation	Multi-agent coordination	Runtime feedback / recovery	Spatial contract / evidence semantics	Governance / provenance as architecture
Spatial-Agent ( Bao et al., 2026 )	Scientific-concept GeoFlow DAG	Agent-centric; not multi-agent focus	Executable workflow generation	Spatial concepts and ordering constraints	Not a reported architectural focus
GeoFlow ( Bhattaram et al., 2025 )	Agentic workflow with tool-calling objectives	Not a reported multi-agent focus	Runtime tool invocation	Tool objectives; no ANASSA-style cross-component contract	Not a reported architectural focus
GeoAgentic-RAG ( Liang et al., 2026 )	Multi-stage retrieval-analysis workflow	Specialized agents plus supervisor	Reflection/planning inside execution workflow	Unified geospatial database and retrieval context	Not a reported architectural focus
GeoAgentBench ( Yu et al., 2026 )	Plan-and-React execution structure	Benchmark/agent architecture	Dynamic feedback and error recovery	Execution parameters and output verification	Benchmark focus rather than governance architecture
ANASSA HLA ( Papantoniou and Hilton, 2026 )	Component task-graph requirement	C1–C11/C5 roles	Typed failure requirement	Authoritative evidence, uncertainty, provenance	Explicit C7 governance and human authority
ANASSA LLA (this paper)	Versioned task DAG per revision	47 logical roles + C4 orchestration	Typed states, retry, replan, escalation	Typed spatial contracts + evidence states	Runtime policy, audit, provenance, authority

Table 1. Positioning of the ANASSA LLA relative to representative geospatial-agent work.

DSR activity	ANASSA design activity	Artifact / evidence in this paper
Problem identification and motivation	Identify the gap between capable geospatial agents and an implementation-ready governed architecture	Problem statement, foundational ANASSA framework, related-work comparison
Objectives for a solution	Define what the architecture must enable and constrain	Design objectives, functional requirements, non-functional requirements, inherited DR1–DR8
Design and development	Translate requirements into principles, HLA responsibility boundaries, and LLA execution mechanisms	DP1–DP8, Figure 6 , Figure 8.3 , task graphs, contracts, runtime states, validation and recovery
Demonstration	Walk a representative geospatial objective through the designed artifact	Synthetic end-to-end trace with a CRS mismatch, graph revision, policy decision, spatial validation, and provenance closure
Evaluation	Assess whether the design is complete and internally coherent at the architecture level	Requirements traceability, flow consistency, failure-path closure, policy/evidence separation, technology-independence analysis
Communication	Present the artifact and its derivation so it can be implemented and empirically tested	HLA/LLA diagrams, design tables, logical interaction patterns, evaluation variables, implementation-readiness criteria

Table 2. Application of Design Science Research Methodology to the ANASSA architecture design.

ID	Functional requirement	ID	Non-functional requirement
FR1	Translate participant objectives into machine-actionable, policy-aware geospatial intent.	NFR1	Traceability: reconstruct data, task, model/tool, policy, validation, and human-decision paths.
FR2	Perform geospatial reasoning and select appropriate analytical capabilities and workflows.	NFR2	Reproducibility: retain versions, parameters, graph revisions, and evidence identifiers for repeated execution.
FR3	Orchestrate tool and service execution across heterogeneous platforms and deployment environments.	NFR3	Interoperability: exchange typed information across replaceable geospatial tools and services.
FR4	Validate spatial claims and artifacts against governed authoritative evidence and explicit quality conditions.	NFR4	Deployment independence: avoid binding logical orchestration to one model, platform, cloud, or protocol.
FR5	Apply governance, authorization, risk, privacy, sovereignty, and human-authority controls at runtime.	NFR5	Extensibility: add sectors, capabilities, agents, tools, or evidence sources without redesigning the full architecture.
FR6	Detect execution and validation failures and select bounded retry, replanning, escalation, or termination.	NFR6	Scalability: separate orchestration semantics from workload size, data volume, workflow depth, and distributed compute.

Table 3. Functional and non-functional requirements for the ANASSA design solution.

ID	Design principle	Architectural implication
DP1	Geospatial context is a first-class system property	Tasks, contracts, evidence, and outputs preserve coordinate reference, geometry, scale/resolution, temporal context, jurisdiction, quality, and uncertainty rather than treating them as hidden prompt context.
DP2	Separate intent from execution	Participant intent is normalized and decomposed before tools are invoked; intent, planning, capability selection, and execution remain distinguishable and auditable.
DP3	Orchestrate capabilities, not vendors	C4 resolves logical capabilities to replaceable implementations so the architecture is independent of a particular model provider, geospatial platform, cloud, or protocol.
DP4	Use explicit contracts at every architectural boundary	Inter-component exchanges declare source, destination, payload, spatial/temporal context, provenance, constraints, policy, validation, expected result, and failure semantics.
DP5	Validation is part of execution	Spatial reference, topology, positional accuracy, resolution, temporal validity, authority, uncertainty, and evidence applicability are evaluated as part of the runtime path rather than only after generation.
DP6	Autonomy is policy- and risk-adaptive	Human authority is invoked according to risk, policy, consequence, uncertainty, and evidence state; low-risk operations may proceed within approved boundaries.

Table 4. ANASSA design principles used to guide HLA-to-LLA refinement.

Req.	Requirement	DP	HLA owner	LLA mechanism	Observable evidence
DR1	Spatial grounding	DP1, DP5	C6, C8, C5-S4	Spatial/temporal contract fields; preparation and validation checks	CRS/datum, geometry, resolution, time, transformation chain, validation record
DR2	Execution-aware orchestration	DP2, DP3, DP7	C4, C5	Versioned task graph, capability registry, preconditions, typed runtime state	Graph revision, capability decision, tool/parameter record, failure stage
DR3	Authoritative validation	DP4, DP5	C8, C5-S4, C7	Claim/artifact validation against governed evidence	Evidence bundle, source/version/authority, tolerance, verdict
DR4	Uncertainty representation	DP1, DP5	C6, C8, C5-S4	Non-binary evidence states and uncertainty fields	Validated-with-uncertainty, conflict, insufficient-evidence state
DR5	Human decision authority	DP6	C7, C5-S3/S4	Policy evaluation and risk-adaptive human control	Permit/deny/conditions or explicit human-authorization record
DR6	Traceability and provenance	DP4, DP8	C10, C11	Cycle-level provenance linked to contracts, evidence, and graph revisions	Reconstructable data/model/tool/policy/human decision path

Table 5. Traceability from inherited ANASSA requirements through design principles to HLA/LLA mechanisms.

Tier	Name	Count	Primary responsibility
A0	ANASSA Spatial Agentic AI Orchestrator	1	Global workflow and connection coordination
A1	Cognitive Loop Agents	6	Sense, reason, plan, decide/validate, execute, and learn
A2	Domain Specialist Agents	27	Task-specific operational and geospatial capabilities
A3	Governance Agents	8	Policy, audit, validation, oversight, and monitoring
A4	Foundation Agents	5	Data, knowledge, trust, infrastructure, and security
	Total	47

Table 6. Five-tier ANASSA logical role hierarchy.

Tier	Owner	Count	Logical roles
A0	C4-L0	1	ANASSA Spatial Agentic AI Orchestrator
A1	C5	6	Geospatial Sensing; Reasoning; Planning; Decision/Spatial Validation; Execution; Learning
A2	C1	5	Participant Engagement; Collaborative Workflow; UX and Access; Community Mapping; Multi-Stakeholder Coordination
A2	C2	5	Industry Requirements; Regulatory and Compliance; Industry Workflow Automation; Domain Knowledge and Insight; Sector Reporting and Communications
A2	C3	4	Solution Recommendation; Deployment Monitoring and Optimization; Scalability and Performance; Legacy Migration and Modernization
A2	C4-L2	5	Spatial Analysis; Cartography; Remote Sensing; Workflow Orchestration; System Connectivity

Table 7. Inventory of 47 logical roles mapped to HLA responsibility owners. The count is not a requirement for 47 runtime processes.

Waiting	WAITING_FOR_DATA; WAITING_FOR_POLICY; WAITING_FOR_HUMAN
Recovery / terminal	RETRYABLE_FAILURE; REPLANNING; REJECTED; ESCALATED; TERMINATED

Table 8. Additional ANASSA task runtime states.

Group	Representative fields	Purpose
Identity	contract ID, version, cycle ID, task ID	Binds the exchange to a workflow and schema version
Source / destination	component, agent/role, capability	Makes responsibility and routing explicit
Spatial context	CRS/datum, units, axis order, geometry type, extent, resolution/scale	Prevents spatial semantics from being implicit
Temporal context	observation time, effective interval, freshness/staleness rule	Prevents stale or temporally incompatible reasoning
Payload	data type, schema, artifact pointer, semantic type	Defines what is exchanged and how it is interpreted
Provenance	source IDs/versions, authority, lineage, transformation history	Supports evidence tracing and reproducibility

Table 9. Canonical ANASSA inter-component contract fields.

Field	Example value
contract / task	K-04 / T-03b
source $\rightarrow$ destination	C6 Data Transformation $\rightarrow$ C5-S1
semantic payload	Flood-warning polygon bundle
spatial context	EPSG:4326, polygon, extent + source resolution
temporal context	observation/effective time + freshness rule
provenance	source IDs, versions, transformation from original CRS

Table 10. Illustrative contract instance used in the worked trace.

No.	From	To	Nature of connection
1	C1	C4	Participant intent enters through the Multi-Model Language Gateway
2	C1	C5-S3	Participant needs and preferences inform Planning Agent context
3	C1	C7	Participant data is subject to privacy, authorization, and access-control policy
4	C2	C4	Industry requirements inform agent configuration and capability selection
5	C2	C5-S3	Industry context and regulations constrain planning
6	C2	C7	Sector compliance rules are enforced through governance

Table 11. ANASSA principal connection matrix.

Time	Task	Owner	State	Contract / evidence	Observed event and architectural response
$\tau_{0}$	T-01	C1/C4	RECEIVED	K-01 intent	Objective, role, output type, and policy context normalized; graph $G_{0}$ created.
$\tau_{1}$	T-02	C6/C8	COMPLETED	K-02 data read	Facility points and flood-warning polygon resolved with versions, timestamps, and authority metadata.
$\tau_{2}$	T-03	C6	PRECONDITION CHECK	K-03 spatial bundle	Contract rejected because the two inputs use incompatible CRS definitions for the requested distance computation.
$\tau_{3}$	T-03	C4	RETRYABLE FAILURE	failure= CRS_MISMATCH	Failure evidence is recorded; unconstrained execution is blocked.
$\tau_{4}$	T-03b	C4/C6	REPLANNING	$G_{1}$ , K-04	Orchestrator inserts an explicit governed transformation task; original $G_{0}$ remains immutable.
$\tau_{5}$	T-03b	C6	COMPLETED	K-04 accepted	Inputs transformed to a distance-suitable CRS; transformation lineage retained.

Table 12. Synthetic architecture trace demonstrating failure, recovery, validation, and provenance. Times are logical offsets, not measured latency.

Criterion	Evaluation question	Evidence in the design artifact	Result
E1 Requirements coverage	Do inherited, functional, and non-functional requirements have identifiable design owners and mechanisms?	DR1–DR8 map to DP1–DP8, HLA owners, LLA mechanisms, and observable records; FR/NFR responsibilities are represented across C1–C11 and runtime controls.	Covered
E2 Internal consistency	Are responsibility, direction, policy, evidence, and failure semantics mutually consistent?	C7 owns governance, C8 owns governed authoritative evidence, S4 owns validation, C10 packages released results; twenty principal flows have explicit direction; failure states terminate in retry, replan, escalation, compensating action, or termination.	Consistent by design review
E3 End-to-end closure	Can a representative objective traverse the architecture without relying on hidden corrective behavior?	Table 12 demonstrates task identity, contract rejection, CRS failure, graph revision, policy decision, spatial validation, uncertainty retention, output packaging, and provenance closure.	Demonstrated
E4 Technology independence	Can logical orchestration remain stable while implementation choices vary?	DP3 separates capabilities from providers; C4-L3/L4 are implementation surfaces; contracts and task semantics remain above specific models, geospatial platforms, clouds, and protocols.	Supported architecturally

Table 13. Analytical evaluation of the ANASSA design artifact.

Agentic Workflows

Agentic workflows coordinate AI agents, tools, and humans across multi-step tasks, emphasizing reliable execution, efficiency, and oversight.

See all 218 papers

ANASSA: An Agentic AI Orchestration Framework for Spatial Intelligence
Sep 13, 2026Constantinos Papantoniou, Brian HiltonLLM Agent Orchestration Geospatial Reasoning
Anassa.ai USA · Research Scientist USA
Agentic AI Orchestration Framework for Spatial Intelligence: Supply Chain Deployment
Oct 25, 2026Constantinos Papantoniou, Brian HiltonAI Agent Architecture Multi-Agent Orchestration
Anassa.ai USA · Research Scientist USA
Spatial Strategies, Not Actions: Vector-Quantized Geodesics as Tools for LLM-Driven Agents
Sep 30, 2026Gabriel TuriniciLLM Agent Skill Learning Tool-Using Agents
CEREMADE CNRS Université Paris Dauphine - PSL Paris 75116 FRANCE

Sep 13, 2026J/K move · Enter open · S save

ANASSA: An Agentic AI Orchestration Framework for Spatial Intelligence

Constantinos Papantoniou, Brian Hilton

Anassa.ai USA · Research Scientist USA

LLM Agent Orchestration Geospatial Reasoning AI Agent Governance

Open paper AskPDF arXiv

The emergence of large language models (LLMs) and large multimodal models (LMMs) has enabled a new class of agentic systems capable of integrating natural language understanding with tool-based execution. In geographic information systems (GIS), this shift is transforming traditional, expert-driven workflows into semiautonomous systems that can interpret user intent, construct spatial workflows, and execute geospatial analysis tasks. However, existing approaches remain limited by fragmented integration of reasoning, execution, and evaluation, particularly in complex, real-world environments. This study synthesizes recent advances in agentic GIS frameworks, benchmarks, and surveys to identify limitations in spatial reasoning, execution robustness, validation, governance, and evaluation. Building on these insights, it introduces ANASSA (Autonomous Neural Agents for Spatial Systems Architecture), an agentic AI orchestration framework that integrates structured spatial reasoning, multi-agent workflow orchestration, execution feedback, authoritative spatial validation, provenance, uncertainty handling, and human decision authority within a unified system design. The contribution is an architecture-level specification: eleven components across four layers, a six-step Geospatial AI Cognitive Loop, cross-component contracts, and governance mechanisms intended to make agentic geospatial workflows traceable, reproducible, and accountable. Empirical performance evaluation is reserved for implementation and deployment studies.

Abstract

Agentic Workflows

Explore similar work

ANASSA: An Agentic AI Orchestration Framework for Spatial Intelligence

Agentic AI Orchestration Framework for Spatial Intelligence: Supply Chain Deployment

Spatial Strategies, Not Actions: Vector-Quantized Geodesics as Tools for LLM-Driven Agents