How we shipped agentic harnesses for agriculture

State pushed us past single-model question answering. A chat answer is one inference and one reply. The jobs in our enterprise deployments have steps, branches, side effects, and state that has to survive across turns and systems. We call the tools and runtime that manage those jobs the harness.

This is the engineering version. There are easier posts on this blog if you want the product version.

The starting point

In late 2024 we had Dhenu 2, an 8-billion-parameter language model fine-tuned for Indian agriculture. Plug it into a chat interface, point it at a farmer’s question, and it would return a grounded answer in the language the question was asked in. The accuracy was high, the latency was good, the deployment was inexpensive. It looked like a solved problem.

Then the questions farmers asked turned out to be a small fraction of the work an agricultural AI needed to do. A farmer asking “should I irrigate today” is one query. The actual job sitting behind that query, when an enterprise was deploying us to thousands of farmers, looked more like: “ingest this week’s weather forecasts from IMD, cross-reference soil moisture telemetry where it exists, identify the 1,200 farmers across our footprint whose crop is in a moisture-sensitive growth window, segment them by region for prioritised outreach, draft an irrigation advisory in each farmer’s language with brand-specific product recommendations honouring our compliance constraints, route to voice or WhatsApp based on farmer preference, escalate to a human field officer if the recommendation involves a high-cost input.”

That is not a chat. That is a multi-step pipeline, with branching, with conditional escalation, with state that needs to persist across turns and across systems.

The harness is what does that.

Architecture

The harness has four primitives. The names are ordinary on purpose.

Planners decide what needs to happen. Given a goal (“draft an irrigation advisory for affected farmers this morning”), a planner decomposes it into ordered sub-tasks. Planners are themselves language models, prompted to think step-by-step and emit a structured plan. We use a smaller model for the planner role than for the executor roles: planning is high-bandwidth low-precision; execution is the opposite.

Tools are everything the agent can do that is not text generation. Pull weather data, query the agronomy knowledge base, look up product label rates, retrieve from the field-level memory store, send a WhatsApp message, place a voice call, escalate to a human queue. Tools are typed (typed inputs, typed outputs) and the harness enforces the contract: if a tool returns malformed data, the agent sees an error, not garbage.

Validators check work before it ships. A draft irrigation advisory written by an executor agent gets validated against a checklist: does it cite a source, is it within the product label rate, does it respect the seasonal cap for this region, is the language correct for the recipient. A validator that rejects a draft sends it back to the executor with a structured failure message; the executor revises. Validators are also language models, with carefully scoped prompts and verifiable rules they enforce.

Deep research is a special tool that lets an agent decompose its own retrieval task. Instead of one RAG hop (“query the knowledge base, get top-5, condition the prompt”), the agent can ask a sub-question, get an answer, ask a follow-up, build up a research trace that resembles how a human agronomist would prepare to answer a question they didn’t immediately know. Used sparingly, this dramatically lifts answer quality on complex, multi-factor questions. Used constantly, it bankrupts you.

Orchestration patterns we use

Most of what runs in production falls into one of these patterns.

The simple chain: plan → execute → validate. A planner emits 3 to 8 steps. Executors run them sequentially, each step’s output becoming the next step’s input. A validator checks the final output. If validation passes, the result ships. If it fails, the validator’s structured feedback feeds back to the planner for a revised plan. Most of our customer-facing work runs this pattern.

Fan-out / fan-in for batch work. When a job is “draft advisories for 1,200 farmers”, the planner creates 1,200 parallel sub-tasks. Executors run in parallel (rate-limited against our cloud budget and against downstream APIs like the voice service). Results are aggregated by a reducer agent, which surfaces edge cases for human review. The pattern is roughly map-reduce, but with language-model executors that occasionally need to escalate.

The deep-research loop. For questions where the answer depends on multiple sources the agent doesn’t yet have in context, a deep-research agent runs its own internal loop: ask sub-question, retrieve, evaluate, ask follow-up, accumulate a research trace, eventually compose an answer that cites the path. The user sees the answer plus the citations. Internally there might have been a dozen retrieval calls.

What we got wrong before we got it right

A few months of mistakes that other teams building similar systems will recognise.

Letting the planner be the executor. Early on we had a single model role doing planning, executing, and self-validating. It was fast and it was wrong. The model would generate a plan, immediately commit to it, and then write self-fulfilling validations that pronounced the plan good. Separating the roles into different prompts (and ideally different model checkpoints) was a precondition for any of the downstream quality work.

Trusting unstructured tool outputs. Early tools returned strings. The agent had to parse those strings back into structured data, and it did so inconsistently. Moving to strict JSON-schema’d tool outputs (with the harness rejecting malformed responses before the agent ever saw them) eliminated a long tail of confusing failures.

Letting deep research run unbounded. Without an explicit budget, a deep-research agent will happily make 50 retrieval calls and produce a marginal-quality answer. We now budget every deep-research invocation in tokens and tool calls and surface the budget exhaustion to the user when it happens, rather than silently truncating.

Skipping validators because they slow things down. They do slow things down. They also catch the 5% of outputs that would have ended in a customer complaint. We have not yet found a deployment where the latency cost was worth skipping validation. We may eventually; we have not yet.

What we publish

The harness uses model checkpoints from the Dhenu family for most roles. We are publishing the planner and validator prompts as a research artefact along with the agent loop. The actual orchestration code is not open; it is the part of the product where the operational complexity lives and where ongoing maintenance has real cost. We may open more over time.

Documentation lives on the developer platform. The reference implementation powers our production agribusiness deployments today. If another engineering team takes one thing from this note, it should be the separation between the planner and its validator.

The part of the system still moving fastest is the deep-research budgeting. Where the trace justifies its cost varies by deployment, and we are still measuring.