The Knowledge Problem: Lessons from Building with AI for Nature

Problem Definition

The problem we set out to solve, and how our understanding evolved

At the broadest level, the project intent was to apply generative AI technology in a viable way for addressing real end user needs in conservation. Our starting focus area was the navigation of the rapidly growing field of biodiversity monitoring technologies. Following Conservation International (CI) and the Nature Tech Collective developing the Nature Tech for Biodiversity Sector Map, Earth Genome joined the journey to investigate agentic approaches to first querying that data. Through rapid learning, we both expanded our ambition to support the entirety of the “pre-validation” phase of biodiversity project planning, and narrowed the use case that would test and confirm the value of what we built to CI’s Yaguas Nature Credit Pilot.

When evaluating available technology solutions and providers, many teams, whether implementers or funders, don’t know where to begin or how to effectively choose and implement a solution. Our initial hunch was that an AI tool, deeply knowledgeable about needs of biodiversity work and the capacity of partner organizations and technology options, could provide the handholds and assessment to match needs to options available in this dynamic marketplace. The problem, framed at the outset, was information overload, and lack of fundamental clarity for navigation of an extremely dynamic marketplace of solutions. The challenge was to design an AI advisor to help practitioners move from complex, fragmented resources toward clear, context-relevant technology plans.

Early user interviews confirmed that the greatest friction occurs well before any technology decisions. Practitioners struggled not just to select the right technologies, but how to select and align with evolving credit and reporting frameworks, choose appropriate indicators, define what to monitor, and balance rigor, cost, and feasibility. While resources like the Nature Biodiversity Tech Sector Map offered one essential component of this journey, it represented only a slice of the full decision space. The need was a clearer path from high-level intent for nature outcomes, to specific, implementable, measurable and financeable solutions. As a result of the complexity of the knowledge, users frequently face uncertainty regarding critical questions, such as project eligibility, required monitoring protocols, and which technologies to use for measurement, reporting, and verification (MRV). At this point, the problem definition evolved from simply improving access to biodiversity technology information, to creating a structured, AI-assisted pathway through early-stage project design.

The project team recognized that the most valuable intervention would be a system that models the role of a trusted advisor who helps users clarify goals, map requirements, and navigate choices among frameworks, methodologies, and monitoring tools. The Biodiversity Advisor Agent, eventually entitled Eco, was a generative AI-driven assistant that guides users through key considerations in the pre-validation phase of biodiversity projects. To test and track the quality of the work and ensure credible and quality results, the project focused on the Yaguas Nature Credit Pilot as a proving ground. Yaguas provided a use case where the tool’s answers could be evaluated against an existing real-world project design that, through extensive manual effort, had aligned a monitoring approach with credit methodologies. If Eco could come to similar conclusions as a manual effort for Yaguas, or at least help point in those directions, it would be more trustworthy for other cases which had not been investigated so extensively.

User Discovery

Learning from user research, to ground in real need

It was essential to ground what we built in real user need. AI solutions are impressive, but frequently on close examination there is a gulf between the hype and the usefulness and veracity of the outcome. Getting close to the user was essential to anchoring what we are building to demonstrable value.

Method of Discovery

The project began with a focused user needs assessment, consisting of interviews with individuals and teams developing and implementing biodiversity projects at CI.

The user discovery phase included input from sixteen individuals and groups representing diverse functions across conservation, project development, and nature finance. Participants contributed expertise in areas such as ecological assessment and baseline data collection, credit methodology development, monitoring protocol design, blue carbon and freshwater ecosystem management, corporate sustainability frameworks, and regenerative land use. This breadth provided a comprehensive view of biodiversity monitoring challenges spanning project conception, technical implementation, and market alignment.

The interviews were conducted in an informal, conversational format with two to three team members per session. The primary objective was to understand the practitioner’s end-to-end journey: how biodiversity challenges were defined, technologies were evaluated, and implementation decisions were made. The course of the interviews did not necessarily stick strictly to predefined questions, but also responded to interesting topics emerging within the conversation. Interview questions covered several core areas:

• Project context and goals: defining the biodiversity issue, scope, and alignment with frameworks such as CCB, TNFD, or the emerging nature credit market.
• Evaluation and capacity: understanding user familiarity with available technologies and their organization’s internal technical capacity.
• Decision-making constraints: identifying limiting factors such as feasibility, budget, and logistical barriers.
• Learning and reflection: capturing lessons learned, information gaps, and areas where better guidance could improve outcomes.

Learnings

These interviews had several conclusions for consideration in the build of the agent, and still hold true as points for consideration in future developments. First, the lack of standardized monitoring frameworks significantly decelerates projects at the early stages. A useful offering would be contextualized “starting kits” for monitoring in specific biomes that provide guidance for approaches that blend manual methods with high-tech sensors in hard to access areas. Finally, cost vs. rigor tradeoff assessments would be highly valuable for these personas.

The agent should embed methodology compliance rules to quickly rule out inappropriate project designs and technologies based on the required metrics. One important support focus for the tool is to help design robust, auditable data trails that link data from field collection to final reporting, addressing key needs for financial payments tied to targets.

For corporate partners, the agent could bring much value in guiding the connection from biodiversity data to compliance and nature credit schemes. The guidance should include regionally aware assessments of technology cost, as well as make clear which global datasets are adequate for estimating the “state of nature” when primary data is unavailable.

Organizing Knowledge

Understanding the Landscape

To guide the work, we identified a need for structured synthesis of knowledge on biodiversity project implementation, beginning with a cohesive framework that clarifies how biodiversity project design actually unfolds in practice. We sought to understand not only the steps involved, but how individual user journeys intersect into this broader landscape of project implementation. This understanding was developed from the user interviews, extensive desk research, and close collaboration with peers and partners, particularly Josh Berger / The Biodiversity Footprint Intelligence Company, Okala, Nature Tech Collective, and WILDLABS.

This synthesis helped clarify how diverse approaches, tools, and frameworks align across four foundational steps:

• Framing “Why” Establishing the overarching purpose to ensure biodiversity projects generate high-integrity, credible outcomes. This step speaks to the values and motivations of measuring biodiversity, from reporting to donors to reporting to SBTN to receiving credits, emphasizing integrity, transparency, and fairness as guiding principles.

• Determining “Where” Clarifying the spatial and ecological context of projects. This includes understanding ecosystem types and boundaries, and ensuring that site selection and project type are appropriately matched to ecological realities and policy frameworks.

• Defining “What” Identifying what is being measured and valued in biodiversity interventions. This focuses on selecting the ecological dimensions such as species, function, and landscape that best capture the impact of conservation and restoration activities.

• Designing “How” Outlining the methodological and technological pathways for implementation. This step links metrics to practical measurement approaches, emphasizing rigor, scalability, and alignment with evolving best practices. It also identifies opportunities for collaboration with partners and organizations that bring technical expertise, data infrastructure, and field implementation capacity, ensuring that biodiversity measurement and verification are grounded in shared standards and collective learning.

The spectrum of use cases this synthesis addressed are very broad, and in order to constrain the problem to something practically manageable, we narrowed the focus of the knowledge resources collected to one specific example “why”: nature credit project development.

Technical Approach

The technical approach for Eco is defined by a modular architecture and a user interface (UI) explicitly designed to support the pre-validation project planning phase for biodiversity initiatives. The system’s core requirements revolve around guiding the user through complex decisions and generating a structured, trustworthy project brief. The UI is designed to clearly announce its purpose, and not appear as a “standard” chat application.

Agent Interface

Key functional and UI requirements were defined as:

• Guided Interview: The agent interactively poses questions across project stages and retains information gathered from the user to inform subsequent questions and the final output. Extensive back-and-forth conversation is expected. Document upload is provided to more quickly proceed to important clarifications in the guided interview.

• Structured Retrieval: The system organizes user input into a logical framework, dynamically updating a project summary. It integrates context resources, including PDF documents, semi-structured data (such as the biodiversity tech sector map), and external APIs (like Geocoding and Biodiversity Information APIs) to enrich the information provided by the user.

• Report Generation: The agent compiles all collected and enhanced information into a concise, structured guide or project brief. This final output is an interactive, shareable structured project brief presented section by section.

• Resource Transparency: To ensure credibility, the agent surfaces references to the specific resources used to inform specific pieces of guidance within the report.

• Flexible Layout: A central pane can be used for the main chat dialogue, or displaying details of any section of the report. The left side pane has a short summary for each stage, visually tracking the completion status of each project section in the outcome report.

• Session Management: The system manages user sessions on the front end, allowing users to save ongoing sessions and share generated results via links. The agent and interface is responsive to user language, responding in chat and updating UI according to language in use.

Agent Architecture

The front end application was built with NextJS, with user authentication and user storage managed by Clerk and a Postgres database. AI interactions were via OpenAI’s Responses API. Tools performed a variety of functions, from sorting through rule sets, querying species databases, and building maps.

The agent architecture consists of the following:

• LLM core: A language model (gpt-5) handled understanding user input and questions, planning, and generating responses.
• Tool orchestration: After classifying the intent of the request, the “planner” selected and sequenced specialized tools (frameworks, species, monitoring, technology, actors, mapping) based on that intent.
• Rule engine: A rules layer (Contextual-Rules Augmented Generation, described below) constrained and guided the model with explicit criteria from biodiversity frameworks and expert guidance.
• Aggregation and reasoning: Synthesized tool outputs, resolved conflicts, deduplicated data, and applied rules for consistency with standards.
• Citation composer: When tools are used, inline citations are attached to specific statements for verification of sources.
• Formatting / UX: Produced concise, Markdown-formatted answers with bold highlights, lists, and section headings. Avoids raw JSON.

System Message and Tools

The plain language system message for Eco mainly describes the available tools it can call to respond to specific stages of the project report, as well as details on how to format responses to work within the application. We especially tuned the agent to ground its answers in verifiable information and adequately present its level of certainty.

Those messages are:

- If you are highly confident (>80%) in factual accuracy, give the answer directly.
- If you are uncertain, clearly signal uncertainty (e.g., "I'm not certain, but …").
- If you do not know, or cannot verify, say "I don't know" rather than guessing.
- Do not bluff with plausible but unverifiable details.
- Prefer partial, qualified, or hedged answers over confident falsehoods.
- When relevant, suggest how the user could verify the information (e.g., with retrieval, citation, or external source).

We developed the following tools that the agent could use:

• Frameworks: Explains and compares biodiversity/nature credit frameworks and standards, including methodologies, crediting logic, additionality, permanence, leakage, and verification.
• Species: Retrieves species information and occurrence records for a location, using IUCN Red List and GBIF.
• Monitoring strategies: Recommends monitoring designs: sampling frameworks, indicators, baselines, power analysis hints, and reporting intervals for species and habitats.
• Monitoring technology: Suggests technologies (e.g., acoustics, eDNA, camera traps, drones, satellite data) and how to deploy them, with trade-offs and sourcing guidance.
• Actors and organizations: Surfaces relevant organizations, platforms, validators/verifiers, data providers, and market actors in nature tech and biodiversity.
• Mapping species: Renders species occurrence points on a map for the project area.

JRAG

While the unspecialized LLM model used in the project, GPT-5, clearly had extensive relevant material in its training data, and provided somewhat adequate answers, the responses were often too generalized, unattributable, and not easily reasoned over.

We initially utilized traditional RAG approaches to ground the model with the selected resources. RAG tokenizes documents, generates encoded summaries (embeddings) for similarity search, and then retrieves portions of relevant documents to provide context to the LLM for a particular completion. However, we found that RAG introduced several limitations:

• Unstructured Retrieval Retrieval in traditional RAG is frequently broad and unstructured, which creates the risk of missed details.
• Interpretation Burden The LLM must interpret long, messy text retrieved from documents, increasing the risk of misinterpretation.
• Lack of Rule-Based Outputs Traditional RAG makes it hard to provide consistent, rule-based outputs (e.g., providing a definite pass/fail eligibility assessment).
• Poor Transparency Citations in traditional RAG are often shallow or generic (e.g., “from Doc X”), rather than referencing precise rules, which makes it difficult for the model to reason or weigh information effectively.

The RAG approach was found to be prone to errors when performing unstructured retrieval across a large span of documents, and provided insufficiently detailed or citable answers. To overcome this, we developed the JSON Rule-Augmented Generation (JRAG) approach. JRAG is designed to ensure responses are grounded in evidence and transparent in reasoning, and provide answers that are accurate and actionable.

JRAG replaces the unstructured text retrieval of traditional RAG with structured, citable, human-readable rulesets. These rulesets are pre-distilled from documents and resources, in partnership with the language model itself through a lengthy reasoning process to digest these lengthy documents into a simpler, common structure. These rulesets serve as the ground truth for the agent’s reasoning. Every rule is defined in a simple JSON structure with specific components:

• name: A human-readable identifier for the rule.
• description: A brief summary of the rule.
• detail: The detailed criteria or rule description.
• cite: The explicit citation linking the rule back to its source document.

For example, a rule for HIFOR might specify that the HAA must be >= 100,000 ha:

{
  "HIFOR": [
    {
      "name": "minimum_project_area",
      "description": "Projects must encompass a large HIFOR Accounting Area (HAA).",
      "detail": "The HAA must be ≥100,000 ha, made up of one or more entire Management Units (MUs). At each Monitoring Event, total forest extent within the HAA must be ≥80,000 ha.",
      "cite": "HIFOR Methodology, 2024, Applicability & Ecological Integrity"
    }
  ]
}

For a sense of scale, the entire HIFOR framework is digested into a few dozen rulesets. Since the rulesets are human readable and editable, they can be reviewed by experts to ensure accuracy, and modified if needed to capture anything missing or misrepresented.

JRAG was used in the following workflow:

1. Query Input: The user enters a query, such as “Generate biodiversity credits in Yaguas National Park, Peru”.
2. Tool Invocation: The model decides to call a specific tool, such as the framework_tool.
3. Ruleset Query: The system queries the relevant JSON rulesets (which may be accessed via an external API).
4. Reasoning and Response: The model reasons over the retrieved rules using the user’s original query as context, and then generates a response.

This approach allowed the agent to reason over explicit rules and provide more trustworthy and well-cited answers.

Feedback & Testing

Pressure testing as we built and evaluated results

During and after the implementation phase, the agent underwent several rounds of testing with intended users to refine its performance and utility for initial biodiversity project planning. We used this user testing to gather critical feedback on the agent’s conversational style, content accuracy, and user experience. We conducted testing sessions with people from the previous needs assessment interviews.

The testing protocol was designed to be hands-on and user-driven. During 1-1 meetings between the tester and the project team member, users were encouraged to either follow the agent’s lead toward particular end goals, or drive the conversation in different directions. Testers were encouraged to try anything that seemed possibly interesting and informative for their work, and to assess the answers provided. The entire chat session was recorded in a log, alongside notes on their observations and feedback of the experience with the agent.

It is important to note that the nature credit landscape comprises a diverse set of actors with highly specialized and heterogeneous problem statements. As a result, portions of the interviews at times reverted to exploratory problem discovery and scoping. We found that it was difficult for participants to clearly articulate well-defined questions, especially given the nascency of this space.

Implementation Phase Testing

In initial rounds of testing, key feedback centered on the agent’s content integrity, conversational style, and user interface functionality.

• Flow The step by step flow, paired with a user friendly report output, was described as intuitive, and provided a useful guiding framework. However, the agent was criticized for moving too fast through the sections, to the point of feeling pushy. There was also a suggestion that the initial step could be less conversational and more form-like to more quickly get a baseline understanding of the user and their needs.

• Precision Testers expressed frustration with the agent’s initial tendency to provide general information that didn’t rise to the level of their prior knowledge. Sometimes the agent made duplicative or irrelevant suggestions, or added complexity without clearly establishing relevancy. Testers wanted the agent to provide detailed information and examples of other specific projects and pricing elements.

• Citations Testers generally expressed positive feelings about how information was cited. When the agent offered advice, comparisons between products, or suggestions, testers wanted to know exactly why a recommendation was made and demanded clear sources.

• Tone The agent’s tone was criticized for being too nice and optimistic, diminishing credibility. Rather, users preferred a professional and expert tone, while also acknowledging where there was uncertainty in its answers.

• Interface Testers noted specific bugs, such as the page not automatically scrolling down and the location section being broken.

Post-Implementation Testing

After incorporating further changes based on the initial interview, we conducted a second phase of user testing. Participants in this second phase were asked to interact directly with the agent and provide structured feedback on the relevance, accuracy, and usefulness of the responses generated.

Overall, testers felt dissatisfied with the results. Testers felt that the answers provided were not targeted or detailed enough to provide real guiding value in complex biodiversity monitoring situations.

That said, the sessions illuminated specific avenues of improvement and identified different failure points. We compiled user feedback from this phase into the following takeaways:

1. Thought Partner value should shift from general advice to structured, use-case driven design. The highest value of an AI thought partner is not in broad guidance but in structured, project-specific decision support aligned to recognized standards and use cases. Modular, stepwise outputs that mirror real project workflows (framework selection, indicators, sampling design, and technology) are essential to avoid cognitive overload and enable defensible decisions.

2. Early screening and project definition are the primary risk-reduction levers. Early-stage screening, particularly around avoided loss eligibility, biodiversity outcome relevance, and core project typology, has outsized impact on downstream feasibility and credibility. Front-loading these filters rapidly narrows viable standards, reduces misaligned monitoring investments, and materially lowers development risk.

3. Revenue potential and buyer demand now drive framework selection. Framework selection is increasingly dictated first by revenue potential, including carbon stacking and bundling opportunities, and second by the monitoring requirements needed to unlock those revenues. In an immature market, buyer preferences (i.e., ex-post vs ex-ante) and supply-chain demands are decisive, creating strong value in tools that explicitly align project design with real demand across geographies and nature outcomes.

4. Tools that can be used in both compliance and voluntary markets will be the most versatile and usable. Incorporating national compliance schemes with voluntary biodiversity frameworks in the agent will reveal meaningful overlap in indicators and sampling designs, enabling the agent to be oriented for both markets simultaneously. Compliance markets offer scale and long-term legitimacy, while voluntary markets provide earlier financing pathways for emerging project types, making dual-market design a strategic advantage.

5. Credibility depends on explicit, framework-specific monitoring guidance. Users require clear, framework-specific guidance on additionality, minimum viable sampling designs, and detection confidence levels to translate recommendations into implementation. Confidence-tiered monitoring plans, credible data sources, and well-cited justifications materially increase trust and allow meaningful comparison across standards.

6. Quality requires domain structure, not output complexity. As general-purpose LLMs advance, quality depends on controlled inputs, careful prompt engineering, and deep domain framing rather than longer or more complex responses. Structured tables, decision-tree logic, and iterative, conversational refinement supported by real-time data discovery will outperform exhaustive, static recommendations in both usability and accuracy.

Next Steps

This work produced a functioning prototype, a novel retrieval technique, and a clearer diagnosis of the real barriers to AI-assisted biodiversity project design. This includes the realization that the nature credit field’s fragmented knowledge base is as much a limiting factor as the technology itself. While practitioners’ core decision-making needs were not yet met, these building blocks and the lessons learned help define a more targeted path forward.

The underlying technology and approaches for leveraging LLMs develop at an intense pace, and lessons that hold true today may be outmoded soon. Model improvements may or may not address limitations of RAG, but it is expected that knowledge structuring and application design will remain key challenges despite any model improvements. Looking ahead, the next phase of development continues along two complementary tracks.

Deepening the Knowledge Base

We are continuing to explore opportunities to improve the quality and precision of Eco’s responses through iterative collaboration with expert reviewers and field practitioners. This includes completing and refining the user experience, and developing the tooling of JRAG to make it easier for users to build, test, and customize rulesets interactively.

There is also a need to expand the knowledge base to include additional methodologies, frameworks, principles, and other resources.

Building a Broader Nature + AI Collaboration

In parallel, we aim to seed a broader collaboration among organizations and researchers developing AI applications across different nature and biodiversity use cases. This collective effort would:

• Develop an open, shared set of evaluation benchmarks to rigorously test AI for nature implementations and clarify their strengths and focus areas.
• Encourage open sharing of tool and agent definitions for reuse, potentially as standardized components (e.g., Claude skills), that incorporate key resources from the corpus of biodiversity knowledge.
• Explore the JRAG approach as a generalizable method for structured reasoning and transparency across nature-related AI projects.
• Promote a shared practice of deep user partnership, knowledge curation, and human-centered AI engineering, strengthening both rigor and community learning.

Together, these parallel tracks aim to consolidate the technical foundations of Eco while fostering an open, collaborative ecosystem for trustworthy AI innovation in biodiversity and nature-based work.