Limit what agents can do

One way to constrain agents is to give them a specific set of tools rather than letting them generate or execute anything. Granted, these tools can be quite broad, such as generating Python code. But we've found that smaller, more focused tools are usually easier to control and maintain. It's a familiar software engineering principle: keep things small and composable.

We've used this approach in several projects:

• GeoAssistant: A LangGraph-based agent that can query the Overture Places API and retrieve NAIP imagery.
• Global Nature Watch Horizon: Agents that generate code as an intermediate step rather than producing unconstrained text or image outputs.

In these examples, the agent decides which tools to use, while the tools handle the actual work. Rather than relying on a language model to generate every result, we can use existing APIs and services to retrieve and process the data.

Controlling how agents respond

When working with scientific and environmental data, we need to be careful about how language models present information. Even when an agent retrieves the right data, asking a model to generate a response introduces another opportunity for errors.

One approach is Retrieval-Augmented Generation (RAG), which grounds responses in an existing knowledge base. This can reduce mistakes, although it doesn't eliminate them. We can go a step further by limiting the format of an agent's response as well.

At the Responsible AI Hackweek, Lilly Thomas demonstrated a snow cover analysis agent that retrieves information from reliable APIs and fills in a predefined response template. Rather than spending tokens generating a long explanation, the agent returns information in a predictable format. The workflow costs only cents per query. We've explored similar approaches in our work on NASA Earth Information Explorer (EIE).

Another method we’ve tried is to keep the original data separate from the generated text. An agent can identify relevant data and use well-defined tools to retrieve or process it. The results are then delivered to the application for visualization, without passing through another round of text generation. Unlike many agents where the LLM’s output is the final answer, we are building agents that return the underlying data itself—rendered maps, statistics, and dataset links—so users can inspect primary sources alongside any natural language output.

These agent development patterns are applicable to bounded, well-defined use cases where the types of questions and analyses users will request are known in advance. It works best when the workflow can be decomposed into a finite set of discrete tools, and when predictability, reproducibility and cost efficiency matter more than open-ended flexibility.

Choosing smaller, focused models

Regardless of the workflow, the brain of an agent is still a language model. It's easy to reach for the largest, most capable model available. But do we really need a frontier-level model for every task? Large, general-purpose models can be expensive to run, especially when an agent makes repeated calls to complete a task. For organizations that provide data and services for free, those costs can become difficult to manage.

For well-defined tasks, a smaller model may be sufficient. Some open-weight models can also be hosted on an organization's own infrastructure, providing more control over operating costs and where data is processed. We've experimented with Small Language Models (SLMs) for geocoding through Gazet. We're also looking at ways to optimize smaller models for particular tasks rather than using a large, general-purpose model for everything.

Smaller models won't work for every application, but they might be a good solution when the task is narrow enough. They can also offer options for organizations concerned about privacy or dependence on external model providers.

Building agents with constraints

There's plenty of excitement around increasingly autonomous AI systems. But through our own experiments, we've found that giving agents fewer options can sometimes produce more useful results.

Limiting the tools they can access, controlling their outputs, and using smaller models are all ways to make agentic workflows more predictable and manageable. There are tradeoffs, of course, and we're still learning where these approaches work best.

In a way, working within these constraints is where some of the most interesting innovation is happening. Rather than trying to build agents that can do everything, we're finding ways to make them useful for specific tasks, with the tools and resources we actually have.

For organizations working with scientific and environmental data, the opportunity isn't just to add AI to existing services. It's to make that data and the tools around it easier to use in new workflows. We're interested in helping organizations make that transition, building on the standards and infrastructure they already rely on rather than replacing them.

Our GeoAI team will be in Berlin the week of October 19th at the Agentic AI for Earth Observation conference, and we'd love to hear how others are approaching these challenges. Find us there, or get in touch to continue the conversation.