It’s been about a month since North51 in Banff. For those who haven’t been, it’s a unique event on the geospatial calendar. It’s a small, single-track conference that fosters great group discussions rather than broadcasting lectures. There are no sales pitches here, just geospatial people staring at the same mountain range, trying to figure out where the industry is actually going.
One theme dominated the room: AI. Specifically, the shift from AI that analyzes Earth observation data to AI that decides what data gets collected in the first place. We heard a lot about agents that can spot a wildfire, check the weather, and automatically task a satellite to get a better look. It sounds incredible. It sounds like the future.
Except, as I listened to the panels, I couldn’t help but think about the plumbing. We are talking about building autonomous, highly intelligent agents, but we are trying to run them on infrastructure that still relies on manual emails and proprietary APIs. We are trying to build Star Trek on top of infrastructure that still feels like the telegraph system.
The Value of Expertise in a Physical World
In my last post, I argued that AI makes human expertise more valuable, not less. Tools like Copilot are incredible at generating “vibe-coded” solutions that look plausible but often fail on the complex edge cases of reality, like the International Date Line or polar projections.
The same logic applies to the physical world of satellite tasking, but the stakes are significantly higher. An AI “hallucinating” a Python function is annoying; an AI hallucinating a satellite tasking request is expensive and wasteful.
Right now, an AI agent can find geospatial data through use of the STAC (SpatioTemporal Asset Catalog) specification. An agent can rely on this standardized way to search petabytes of imagery. But if that agent wants to create new data (e.g., “Take a picture of Banff next Tuesday”), there is no widely adopted “Tasking STAC.”
The Tower of Babel
To task a satellite and get data today, you have to learn a specific dialect for every step of the chain.
- Provider A has a REST API for tasking but delivers data via an FTP server you have to poll.
- Provider B uses a SOAP endpoint for ordering and pushes data to an S3 bucket you don’t control.
- Provider C requires you to email a shapefile to a sales engineer and sends you a download link days later.
This fragmentation is a massive coordination problem. It can be tackled by humans (we can read documentation, write custom scripts, and call support), but it is tedious and error-prone. AI agents can also tackle this, generating integration code in milliseconds.
However, the risk of failure is significantly higher for AI. When a human encounters an ambiguous API parameter or a broken zip file, they pause and investigate. An AI agent, lacking that context, is more likely to hallucinate a fix or brute-force a solution that works technically but fails operationally. Every time a provider changes an unversioned API or alters their delivery structure, the agent’s custom-built driver breaks.
Instead of a robust automated workflow, you get a fragile web of custom integrations that requires constant maintenance. If we want AI to act reliably and at scale in the physical world, we can’t expect it to independently maintain 50 different custom drivers. Reliability requires a standard, not an infinite list of edge cases.
Interoperability as an Enabler
The reason you can build a bot that scrapes a million websites is that they all speak HTTP. You don’t need a custom driver for google.com and another for element84.com. The standard (HTTP) abstracted away the complexity of the connection. So we need the “HTTP of Tasking.”
To understand what that looks like, we have to look at the different ways AI agents will interact with satellites. Consider two different request types an AI might make.
First is Tipping and Queuing. In this scenario, a wide-area sensor detects an anomaly (e.g. a potential oil slick or a ship in a restricted zone). It commands a high-resolution sensor to “look 20° off-nadir” or collect a swath of data in this location. This is a tightly coupled operational loop where sensors are talking directly to other sensors.
Second is Rapid Response. Imagine an AI agent monitoring a disaster zone for a humanitarian organization. It searches the STAC archive and finds plenty of data from yesterday, but nothing from today due to cloud cover. The agent doesn’t need to know how to fly a satellite, nor does it care which specific satellite takes the picture. It just has a simple question: “Who can get me a clear image of this bounding box in the next 4 hours?” This is a commercial procurement problem.
These aren’t just different use cases; they represent fundamentally different levels of abstraction. One is sending instructions to a machine; the other is expressing intent to a market.
Existing Efforts
We aren’t starting from scratch. There are standardized approaches that address these distinct layers. The point isn’t that one of these wins; it’s that AI agents require something stable to stand on.
For the Tipping and Queuing scenarios, we have standards designed for direct device interaction. The OGC SensorThings API (specifically Part 2: Tasking) provides a lightweight, IoT-centric way to command devices. Meanwhile, the emerging OGC API – Connected Systems is modernizing the robust capabilities of the older Sensor Web Enablement (SWE) stack, designed to handle complex systems. Platforms like OpenSensorHub have proven how powerful these tools (and their predecessors like SOS/SPS) are for unifying control over diverse sensors like drones and cameras in a closed loop.
However, these device-centric approaches are often overkill for the “ordering” problem. They assume you know which device you are talking to and have the authority to command it. They are less suited for the high-level questions an AI agent asks a marketplace, like “Who can see this building next Tuesday?”
One emerging effort in this space is STAPI (Sensor Tasking API). Instead of modeling the complex internal state of every sensor, it focuses on a simple, transactional workflow: Discovery, Feasibility, and Delivery. It aligns with the philosophy that made STAC successful – keep it simple, JSON-based, and focused on user intent rather than engineering details.
For an autonomous agent acting as a consumer searching the open market for data, a standardized Tasking API could provide consistent answers to three questions that are currently buried in PDFs and emails:
- Discovery (“What is on the menu?”): Before an agent can order, it needs to know what is possible. Does this provider offer 50cm resolution? Do they have a SAR C-band sensor? In a standardized world, an agent can crawl the capabilities of a dozen providers in milliseconds, filtering for the exact match for its mission, rather than hard-coding assumptions about what “Provider A” sells.
- Feasibility (“Can you actually do it?”): This is the hardest part of the chain. Asking “Can you image Banff next Tuesday?” involves complex orbital mechanics, cloud cover probability, and competing customer priorities. A standard Tasking API abstracts this complexity away. The agent submits a polygon and a time window, and the API returns a set of “Opportunities” – validated windows where the collection is physically possible. This allows the agent to shop around for the best opportunity without needing to understand the physics of the constellation.
- Ordering & Delivery (“Close the loop”): This is often the most broken link. Even if you successfully order a satellite image via API today, the delivery mechanism is often an afterthought such as an email link, an FTP upload, or an S3 bucket with a cryptic folder structure.
A tasking API like STAPI can unify the order with the delivery. When the task is complete, the agent doesn’t get a zip file; it gets a STAC Item. This is the critical handshake. Because the agent receives standardized metadata first, it can evaluate the delivery (such as checking cloud cover, geometry, and sun angle), before it even downloads a byte of data. By standardizing the delivery into the same format as the archive, we close the loop. The agent searches with STAC, finds a gap, tasks with STAPI, and receives the result as STAC. It creates a seamless cycle where historical data and future data speak the exact same language.
The AI Agent as a Platform User
We are moving into an era where software won’t just look at our data; it will create it. But “AI Agency” is impossible without standards. We successfully standardized EO archives with STAC. The next big challenge is to standardize the EO ordering. Until we do that, our AI agents will be brilliant minds stuck in a room with no hands.
As I wrote in STAC: A Retrospective Part 2, the success of a standard isn’t determined by its technical perfection, but by its adoption. The “Field of Dreams” fallacy (if you build it, they will come) is just as dangerous for tasking APIs as it was for catalogs.
Complex, comprehensive frameworks like the Connected Systems API are technically impressive and necessary for specific engineering domains. But for the broader market of AI agents and commercial tasking, complexity is a barrier. Any effort that hopes to succeed will need to follow the “Guerilla Standards Playbook” that made STAC successful: keep it simple, leverage other standards, and focus relentlessly on the developer experience.
If we want AI to act in the physical world at scale, we don’t need the standard that models every possible sensor state. We need the one that everyone actually agrees to use. The work happening now across the standards community is not the flashy part of AI-automated tasking, but it is the part that will actually make it work. To continue this conversation, reach out to our team directly on our contact us page. We’d love to hear your thoughts on the future of standards in the AI age.
