Krushi AI

Agricultural advice is high-consequence and highly contextual. The right answer depends on soil data, current crop cycle, and which government schemes a farmer is eligible for — three different data sources, two of them live APIs rather than documents.

It also has to reach people who are not going to type a query in English. The interface constraint — voice, in the user's own language — is not a feature layered on afterward; it determines what the system can be.

And it is a domain where a confidently wrong answer causes real harm. Hallucinated agronomic guidance is not an embarrassing demo failure; it is advice someone might act on for a season.

I built a multi-agent advisory system coordinated by a LangGraph orchestrator, with specialized agents owning soil data retrieval, crop recommendation, and government scheme lookup. Each hands structured results back to the coordinator for synthesis, so the coordinator composes an answer rather than any single agent guessing across domains it does not own.

The agents are ReAct-style tool users on LangChain/LangGraph runtimes, reasoning iteratively over tool outputs rather than following a fixed call sequence. That matters here because advisory queries do not decompose predictably — what you need to look up second depends on what the first lookup returned.

Exposing live external APIs to an agent layer is where this class of system usually gets unsafe. I routed external agricultural APIs through MCP server endpoints, which gives schema-validated structured data lookups alongside unstructured document retrieval — the agent works against a declared contract instead of improvising request shapes against a live service.

Retrieval needed a designed failure path. The RAG pipeline uses embedding-based retrieval with an explicit fallback strategy on retrieval miss, and carries source traceability down to filename and chunk, so every recommendation is auditable back to its origin. In an advisory domain that traceability is the difference between a suggestion and an answer someone can check.

Against hallucination I applied response validation and domain-scoped prompt templates, constraining what the system is willing to assert about sensitive agronomic questions rather than trusting the model to decline on its own.

1. MCP servers as the tool boundary for external APIs

   Letting an agent construct arbitrary calls against live agricultural services is unsafe and unauditable. MCP endpoints give schema-validated lookups, so the contract is declared and enforced rather than improvised per call.

2. ReAct reasoning over a fixed call sequence

   Advisory queries do not decompose predictably — the second lookup depends on the first result. A fixed pipeline either over-fetches every source or misses the one that mattered.

3. Source traceability to filename and chunk

   In a domain where advice gets acted on, a recommendation that cannot be traced to its origin is not verifiable. Carrying provenance through synthesis makes auditability a property of the output rather than a separate lookup.

4. Domain-scoped prompting and explicit response validation

   Hallucinated agronomic guidance causes real harm. Constraining what the system will assert is more reliable than expecting a model to recognize the edge of its own competence.

Farmers query the system by voice in English, Hindi, or Marathi and receive advice synthesized across soil data, crop recommendation, and government scheme eligibility — three sources that previously required separate lookups.

Every recommendation traces to its source document and chunk, so guidance can be verified rather than trusted, and retrieval misses degrade to a designed fallback instead of a fabricated answer.