Two internal documents independently describe the same mechanism — the SERVIR Global Platform Technical Integration Guide and SIG-NAL's GeoAI Strategy — which means GeoAI capabilities don't need their own integration architecture. A model, an alert feed, and a classifier all become available the same way.

The wrap-once pattern

Gateway components

What already exists at the consolidation point

github.com/SERVIR-AI/global-platform is not a scaffold — it's a live, actively-developed MCP server (LangGraph + FastMCP, 183 commits, 3 contributors, EPL-2.0) already answering natural-language disaster-risk questions for Southeast Asia across flood, flash flood, drought, fire, landslide, cyclone, storm, tsunami, and earthquake, and already pulling in Food Security data (GEOGLAM, ENSO/IOD). It mints every answer as a replayable, litestream-backed receipt, gated by a groundedness check before publishing — real precedent for the human-approval checkpoint this whole gateway needs, not a pattern to invent from scratch.

What it does not have yet: the gateway itself (identity/policy/routing/audit) or Agent2Agent federation — one LangGraph pipeline inside one FastAPI service, not a hub for every platform's agents. Positioning: this plan's gateway wraps and federates what's already running there, rather than competing with it.

Migrating the scattered state into SERVIR-AI

David named the org's actual GitHub footprint directly: github.com/SERVIR-AI is confirmed as “the master one that everything will end up in and where people are building things” (Decision #14). Four hub-level orgs hold the current, more scattered build activity — that inventory is now complete and carried in full below — 259 public repositories, each with a triage call (Decision #14's residual, closed). The count moved from 230 to 231 on 9 September 2026 when Platform-Inventory itself was made public, taking SERVIR-AI from one repo to two — caught by the automated sweep, which is the intended behaviour — and to 259 on 16 September 2026 when github.com/geoglows was inventoried for the first time. GEOGloWS is named as the riverine-flood forecasting backbone throughout this plan; its 28 repositories had never been read, and until geoglows was added to scripts/sweep.py the authoritative record disagreed with the plan by exactly that many. The authoritative count is data/servir-repos.json in that repo, refreshed weekly; the figure quoted in this prose is a reading, not the record, and will drift between sweeps.

Vendor-agnostic by design (Decision #10)

MCP and Agent2Agent are open protocols, not one vendor's product. Every domain agent built under this plan must stay callable by whichever LLM backend a given hub or partner actually has access to — Claude, GPT-class models, Gemini, or an open-weight model run on SIG's own SOCRATES cluster. Google.org's funding of AgriNexus does not imply a Google-only model stack; this is settled policy, confirmed, not an assumption to revisit per platform.

What is being built right now in SERVIR-AI

Three repositories in the consolidation org are where the current build is actually being organised. They are named here by David; two are private and could not be read from outside, so this plan records what they are for and flags what it needs.

global-platform, in detail — the reference implementation

This is not a scaffold. It is an active build with tests, checked-in end-to-end example payloads, a Dockerfile and GCP deploy config, and near-daily commits. Read closely, it already implements four of the six seams §04 specifies — which makes it the thing to extend rather than the thing to compete with.

The GitHub migration inventory

Decision #14 confirmed github.com/SERVIR-AI as the consolidation target and left the migration mapping as its residual — the first engineering task in the roadmap. That inventory is below: every public repository across the seven organizations, with a triage call on each. It was compiled from the public GitHub organization listings on 2 September 2026; the REST API is unavailable from this environment, so the listings are the source, and private repositories do not appear.

github.com/SERVIR-AI — 1 repos

The confirmed consolidation target (Decision #14). One repo today — and it is the only repo of all 259 with an MCP endpoint.

1 wrap as mcp

github.com/SERVIR — 132 repos

The general / legacy org and by far the largest. Fifteen years of service code, six repos already archived upstream, and the great majority dormant.

19 wrap as mcp · 10 migrate · 35 review · 7 capacity material · 61 archive

github.com/Servir-Mekong — 44 repos

The deepest hydrology and land-cover bench in the ecosystem. hydra-floods and rlcms are the two assets the platform plan leans on hardest.

8 wrap as mcp · 2 migrate · 7 review · 1 capacity material · 26 archive

github.com/SERVIR-Amazonia — 38 repos

Newest activity of any hub org. Also carries an obvious consolidation target: fourteen Tethys/GEOGloWS repos are roughly three codebases forked once per country.

4 wrap as mcp · 22 review · 11 capacity material · 1 archive

github.com/SERVIRSEA — 7 repos

Small and modern — includes two foundation-model experiments (Claynge on Clay, cashew on a CNN) that are directly relevant to the GeoAI stack in §03.

5 wrap as mcp · 2 review

github.com/pyregence — 8 repos

Partner-tool org, named by David (Decision #16). Actively developed in Clojure through September 2026 — the wildfire capability in §04 is real, current software.

4 wrap as mcp · 3 migrate · 1 archive

github.com/geoglows — 28 repos

Partner-tool org. GEOGloWS is named as the riverine-flood forecasting backbone throughout this plan — §04's flood row, §05's irrigation-water-availability signal, §07's shared streamflow row, and the Malawi and IDEAM use cases — but its code had never been inventoried, so the plan was depending on software it had not read. It is the most actively developed org in this register: eleven repos pushed in the last month, against roughly six across the two largest hub orgs all year. Licensing is permissive throughout, verified by cloning: geoglows is on PyPI and conda-forge at 2.2.0 (BSD-3-Clause-Clear), geoglows-rest-api is MIT and already a running Flask service, river-route is BSD and on PyPI. That lowers the technical barrier to wrapping — it does not define the institutional relationship. GEOGloWS is a partner with its own governance (confirmed by David, 14 September 2026), and §04's flood row stays Partner. What the inventory changes is that the partnership turns out to be better provisioned than the label implied: integration here is an agreement to reach, not a capability to build.

12 wrap as mcp · 3 migrate · 9 review · 3 capacity material · 1 archive