Building an environmental intelligence platform on AWS with open data

When a catchment manager wants to know how much phosphorus pollution would decrease if they converted 30 percent of the upstream grassland to woodland, answering that question might involve aggregating multiple data sources, such as:

1. Government water quality archives for phosphorus monitoring data
2. Sentinel-2 satellite imagery from Amazon Web Services (AWS) Open Data for a land use classification
3. A phosphorus export model with modified land use parameters
4. Biodiversity indicators to check whether the intervention would affect protected species
5. Geospatial foundation model (FM) embeddings to detect what has changed on the ground between years, distinguishing real land use change from seasonal variation

Each source has its own data format, API, coordinate reference system, and access method. Traditionally, this integration work requires a geographic information system (GIS) specialist, someone who can write scripts to reconcile projections, parse disparate formats, and chain analysis steps together. Without that expertise, the question either waits weeks or goes unasked entirely.

Multiply that by dozens of river water bodies requiring regulatory assessment in a single catchment area, and the scale of the expertise bottleneck becomes clear.

Solution: One question, multiple tools, trustworthy answers

We built a working prototype of a serverless environmental intelligence platform, where nontechnical users ask questions in plain language and receive answers drawn from open data, published models, and satellite observations. The platform is built on four pillars, as outlined in the following table.

All data comes from AWS Open Data and government datasets under open licenses; there are no commercial data dependencies.

Architecture

A user’s question flows through:

1. Frontend (Amazon S3 and Amazon CloudFront) – Map interface and chat, authenticated using Amazon Cognito
2. Amazon Bedrock Agents – Understands intent, selects which tools to call and in what order, and synthesizes a plain-language response
3. AgentCore Gateway – REQUEST interceptor validates each tool call is within scope. RESPONSE interceptor injects data source attribution
4. Lambda tools – Each handles a specific environmental data domain, exposed as Model Context Protocol (MCP) tools through the gateway

We decided to use AgentCore Gateway because governance is centralized and updating guardrails or traceability means changing an interceptor, not redeploying six tools. The gateway also exposes the tools over MCP with semantic search enabled, so the agent can find the right tool from a natural-language query instead of relying on a hardcoded list.

Multi-tool chaining: The platform decides the workflow

The agent chains tools automatically based on the question. The platform requires no preconfigured workflow. The user asks one question, and the platform decides the analysis sequence.

For example, if the user asks, “What if we convert 30 percent of improved grassland to broadleaf woodland in the upper catchment?”, then the agent follows this flow (an actual run):

1. The agent has every parameter it needs, so it runs the phosphorus export model immediately. Converting 555 of 1,850 hectares of improved grassland takes the total export from 3,881 to 3,409 kg per year, a reduction of 472 kg, or 12.2 percent.
2. With the answer in hand, it goes back for the evidence to explain it. It calls the phosphorus model a second time for a full breakdown, which shows that improved grassland is the single largest source in the catchment at 1,757 kg per year, on an export coefficient roughly ten times higher than broadleaf woodland’s.
3. It then calls the land use tool, which shows that this grassland accounts for 40.9 percent of the catchment and carries a high phosphorus risk rating.

The answer led with the number, explained why the intervention works, and carried the model’s own caveat: this is a steady-state estimate, and the full reduction would take 5–15 years to realize. The agent’s final response closed by asking whether to model the arable land as well, rather than recommending it.

Two tools, three calls, one question. The second and third calls weren’t in any workflow: the agent made them because the first result needed to be explained.

Satellite change analysis using TESSERA embeddings

Without TESSERA (Temporal Embeddings of Surface Spectra for Earth Representation and Analysis), change detection usually requires working directly with multitemporal satellite imagery, including data preparation, cloud filtering, feature or index calculation, and comparison across dates. This can require significant geospatial expertise and processing, and straightforward spectral comparisons can also be sensitive to seasonal vegetation changes.

TESSERA is a geospatial foundation model developed at the University of Cambridge. It represents a year of Sentinel-1 and Sentinel-2 observations as a 128-dimensional embedding for each 10-meter pixel. The embedding is a compact learned representation of the pixel’s annual spectral and temporal behavior, including seasonal and phenological information.

For the land manager, the interaction involves asking what changed between 2023 and 2024. The platform compares TESSERA embeddings across millions of pixels and returns a change heatmap on the map. The expertise hasn’t disappeared. Instead, it has moved into the embeddings and the tools around them.

The following table summarizes the differences between using TESSERA and not using TESSERA.

A second capability, similarity search, lets a user identify an area of interest and search for locations with similar TESSERA embeddings. This can help surface areas with similar spectral-temporal characteristics without manually reviewing satellite imagery.

Dataset discovery with the RODA MCP server

Platforms typically require developers to preconfigure every data source. When a new dataset becomes available, someone must write a new connector.

The Registry of Open Data on AWS (RODA) MCP Server gives the platform the ability to discover datasets on demand. Over 1,100 open datasets (for climate, satellite imagery, biodiversity, genomics, and more) become searchable through natural language.

In the platform, the TESSERA team publishes the embeddings to RODA. When the registry lists it, discovering and evaluating it happens through the agent rather than through documentation:

1. Discover – A natural-language search for geospatial embeddings for land change detection returns the TESSERA dataset (v1.1) with its description, license, and Amazon S3 path.
2. Explore – Requesting further details returns the dataset’s temporal coverage, spatial resolution, and file format.
3. Evaluate – Previewing the bucket reveals the directory structure and tile naming conventions, and sampling a single file confirms the embedding dimensions and coordinate reference system.
4. Integrate – With this information, a developer builds the Lambda tool.

This means the platform’s knowledge of what is available grows with the registry. Turning a newly discovered dataset into a working tool still means writing a Lambda function. But the searching, documentation reading, and manual inspection that used to come first is no longer part of the process.

Guardrails: The system knows when not to answer

During development, we discovered the platform was too eager. When asked, “Should we plant woodland on this slope?”, it confidently recommended an intervention, without acknowledging that the answer depends on soil type, protected species, drainage, and planning regulations it knows nothing about.

In environmental decision-making, a wrong answer from AI can cause real harm. The REQUEST interceptor blocks queries outside the system’s competence:

The solution follows the principle that AI provides analysis, and humans make decisions.

Traceability: Every tool result has a source

The RESPONSE interceptor injects attribution into every tool response, as described in the following table.

By providing attribution, the agent turns a response like “the AI said phosphorus is elevated” into something a land manager can cite. The answer carries the reading itself, the archive it came from, the license it’s published under (such as Open Government Licence v3.0), and when it was last updated. This kind of attribution can support a regulatory submission after its currency is checked. Merely claiming that the source was AI is insufficient.

Who else can use this pattern

We built the platform for one problem, but the pattern isn’t specific to water quality or to any single catchment. Consider who faces the same barrier:

• Environmental regulators and catchment authorities assessing dozens of water bodies against regulatory targets.
• University research groups that have the domain expertise but not the engineering time to build data pipelines.
• Nonprofits and community groups monitoring a local river or woodland with no technical staff at all.
• Land managers and landowners who want to understand how their own land use affects the surrounding environment (including the soil, water, and biodiversity) without commissioning a consulting firm to carry out a study.

That last group is worth dwelling on. As it stands today, a farmer considering a change to field margins or a land manager weighing a woodland planting scheme, either pays for a specialist assessment or proceeds without evidence. Wanting to understand what would happen if one element were changed is exactly the kind of question this platform is designed to answer.

What transfers to a new domain isn’t the platform itself, but three architectural choices:

1. One tool per data domain – Each Lambda function owns a single dataset and exposes it to the agent. Adding air quality means adding a tool, not rewriting the system.
2. Governance at the gateway, not in the tools – Guardrails and source attribution live in the gateway’s interceptors, not in the tools. Changing what the system will and won’t answer is a single change in a single place.
3. Discovery instead of preconfiguration – Because the agent can search RODA directly, the set of datasets it can find and describe isn’t fixed at build time.

There are a few instances where this pattern doesn’t fit, including decisions that require regulatory-grade precision or domains where the underlying data sits behind commercial licenses. Our platform is designed to be a way to ask better questions faster, and it isn’t a substitute for a formal environmental assessment.

What’s next

The prototype covers one catchment and a fixed set of tools, which leaves several directions we intend to develop further.

• Scaling beyond a single catchment – The heaviest analysis currently runs inside one Lambda function, already at its memory, storage, and 15-minute limits, and similarity search rescans every pixel on every query. Regional coverage would mean moving that work out of a single function, fanning tiles out in parallel, precomputing and indexing embeddings so similarity search becomes a lookup, and returning raster layers by reference from Amazon S3 rather than inline.
• Validation with research institutions – Working with universities and research bodies to validate platform outputs against field observations and expand to new environmental domains.
• Validating what the agent reports – Source attribution proves where a number came from, not that it survived the journey into the sentence the user reads. The next step is automated checking that figures in a generated answer match the raw tool output.
• New domain tools – Using the RODA MCP discovery pattern, building Lambda tools for soil moisture (NASA SMAP), and air quality (OpenAQ).

Conclusion

The environmental data exists: petabytes of satellite imagery, millions of monitoring records, decades of species observations. Most of it is public. The barrier was never the data. It was the specialist work needed to bring it together.

This platform shows that someone without GIS training can ask a question in plain language and get an answer drawn from several environmental datasets at a time, with each tool result carrying its own source and confidence. When the answer needed a judgment call, the system asked rather than recommended.

Learn more

To build environmental data tools on this pattern, start with the resources below:

• Geospatial Power Pack for Kiro
• TESSERA v1 paper – CVPR 2026
• TESSERA v2 preprint – arXiv:2607.03949
• Geotessera library on GitHub

To learn how AWS Open Data supports open science and public sector decision-making, visit the Registry of Open Data on AWS.