Chronological evolution of Snap4City: from Km4City to Agentic AI
The evolution of Snap4City can be understood as a progression from semantic data integration, to IoT and Big Data management, then to AI-supported Digital Twins and decision support, and finally to Generative and Agentic AI capable of actively using the services of the platform. Importantly, Km4City was not replaced by Snap4City: it remained—and continues to evolve as—the semantic and knowledge-model foundation of the platform.
2013–2014 — Km4City: creating a semantic model of the city
The origins go back to 2013, when the City of Florence identified the need for a unified data aggregator capable of bringing together information that was scattered across heterogeneous municipal and third-party systems. DISIT Lab at the University of Florence responded by developing Km4City — Knowledge Model for the City, initially as a Smart City ontology and associated data-aggregation infrastructure. The idea was already more sophisticated than building a conventional data warehouse: heterogeneous information should be reconciled into a common semantic model so that roads, public services, mobility, events, sensors, administrative entities and other urban objects could be connected and queried as a coherent knowledge graph. (Snap4Solutions)
The approach was scientifically consolidated in 2014 with the publication of the Km4City ontology work. Data from multiple sources were transformed into RDF, reconciled according to the ontology, stored in an RDF store and exposed through SPARQL and application services. Km4City therefore provided the first essential layer of what would later become Snap4City: a machine-interpretable representation of the city rather than a collection of disconnected datasets. (ScienceDirect)
2015–2016 — From knowledge graph to operational urban intelligence
During 2015–2016, Km4City expanded from a data-integration experiment into an operational platform used by major research and smart-city initiatives. Sii-Mobility extended the information base toward mobility and transport and expanded coverage to Tuscany, while RESOLUTE used the platform to study urban resilience, critical infrastructures and responses to unexpected events. (Snap4Solutions)
With the REPLICATE H2020 project in 2016, the architecture became part of the infrastructure behind Florence's Smart City Control Room. At this stage, Km4City was no longer only answering questions such as “what entities exist and how are they related?” It was increasingly supporting real-time monitoring, mobility analytics, traffic reconstruction, predictions, environmental analysis and decision support. (Snap4Solutions)
This period also introduced progressively stronger AI components: machine learning for parking and mobility prediction, social-media NLP and sentiment analysis, traffic-flow reconstruction, risk analysis and decision-support models. Thus, semantic/symbolic intelligence from Km4City began to coexist with statistical and machine-learning approaches. (Disit)
2017–2019 — The transformation from Km4City into Snap4City
The decisive change occurred with SELECT for Cities / Select4Cities, launched in 2017 by Helsinki, Copenhagen and Antwerp. Its challenge was to develop an open, interoperable, scalable, service-oriented environment in which cities could rapidly create and experiment with Internet-of-Everything applications. Responding to these requirements forced a substantial modernization and harmonization of the earlier Km4City-based infrastructure. This is the period in which the broader platform acquired the name Snap4City, expressing the idea of making smart-city innovation deployable “in a snap.” (Snap4Solutions)
Technically, Snap4City added several major layers around the Km4City semantic core: IoT/IoE device management and brokers, edge computing, scalable Big Data storage, visual IoT application development, Node-RED microservices, dashboards, analytics, APIs, security and privacy mechanisms, multi-tenancy and Living-Lab facilities. Industry 4.0 integration also started during this period, expanding the platform beyond municipal applications. (Snap4City)
The 2018 scientific description of Snap4City characterized it explicitly as a scalable IoT/IoE platform for developing Smart City applications, showing the transition from a semantic data aggregator into a complete development and operational environment. (Flore)
Select4Cities Phase 3 ran from late 2018 to September 2019 and tested the platform in real environments in Antwerp and Helsinki. Snap4City received first place on 19 November 2019 at the Smart City Expo World Congress in Barcelona, with data aggregation, analytics, interoperability, flexibility and deployability highlighted among its strengths. A later Snap4Solutions history page places the winning milestone under “2020,” but the dedicated award record gives the precise award date as 19 November 2019. (Snap4City)
2020–2021 — From experimental platform to reusable Smart City infrastructure
After Select4Cities, Snap4City increasingly became a reusable Big Data Smart City platform rather than a single-project prototype. Its architecture supported bidirectional integration with open data, IoT, GIS, mobility systems, social data, Industry 4.0 systems and external services, while Km4City continued to provide the semantic knowledge base linking these resources. Analytics could then operate across domains rather than inside isolated application silos. (PubMed Central (PMC))
The platform also matured operationally through containerized deployments, multi-organizational environments, federation, improved dashboard and data-management tools, and integration with international ecosystems. In October 2021, Snap4City became a certified FIWARE platform. (Snap4City)
At roughly the same time, an important new concept emerged: the Digital Twin. By 2021 Snap4City was already releasing global and local 3D Digital Twin facilities, connecting urban geometry and BIM-like representations with live sensors and platform data. (Snap4City)
2022–2024 — The Smart City Digital Twin becomes the central paradigm
Between 2022 and 2024, the Digital Twin evolved from a visualization layer into a much broader architectural concept. Research addressed global and local 3D representations, real-time data integration, buildings and infrastructures, simulations, what-if analysis and the evaluation of changes according to KPIs. The integrated Digital Twin work presented in 2022 was expanded into a peer-reviewed framework published online in 2023 and in journal form in 2024. (Snap4City)
This changed the role of the platform again. Snap4City was increasingly conceived as a continuously updated representation of the urban environment supporting both operation—monitoring, prediction, anomaly detection and reaction—and planning—simulation, optimization, scenario comparison and decision support. Real-time streams, historical data and relationships continued to be connected through the Km4City-based knowledge graph. (Snap4City)
Km4City itself continued evolving rather than becoming a legacy component. For example, ontology version 1.6.8 was released in September 2024, showing that the semantic model remained an active part of the Digital Twin architecture. (Snap4City)
AI also moved toward a combination of machine/deep learning, XAI and symbolic knowledge. The CAI4DSA project, starting on 1 August 2024 with Snap4City as its reference platform, explicitly explored collaborative, explainable neuro-symbolic AI, human-in-the-loop decision support and systems able to learn from changing contexts. (Snap4City)
This stage is particularly important for understanding the later agents: by 2024 Snap4City already possessed the assets an AI agent would need to exploit—semantic knowledge, real-time data, historical data, IoT services, APIs, prediction algorithms, simulators, optimizers, routing services and Digital Twin representations.
2025 — Generative AI and SnapAdvisor: from dashboards to conversation
The next transition was from conventional AI models to LLM-based interaction.
In March 2025, SnapAdvisor began being provided to Snap4City contractors. During 2025 it evolved into an LLM assistant knowledgeable about Snap4City documentation and platform usage; public trials were announced from September 2025, with the platform reporting Llama-based implementations, including Llama 3.3. (Snap4City)
The first role of SnapAdvisor was essentially that of a RAG-based expert/copilot: rather than forcing users to navigate documentation, APIs and technical manuals manually, users could interrogate specialized knowledge conversationally.
Research during the same period addressed one of the central weaknesses of LLM systems—grounding. The Context-Aware RAG (CA-RAG) work published in IEEE Access in 2025 experimented with validating generated answers against their documentary context in order to reduce unsupported responses. (Snap4City)
The conceptual change was significant:
Km4City: “connect and reason about urban data.”
Snap4City: “collect, process, visualize and act on urban data.”
Digital Twin: “represent, predict and simulate the evolving city.”
SnapAdvisor/RAG: “talk to the platform and its knowledge in natural language.”
But SnapAdvisor was still principally a knowledge assistant. The next step was to let the LLM use tools.
Early 2026 — From RAG assistant to Agentic RAG
By January 2026, Snap4City was publicly reporting an early SnapAdvisor Agentic RAG LLM implementation under test, initially including a solution for processing commercial emails. This marks the transition from an LLM that retrieves and explains information toward an LLM that can participate in workflows. (Snap4City)
Research activities in 2026 broadened this direction to agentic LLMs, MCP-based integration, multimodal models, GraphRAG, neuro-symbolic AI, Deep Reinforcement Learning and interaction with APIs and knowledge bases. (Snap4City)
At the same time, specialized agent-oriented research appeared around the semantic foundation itself. The OASA-KGQA — Ontology-Aware Semantic Agent for Knowledge Graph Question Answering work was presented at IEEE Big Data Services in July 2026, reinforcing the connection between the original Km4City knowledge-graph philosophy and modern LLM agents. (Snap4City)
2026 — Full multi-agent architecture: the current Agentic AI generation
The latest major step, as of September 2026, is the Snap4City LLM-based multi-agent architecture for natural-language interrogation and exploitation of Smart City services, presented at NGEN-AI 2026. Rather than treating the LLM as a chatbot, the architecture treats it as an orchestration layer over the Digital Twin and Snap4City service ecosystem. (Snap4City)
A user can express a complex objective in ordinary language. A Planner decomposes it into dependent tasks; a router sends each task to an appropriate specialized agent; agents execute actual Snap4City capabilities; results are correlated; and a formatter constructs the final grounded answer. The current implementation describes seven categories of specialized agents and roughly 65 tools (now more than 200 tools) covering geolocation, services/POIs, IoT, entity details and observations, public transport, images, rendering on dashboards, accessing web, statistics, multimodal routing, geographic utilities, poredictions, optimisation, simulation, etc. (Snap4City)
A particularly important architectural choice is the adoption of MCP — Model Context Protocol. Existing heterogeneous REST APIs and Snap4City microservices are exposed as typed MCP tools, giving agents machine-readable descriptions of parameters, units, permitted values and errors. This converts the enormous existing Snap4City service ecosystem into something that LLM agents can systematically discover and invoke. (Snap4City)
The architecture also moves beyond simple tool calling. Each agent's output can be checked by an LLM-based Supervisor; failed actions can be retried with corrective information; a Replanner can reconstruct a failed workflow; and graceful failure can preserve valid partial results. The objective is therefore controlled and verifiable orchestration rather than allowing an LLM unrestricted autonomous access to the city infrastructure. (Snap4City)
Initial experiments are already reported: planner agent selection achieved an F1 of 90.5%; retrieval against SPARQL ground truth obtained 0.929 precision; expert evaluation of broader Smart City questions produced an F1 of 0.866; and an agentic configuration obtained a higher G-Eval correctness score than a tool-free LLM, although at substantially higher computational cost. (Snap4City)
This agentic layer is now being expressed in domain-oriented solutions such as Snap4Mobility & Transport, Snap4Tourism and Snap4Assets. In these scenarios, SnapAdvisor/Copilot can move from a natural-language objective to a workflow combining live data, Digital Twin information, prediction, routing, simulation, optimization and decision-support tools, while keeping the human operator in the decision loop. (Snap4City)
The overall technological trajectory
Seen as a single evolution, Snap4City has moved through a very coherent sequence:
2013 Km4City → semantic knowledge of the city
2015–2016 → analytics and decision support
2017–2019 Snap4City → IoT/IoE, microservices and Living Labs
2020–2021 → scalable/federated operational platform and control rooms
2021–2024 → multidomain, real-time Smart City Digital Twin
2024–2025 → XAI, neuro-symbolic AI and Generative AI/RAG
2025 SnapAdvisor → conversational access to knowledge
2026 Agentic SnapAdvisor → conversational access to tools, services and workflows
The most interesting continuity is that the 2013 Km4City idea has effectively returned at a higher level. Km4City originally solved the problem of giving heterogeneous urban data a common semantic meaning. Thirteen years later, the same semantic structure is helping AI agents understand what the available entities and services mean, while MCP and the multi-agent architecture determine how to use them.
Thus the latest Snap4City architecture can be viewed as an AI-enabled, semantically grounded and agent-accessible Digital Twin: the Knowledge Graph provides meaning; IoT and data infrastructures provide current and historical state; analytics and simulations provide prediction and possible futures; and Agentic AI provides a natural-language orchestration layer capable of composing those resources into multi-step processes.
In that sense, the evolution is not simply “Km4City → Snap4City → AI.” It is more accurately:
Data → Semantic Knowledge → Connected Things → Analytics → Decision Support → Digital Twin → Generative AI → Agentic Digital Twin.
