MRS MILLE

Maganti parthive — Wed, 12 Aug 2026 17:34:51 +0000

I Built an Agricultural Agent That Treats Field History as Memory

Most agricultural software is very good at answering a question about the field in front of it. The harder problem is answering the next question without forgetting everything that happened before.

That is the problem I built MRS MILLE around. It is an agricultural agent that keeps a longitudinal memory of a farmer and field, then uses that history when making the next recommendation. The interesting part is not storing conversations. It is making past actions and outcomes affect future decisions.

What MRS MILLE actually does

MRS MILLE combines structured field data, agricultural observations, an LLM, and Hindsight as a long-term memory layer.

The basic flow is:

I use Hindsight because I don't want the memory layer to be just another database table. Its job is to retrieve relevant experience and help consolidate observations from that experience.

I keep Hindsight behind a dedicated memory service, so the rest of the application does not depend on its API directly.

The service starts with a simple rule:

@staticmethod
def _bank(farmer_id: str) -> str:
if not farmer_id or not str(farmer_id).strip():
raise ValueError("farmer_id is required for memory isolation")
return f"mrsmille-farmer-{_slug(str(farmer_id))}"

I deliberately make the farmer identity part of the Hindsight bank ID. Memory isolation is structural rather than something I expect every query to remember to enforce.

Within that bank, field, crop, season, and event information is represented with tags.

That gives me two levels of scope:

Farmer
└── Hindsight bank
├── Field F001
│ ├── crop
│ ├── symptoms
│ ├── recommendations
│ └── outcomes
└── Field F002

The same farmer can therefore have two fields with different histories.

Why I chose Hindsight instead of treating memory as CRUD

I originally thought of memory as something simple: save the farmer's previous messages and retrieve them later.

That approach breaks down quickly.

Suppose a farmer says:

"The leaves turned yellow last time."

The useful information is not necessarily the sentence itself. I want the system to connect the symptom to the conditions around it, the advice that was given, what the farmer actually did, and what happened afterward.

So I model an agricultural episode as:

Condition
↓
Symptom
↓
Recommendation
↓
Farmer action
↓
Outcome

For example:

Heavy rainfall
↓
Leaf yellowing
↓
Check drainage before adding water
↓
Farmer clears drainage
↓
Crop recovers

Hindsight is the part of the system that lets me retain these experiences and later recall them by meaning and context. The Hindsight agent memory documentation is useful here because the API is built around retaining information, recalling relevant memories, and reflecting over them rather than treating memory as a passive log.

I also use Hindsight's agent memory architecture as the conceptual model for separating ordinary application state from longer-lived agent experience.

The memory service is intentionally boring

One design decision I am happy with is that the Hindsight integration itself is not spread across the application.

The memory service owns the integration:

async def recall_field(
self,
farmer_id: str,
field_id: str,
query: str,
*,
budget: str = "mid",
types: Optional[list[str]] = None,
) -> list[Memory]:

resp = await self._client.arecall(
    bank_id=self._bank(farmer_id),
    query=query,
    tags=[f"field:{_slug(field_id)}"],
    tags_match="all",
    types=types,
    budget=budget,
    max_tokens=4096,
)

return _normalise_recall(resp)

The important line here is not the API call itself. It is the field scope:

tags=[f"field:{_slug(field_id)}"],
tags_match="all",

The application can ask, "What happened when this field had a similar problem?" without accidentally pulling memories from another field.

The other half of the system is reflection. Recall gives me evidence. Reflection is where I ask Hindsight to reason over the field's history alongside today's conditions.

resp = await self._client.areflect(
bank_id=self._bank(farmer_id),
query=question,
context=context,
tags=[f"field:{_slug(field_id)}"],
tags_match="all",
budget=budget,
)

I explicitly pass current conditions into the reflection context.

That is important because old memory should not automatically win.

If a field historically needed irrigation during a dry period, that does not mean I should recommend irrigation today when the field has just received heavy rain.

The current state has to be allowed to override stale history.

I don't store every conversation

Another decision I made was to avoid dumping raw chat history into memory.

The memory service has explicit event types:

class EventType(str, Enum):
PROFILE = "profile"
PREFERENCE = "preference"
SYMPTOM = "symptom"
CONDITION = "condition"
RECOMMENDATION = "recommendation"
ACTION = "action"
OUTCOME = "outcome"
NOTE = "note"

That vocabulary gives the application a useful mental model.

A farmer saying "I prefer Telugu" is a preference.

A farmer saying "I cleared the drainage channel" is an action.

The later statement "the crop recovered" is an outcome.

And the recommendation itself is an agent experience.

That distinction becomes especially useful when the system has to answer questions such as:

"Did the previous recommendation actually work?"

The one-year field story

I use a twelve-month history to exercise the memory system.

The dataset contains 108 events spanning August 2025 through July 2026, including conditions, symptoms, recommendations, actions, outcomes, recurring problems, and irrigation changes.

The important part is that the timeline contains conflicting contexts.

Earlier in the year, the field experiences moisture stress and later recovery after irrigation.

Later, heavy rainfall creates high soil moisture and temporary waterlogging.

Those two situations deliberately look similar at the symptom level but require different reasoning.

That gives MRS MILLE a useful question to answer:

"The leaves are yellow again. Should I do what I did last time?"

A conventional assistant might anchor on the previous intervention.

MRS MILLE should instead retrieve the previous episode, inspect the current conditions, and explain the difference.

The intended answer is along these lines:

The field has experienced yellowing before, but the conditions
are not identical.

Earlier, yellowing occurred during low-moisture stress and the
crop recovered after irrigation.

A later event followed heavy rainfall and high soil moisture,
where waterlogging became the more relevant explanation.

Today's readings should determine which historical pattern is
actually comparable before recommending another intervention.

That is the behavior I care about. Memory is useful because it changes the reasoning, not because it makes the UI look more sophisticated.

Making memory visible without exposing chain-of-thought

I wanted the user to be able to answer a simple question:

Why did MRS MILLE tell me this?

A response can show:

MEMORIES USED

Previous symptom
Leaf yellowing after heavy rainfall

Previous action
Farmer cleared the drainage channel

Previous outcome
Crop recovered in four days

Learned pattern
This field has experienced yellowing under waterlogged
conditions before

Current condition
Soil moisture 31%, no rain forecast

Then the recommendation can say:

"Check drainage first before adding water or nitrogen."

I am not exposing the model's private chain-of-thought. I am showing the evidence that materially influenced the decision.

The application layer stays small

The FastAPI layer is intentionally thin.

The question endpoint does three important things: retrieve relevant memories, generate the memory-informed recommendation, and return the memories used for provenance.

memories = await memory.recall_field(
req.farmer_id,
req.field_id,
req.question,
types=["world", "experience", "observation"],
budget="mid",
)

answer = await memory.recommend(
req.farmer_id,
req.field_id,
req.question,
current_conditions=req.current_conditions,
budget="high",
)

This separation makes the architecture easier to reason about:

FastAPI
|
+-- structured application state
|
+-- Hindsight memory service
|
+-- Retain
+-- Recall
+-- Reflect

The frontend does not need to know how Hindsight works.

It only needs to know that an answer has supporting memories and that those memories belong to the current field.

What a real interaction looks like

Imagine Ravi returns to the application several months after an earlier crop problem.

He asks:

"Did this field have yellowing before?"

MRS MILLE can answer from the historical record.

He asks:

"What happened after that?"

Now the agent follows the previous event into the action and outcome.

He asks:

"What did I do?"

The answer comes from the farmer action memory.

Finally:

"Why are you giving me different advice today?"

That is where the system becomes more interesting. MRS MILLE can compare the previous event with current conditions and explain why the old intervention is not automatically appropriate.

The same history can be reached through different phrasing, such as "When did I change the irrigation?" or "Wasn't this field using flood irrigation before?" The production question layer resolves those variations to the same intent and retrieves the underlying history rather than relying on a hardcoded question list.

The uncomfortable part: memory can be wrong

Persistent memory creates a new class of bugs.

A stateless assistant can be wrong about today's answer. A memory-enabled assistant can be confidently wrong because it has an old fact available.

I therefore treat temporal relevance as part of the reasoning problem.

The Hindsight bank is configured with temporal retrieval enabled, and the reflection mission explicitly tells the system to prefer newer reliable information when memories conflict.

The principle is simple:

Old memory + current evidence
↓
compare
↓
same context?
/ \
yes no
↓ ↓
reuse reconsider

This is more important than maximizing the amount of information stored.

What I learned building it

Long-term memory is a data-modeling problem before it is an LLM problem

The useful unit is not a conversation. It is an experience: condition, decision, action, and outcome.

Isolation needs to happen at the architecture boundary

I don't want to rely on developers remembering farmer_id on every query. The farmer determines the Hindsight bank; the field determines the tag scope.

Current state must be first-class

Historical memory is powerful precisely because it can become stale.

I pass today's field conditions directly into reflection and tell the system to weigh current readings above older memories when they conflict.

Memory provenance is part of the product

If a recommendation changes because of history, the user should be able to see which historical facts mattered.

"Trust me, I remember" is not a useful interface.

"Here are the three previous events that changed today's recommendation" is much better.

A good memory system should make the agent less repetitive, not merely more verbose

The goal is not for MRS MILLE to mention the farmer's past in every answer.

The goal is selective recall.

If history is relevant, use it. If it isn't, don't force it into the response.

That is the line I keep coming back to with agent memory: the system should remember more than it says.

Where I would take it next

The next layer I would invest in is evaluation: the same agricultural question expressed in many ways, across English and Telugu, with temporal references such as "last time", "earlier this year", and "after the rain". I want to measure both retrieval quality and whether the recommendation actually changes when relevant history changes.

I would also test contradictory memories deliberately. A farmer's irrigation method can change, a field can change crops, and a previously successful intervention can stop being appropriate. Those are not edge cases in a longitudinal system. They are the system.

MRS MILLE started as an agricultural question-and-answer application. The more interesting architecture emerged when I stopped treating history as a log and started treating it as experience.

The core loop is now simple:

Remember what happened.
Recall what matters.
Compare it with what is happening now.
Make a decision.
Remember the outcome.

That is the part I would build on.

For engineers interested in the underlying memory system, the Hindsight GitHub repository, Hindsight documentation, and agent memory overview from Vectorize are the places I would start.

DEV Community: Maganti parthive

MRS MILLE