FieldLoop

Fieldloop: WhatsApp-first agricultural decision support for Canadian farmers
The scale and economic importance of Canadian agriculture
Agricultural volatility makes timing and context important
The problem: useful information is fragmented at the moment of decision
The design decision: bring intelligence to the farmer, not another dashboard
Text, voice, photos, English and French through one WhatsApp workflow
The Outcome Loop: from question to action, follow-up and outcome
Fieldloop’s Cloudflare-based retrieval and messaging architecture
Reliability safeguards and automated regression coverage
Where Fieldloop goes next

Inspiration

Canadian agriculture operates at enormous scale, but the information a farmer may need in a single decision is often spread across government publications, provincial resources, crop guides, weather services, and current web sources.

The problem I became interested in was not simply whether that information exists. It was what happens when a farmer is actually standing in a field, looking at frost damage, unusual leaf symptoms, or a changing weather situation, and needs the right context for a decision now.

That led me to a narrower question:

What if agricultural decision support could fit into a workflow the farmer already understands instead of asking them to learn another dashboard?

That question became Fieldloop.

What it does

Fieldloop is a WhatsApp-first agricultural decision-support assistant for Canadian farmers.

A farmer can send a normal text question, record a voice note, share a crop photo, or communicate in English or French.

From there, Fieldloop tries to understand the agricultural context of the question, including the crop, location when available, and what the farmer is actually trying to decide.

It then determines what evidence is useful for that specific question. That may come from the prepared agricultural knowledge base, live web evidence, current weather information, or a combination of those sources.

The system is deliberately cautious where certainty is not justified. A crop photo, for example, can help narrow what a farmer should inspect next, but Fieldloop does not treat a single image as definitive proof of a disease.

The goal is decision support, not replacing the farmer, an agronomist, pesticide labels, regulations, or field scouting.

But the part of Fieldloop that matters most to me is what happens after the first answer.

The Outcome Loop

Most AI interactions can effectively end once an answer has been delivered.

Fieldloop is built around a longer workflow:

Ask -> Investigate -> Recommend -> Act -> Follow up -> Record outcome

When a recommendation genuinely needs reassessment later, the farmer can reply DONE after taking action.

Fieldloop can then follow up and record whether the result:

WORKED
is IMPROVING
FAILED
is still UNKNOWN

If the result is FAILED, the same case can continue with its earlier context instead of treating the farmer's next message as an entirely new problem.

This is not automatic model retraining.

It is case continuity: keeping the original question, the action taken, and what happened afterward connected.

How I built it

Fieldloop uses Meta WhatsApp Cloud API as the farmer-facing interface.

When a message arrives, it first reaches a Cloudflare Worker, where the incoming request is handled and validated. The job is then placed onto a Cloudflare Queue, and the queue consumer moves it into Fieldloop's main processing pipeline.

Inside that pipeline, Cloudflare D1 maintains farmer, case, preference, and follow-up state. R2 stores documents, while Vectorize and BGE-M3 provide retrieval over the agricultural knowledge base.

The retrieved evidence is then used to support Qwen in generating the farmer-facing response.

The broader system includes:

Cloudflare Workers for compute
Cloudflare Queues for asynchronous processing
Cloudflare D1 for structured state
Cloudflare R2 for document storage
Cloudflare Vectorize for vector retrieval
BGE-M3 for embeddings
Qwen through Workers AI for response generation
Whisper for voice transcription
Tavily for selective live web search
Open-Meteo when current weather information is genuinely relevant
Cloudflare Cron for bounded follow-up scheduling
Meta WhatsApp Cloud API for the messaging interface

The routing is intentionally selective.

Fieldloop does not automatically call weather because a farmer mentioned frost, and it does not search the live web for every question. Crop, province, intent, and the strength of available evidence influence which tools are actually used.

Building the knowledge layer

A large part of the project was not model selection at all. It was building a usable agricultural evidence layer.

I researched and collected approximately 90 agricultural sources.

After reviewing source usage rights and production readiness, 22 sources were prepared for static production retrieval, producing 2,006 production-ready chunks.

Other sources remain more appropriate for live retrieval or permission-dependent use rather than being copied into the static knowledge base.

Province and crop context also influence retrieval. When the static knowledge base does not provide a strong local match, Fieldloop can selectively use live evidence instead of forcing an irrelevant source into the answer.

Prototype access

Fieldloop is a working hackathon prototype, and the demo video shows the real end-to-end system running through WhatsApp across text, voice, crop photos, French, retrieval, and follow-up workflows.

Public self-service access is intentionally limited at this stage.

The current WhatsApp integration uses Meta's test environment, which restricts messaging to approved test recipients. I also designed the project around a free-first infrastructure approach so I could build and validate the complete workflow without turning the prototype into an expensive cloud project.

For this submission, the live product is demonstrated through the recorded end-to-end workflow, while wider farmer access remains a next-stage step.

Challenges

The hardest part of Fieldloop was making it behave like a decision-support system rather than a generic chatbot.

Some of the problems I had to solve included:

Preventing evidence about the wrong crop from influencing an answer
Deciding when live search should or should not run
Avoiding unnecessary weather calls
Preserving uncertainty when interpreting crop photos
Handling duplicate WhatsApp deliveries safely
Bounding retries instead of allowing endless retry loops
Maintaining farmer and case state across separate messages
Scheduling follow-ups only when they are actually useful
Continuing the same case when a farmer reports that a recommendation failed
Supporting English and French through the same workflow

Another challenge was learning how much a real AI product depends on systems outside the model itself.

During final testing, Workers AI experienced an account-level quota issue that temporarily blocked inference even after the usage dashboard showed the quota had reset. The application logic itself remained intact, and service later recovered, but the incident reinforced an important production lesson: an AI inference provider should never become a single point of failure.

That is now part of the future resilience plan for Fieldloop.

Reliability

A farmer should not have to think about queues, retries, deduplication, or routing logic.

Those systems should simply make the conversation dependable.

Fieldloop includes protections for:

Meta webhook verification
Duplicate message handling
Bounded retries
Crop-aware evidence filtering
Province-aware retrieval
Weather-intent detection
Citation handling
Voice and image processing
Follow-up eligibility
Quiet hours and farmer preferences
Case and outcome lifecycle

The current system is backed by roughly 290 automated regression and reliability checks covering these workflows.

The purpose of that engineering is not to make the product look complex.

It is to keep the farmer-facing experience simple.

What I learned

Building Fieldloop changed the way I think about AI products.

At the beginning, it is easy to think the model is the product.

By the end of this project, I had learned that the difficult part is everything around the model:

What evidence should it receive?

When should an external tool be called?

When should it not be called?

How should uncertainty be communicated?

How do you keep one user's case separate from another?

What happens when an external provider fails?

And most importantly, what happens after the answer is delivered?

That final question became the core of Fieldloop.

What's next

The next stage for Fieldloop is not simply adding more features.

It is making the same workflow stronger and more useful over time.

That includes:

Broader Canadian crop and agricultural domain coverage
Stronger farm-specific context
Wider access beyond approved test recipients
Fallback AI providers for greater resilience
Continued evaluation of retrieval and evidence quality
Richer use of case and outcome history
Maintaining a clear separation between farmer-reported outcomes and verified agronomic evidence

Fieldloop started with a simple idea:

Useful agricultural intelligence should fit into the farmer's workflow instead of forcing the farmer to adapt to another tool.

The result is not just a chatbot inside WhatsApp.

It is a decision-support workflow that connects the farmer's question, the evidence used to investigate it, the action that follows, and what happens afterward.