Earth Observation workflows rarely operate within a single platform as a geohazard analysis may combine satellite data held in one infrastructure, processing capabilities operated by another provider, specialised scientific models maintained by expert teams, contextual information subject to access restrictions, and validation undertaken in notebooks or GIS environments. Making these elements work together is therefore as much an interoperability and governance challenge as it is an AI challenge.
GEP has recently outlined how agent-assisted workflows could help users move from a geohazard objective to a trusted and traceable workflow. It has also described how openEO is planned as an additional processing interface, alongside EO Application Packages, OGC API – Processes and other documented service APIs.
These directions are closely connected because agent-assisted workflows will be most useful when they can work with the diversity of data, services, models and infrastructures that already exists across the EO ecosystem, without requiring every capability to be transferred, rewritten or operated through a single platform. The next evolution for GEP is therefore to prepare an environment in which distributed capabilities can be described, discovered, combined, executed and traced more systematically, while respecting where they are operated, who controls them and which technical interface is most appropriate.
What makes an EO capability agent-ready?
An agent-ready capability is not simply a service with an API but a capability whose purpose, applicability, inputs, outputs, access conditions and execution interface can be understood by software, and whose use and results remain traceable and subject to appropriate human control.
For an assisted workflow to select and use a capability responsibly, it needs sufficiently clear information about:
- what the capability does and which scientific or operational purpose it supports;
- the geographic, temporal and thematic conditions under which it is applicable;
- the required inputs, expected outputs and relevant parameters;
- the provider responsible for maintaining it and the version being used;
- the interface through which it can be invoked;
- applicable authentication, authorisation, licensing and data-handling conditions;
- expected infrastructure, resource and cost implications;
- the provenance and execution evidence that will accompany its results;
- the validation status, known limitations and points requiring expert review.
Making this information machine-understandable does not transfer scientific responsibility to an agent. It gives an assisted system the evidence needed to propose a suitable workflow, explain its choices and identify where confirmation or specialist judgement is required.
Common meaning, native execution
A central principle for an agent-ready EO ecosystem is that a common way of understanding a capability does not require a common way of executing it.
An openEO workflow should be able to remain openEO-native while a mature containerised EO processing chain should remain an EO Application Package, exposed through OGC API – Processes where this is the appropriate model. A specialised scientific model or external service should be invoked through its documented API when transferring or rewriting it would be unnecessary or impractical.
The purpose of interoperability is not to flatten these capabilities into a single execution technology. It is to provide enough common meaning for users and software systems to discover them, assess their suitability, connect them within a workflow and interpret the resulting evidence.
Execution may also remain distributed and processing large EO archives can take place close to the source data, computationally intensive models can run where the required resources are available, and sensitive operational or contextual information can remain within an institutional or customer-controlled environment. Coordination around the workflow should preserve these boundaries while maintaining access control, provenance and visibility over execution.
From a geohazard objective to a distributed workflow
Consider a request to assess ground deformation following an earthquake where the user may begin with an objective and an area of interest, without knowing the precise dataset, processing service, parameter configuration or analysis environment required.
An assisted workflow could help identify suitable Sentinel-1 observations, determine whether an appropriate deformation-processing capability is available, check its geographic and temporal applicability, and verify the access and infrastructure conditions associated with its execution. The selected processing chain could then run close to the relevant archive, with its outputs registered in a catalogue and made available for analysis in a notebook or GIS environment.
If contextual information or a complementary model is held elsewhere, the workflow could invoke that capability through its documented interface rather than requiring it to be moved into the same backend. Throughout this process, the system would retain the selected capability versions, input references, parameters, execution records and derived-product relationships.
The resulting deformation product would not become trustworthy merely because an agent had assembled the workflow. Scientific experts would still need to assess processing quality, uncertainty, possible artefacts and fitness for the intended use. The role of assisted orchestration is to make the path from objective to evidence more efficient, transparent and reproducible, not to remove scientific judgement.
An agent must also be able to recognise when a workflow should not proceed automatically. Missing data, unsuitable temporal coverage, unavailable services, excessive resource requirements, access restrictions or insufficient validation evidence may require an alternative route or an explicit user decision.
What GEP provides today
GEP already provides operational foundations for this direction, including EO data discovery, processing services, EO Application Packages, cloud execution, notebooks and analysis environments, catalogues, storage, collaborative workspaces and monitoring workflows for different geohazard domains.
These capabilities support users and service providers in discovering data, running reusable processing chains, managing outputs and conducting further analysis. GEP also brings operational experience in onboarding heterogeneous services, monitoring their execution, supporting their lifecycle and connecting results with collaborative scientific and operational activities.
This existing environment is important because agent-assisted workflows need to operate across real services, infrastructure constraints and user communities, rather than only within demonstrations in which every component has been prepared for a single use case.
Agentic orchestration remains a roadmap direction for GEP, building progressively on the platform’s existing processing, analysis and collaboration foundations. The capabilities described here represent a progressive roadmap built on the platform’s existing processing, analysis and collaboration foundations.
What the roadmap adds
The first step is to make datasets, Application Packages, workflows, models, notebooks and other services easier to describe consistently. Their purpose, applicability, inputs, outputs, interfaces, policies and provenance requirements need to be sufficiently explicit for both people and software systems to interpret them.
The second step is to strengthen connections between catalogues, processing services, storage and analysis environments, including capabilities operated outside GEP. A workflow should be able to determine where inputs are held, where execution can occur, where outputs will be written and how those outputs can subsequently be discovered and used.
On this basis, GEP can progressively support assisted workflow planning. Users could describe an observation or monitoring objective, while the platform helps identify relevant data and capabilities, proposes an execution path, explains the principal choices and requests confirmation where scientific, policy or resource decisions are involved.
Selected steps may become more automated as the descriptions, interfaces and control mechanisms mature. Such automation should remain permission-aware, auditable and capable of stopping or selecting an alternative route when the required conditions are not met.
Planned openEO support is one part of this wider direction. The broader objective is for GEP to work progressively with different processing interfaces, scientific services, models and independently operated environments without requiring each provider to redesign its capability specifically for the platform.
A collaborative and federated ecosystem
No single organisation normally owns all the data, scientific models, processing services, orchestration components, infrastructure and operational knowledge needed for a complete geohazard workflow.
Platform and integration teams provide the environment for access, execution, storage, monitoring, identity and service lifecycle management. Interoperability specialists help make catalogues, capability descriptions and processing interfaces understandable across systems. Scientific teams remain responsible for model validity, applicability and uncertainty, while service providers maintain the specialised methods and interfaces through which their capabilities are made available.
Infrastructure providers enable workloads to be placed according to data locality, computing requirements, sovereignty and cost. Ultimately, scientists, institutional users and operational teams determine whether the resulting information is suitable for the intended monitoring or decision-making task.
These actors do not need to become part of one organisation or move their capabilities into one technical platform. The opportunity is to connect them through common descriptions, documented interfaces and traceable execution, while preserving provider responsibility and operational autonomy.
For GEP, this can be summarised through a straightforward principle: bring a capability into the GEP ecosystem without necessarily bringing it physically into GEP.
Preparing the next layer
The next stage of the GEP roadmap will focus on making capabilities more consistently discoverable and machine-understandable, connecting them through documented interfaces, and strengthening the provenance and control mechanisms required for assisted orchestration.
This direction builds on what is already operational while extending GEP towards a wider and more federated ecosystem. It preserves the value of established EO processing technologies, allows capabilities to remain close to their data and providers, and avoids unnecessary dependence on a single processing interface, infrastructure or cloud environment.
The objective is not to create another monolithic platform or to replace scientific expertise with autonomous decision-making. It is to make it easier for users and service providers to combine distributed EO capabilities within workflows that are transparent, reproducible and suitable for expert validation.
As the roadmap progresses, GEP will continue engaging with scientific teams, service providers and infrastructure operators around use cases, capability descriptions and interoperability requirements.
This article presents a forward-looking perspective on the GEP technology roadmap. It does not announce the availability of an operational agentic engine on GEP or a specific project implementation. The roadmap builds progressively on existing GEP processing, analysis and collaboration capabilities, together with planned interoperability developments such as openEO support.