Four years ago I wrote about revolutionizing rice farming with IoT AWD at KhawTECH. The hardware worked. The LoRaWAN sensors worked. The platform worked. Farmers could see water levels on a phone. What we still didn’t have was the thing that turns data into remembered, field-specific advice… you know, the agronomist who knows that *this* paddy drains faster after re-levelling, that *this* farmer wants to approve the pump himself near flowering, that *last* season AWD here cut pumping by roughly a third with no yield loss, etc.

When the Alibaba Cloud hackathon opened the MemoryAgent track, it felt less like a side project and more like the missing layer of a platform I’ve been shipping in the field for years. NaLog is already proving useful in poor farming communities, so I joined the hackathon in hopes of winning further funding to scale what’s working, not to prototype something from scratch. So I built NaLog Agent: a Qwen-powered Memory-Augmented Agent on top of the live NaLog / KhawTECH IoT platform, deployed on Alibaba Cloud, and open-sourced under MIT.

This is the story of how I built it (and what I learned putting Qwen to work on a real agritech product, not a demo).

Sensors are working. It’s the memory that’s missing.

Smallholder farmers can’t afford big ag-tech. KhawTECH puts affordable AWD (Alternate Wetting and Drying) sensors in their fields. The sensors produce data. Raw data isn’t advice.

A generic chatbot fails here for two reasons:

1. Grounding: Irrigation advice has to be based on actual water levels, growth stage, and AWD phase. Inventing a number is worse than saying nothing.
2. Memory: Good guidance is hyper-local and cumulative. It has to survive across sessions and seasons, and forget what no longer matters.

That’s the Memory-Augmented Agent problem in a nutshell. And it’s exactly what I’ve been thinking about since I first wrote about Vector RAG and agentic search (not as an abstract retrieval debate, but as a practical constraint for rural deployments with limited bandwidth and small context windows).

What NaLog Agent does

A farmer asks in Thai or English something like “Does Paddy 3 need pumping now?”, and the agent goes brrrrr:

1. Reads live sensor data from the NaLog REST API (paddies, AWD cycles, water levels, trends).
2. Recalls relevant past experience for that farmer and that field.
3. Explains a recommendation grounded in real numbers.
4. Proposes pump actions for human approval and never switches a pump on its own. Only after approval does a LoRaWAN downlink go to the field via ChirpStack.

Behind the scenes it runs a bounded ReAct tool loop (up to 6 rounds), persists a 3-tier memory system, and autonomously extracts durable learnings after each turn using a cheap qwen-turbo pass.

The same tool handlers also run as an MCP server, so any MCP client can read field state, query memory, and prepare irrigation proposals (one implementation, two surfaces).

Architecture on Alibaba Cloud

The full Alibaba Cloud stack:

I wrote about testing Model Studio back in 2024 and about running Qwen in Cursor earlier this year. NaLog Agent uses the same OpenAI-compatible DashScope endpoint I’ve been using everywhere else:

https://dashscope-intl.aliyuncs.com/compatible-mode/v1

The difference here is how the models are tiered:

• qwen-turbo: cheap post-turn memory extraction
• qwen-plus: fallback chat when the tool loop needs a plain answer
• qwen-max: the agronomic reasoning loop with tool calling
• text-embedding-v3: episodic memory vectors

On a product where every token costs real money for farmers who can’t afford waste, that tiering matters.

The memory model

Three tiers, deliberately designed for the MemoryAgent track:

At recall time, relevance blends three signals:

score = 0.60 · semantic_similarity
      + 0.25 · recency           (half-life ≈ 120 days)
      + 0.15 · reinforcement     (min(reuse_count / 5, 1))

Forgetting is twofold: old memories sink in ranking (soft), and Tablestore TTL physically deletes episodic rows after ~400 days unless they’re rewritten (hard). Recall is deliberately top-K (default 5) and summarised into a compact block — never a full memory dump. That’s what makes it viable on slow rural connections with a small context window.

This is the part where my Vector RAG experience actually paid off. DashVector returns cosine distance; the local dev driver returns similarity. Ranking by position rather than raw score made recall robust across both environments.

Building on a real platform

This is not a mock dataset dressed up as agritech.

NaLog Agent connects read-only to the live NaLog API, which is the the same platform that powers the KhawTECH farming frontend. There is no aggregated “paddy status” endpoint, so the agent stitches paddy + AWD cycle + sensors + latest readings the way an agronomist would mentally compose the picture.

When NALOG_USE_DEMO=true, anyone can run the agent locally with a bundled demo farm and only a DashScope API key. When pointed at production, it reads real sensor data from fields we’ve been deploying since my first KhawTECH posts.

Safety is architectural, not prompt-only. The LLM has no “turn pump on” tool. Pump actions go through propose_irrigation → farmer approval → ChirpStack downlink (0x01 on / 0x00 off). The agent can recommend; the human decides.

Deploying on Function Compute

I’ve been deploying on Function Compute since 2018. For this project I went with FC 3.0’s ZIP-based custom runtime (custom.debian10, bundled Node 20) rather than a GPU container. As inference runs on Model Studio, the function itself is a lightweight Express 5 service orchestrating tools and memory.

The deploy flow:

npm run provision      # Tablestore tables (with TTL) + DashVector collection
npm run deploy:build   # Linux node_modules via Docker → dist/nalog-agent-fc.zip
npm run deploy:fc      # CreateFunction / UpdateFunction + HTTP trigger

If you want the deep dive on FC itself, I covered GPU-based Qwen hosting in a separate post. NaLog Agent takes the opposite path: tiny ZIP function, heavy lifting on managed Model Studio.

What surprised me

Grounding beats fluency. Tool-calling over live sensor data, with explicit “never invent water levels” rules, produces trust in a domain where a wrong pump decision costs diesel, yield, or both.

Memory is the product unlock, not the chat UI. Farmers don’t need another bot. They need something that remembers their fields and gets cheaper to run over time.

Forgetting is as important as remembering. Without TTL and recency decay, episodic memory becomes noise within a season.

Model tiering is an economic feature. Per-turn token reporting in the API response makes the cost visible. On a platform for people who count diesel litres, that transparency matters.

Open source

The project is MIT-licensed and on GitHub. Docker quick-start, demo mode, swappable storage drivers (local for dev, alibaba + dashvector for production), tests, smoke scripts, and full docs included.