Applied AI and AgricultureSelected technical experience
Turning Agricultural Research into Personalised Farmer Guidance
How a rule-guided recommendation engine can evolve into a scalable, cloud-native advisory platform.
How structured farm inputs, research rules and analytical models can be combined to deliver practical recommendations through accessible digital channels.
6 minute read
Business challenge
Technology must translate complexity into a dependable service
Agricultural recommendations often begin as research models, scripts and decision rules. Farmers, field teams and digital platforms need those complex inputs converted into consistent guidance that can respond to individual farm conditions.
The challenge involves more than deploying a model. The platform must:
Validate farmer inputs
Convert units consistently
Apply domain rules
Generate personalised recommendations
Translate analytical output into understandable guidance
Deliver results through accessible digital channels
Retain sufficient evidence for quality review
Original implementation
Architecture appropriate to its original scope
The source material describes a focused implementation built with the available tools and delivery requirements of its time.
01Farmer or field inputs
02Input validation and unit conversion
03Research rules and analytical logic
04Recommendation matrix
05Plain-language text generation
06API integration
07Mobile-accessible delivery
Original technical capabilities
Statistical-computing components
OpenCPU API exposure
Database-backed content
Decision-tree mapping
Conditional and skip logic
Input-parameter mapping
Modularisation of research scripts
Content validation and quality assurance
Integration with a digital delivery platform
Why modernise it
Scaling considerations
These are architecture considerations for future growth, not confirmed failures in the historical implementation.
Input processing and recommendation logic may scale together unnecessarily.
A failure in one step can interrupt the entire request.
Long-running calculations can exceed ordinary web-request limits.
Updating domain rules may require redeploying unrelated code.
Historical input and recommendation data may become difficult to analyse at scale.
Monitoring may not identify the processing stage that failed.
Crop or regional models may require different runtime dependencies.
Modern AWS reference architecture
A possible cloud-native design
This reference architecture describes how an organisation could modernise the workflow. It does not describe the historical implementation.
01Mobile or web channel
02Amazon API Gateway
03Input Validation service
04Amazon SQS
05AWS Step Functions
06Preprocessing service
07Recommendation service
08Rules service
09Explanation service
10Recommendation result store
11Monitoring and audit services
Service responsibilities
Separating the workflow
API layer
Amazon API Gateway would provide the controlled entry point for web and mobile requests.
Secure HTTP API
Request-structure validation
Authentication and throttling
Routing to the appropriate service
Versioned API endpoints
Lightweight serverless services
AWS Lambda suits short, stateless and event-driven tasks that do not need a continuously running server.
Request validation and unit conversion
Lightweight feature preparation
Routing and notifications
Audit-event creation
Short synchronous tasks
Workflow orchestration
AWS Step Functions records and coordinates each stage, making progress and failure handling visible.
Validation and preprocessing
Model selection and recommendation generation
Rule checks and explanation generation
Result persistence
Retries and failure handling
Decoupling with queues
Amazon SQS lets requests wait safely between services instead of requiring every component to respond at once.
Survive temporary service failures
Retry safely
Wait for long-running processing
Process stages independently
Absorb traffic spikes
Containerised recommendation services
Docker provides each component with a repeatable runtime containing its code and dependencies. Amazon ECR would store the images.
Preprocessing service
Recommendation-engine service
Domain-rules service
Text-generation service
Model-serving service
Container orchestration
Where Amazon EKS becomes useful
Amazon EKS becomes useful for sustained or specialised workloads. It is an option, not a default requirement.
When to consider EKS
Custom statistical-computing, Python or system dependencies
Processing longer than a typical Lambda invocation
Predictable compute or specialised CPU and memory
Several independently deployable model services
Horizontal scaling and portability across environments
Kubernetes components
Deployments for long-running APIs
Jobs for one-off processing and CronJobs for scheduled refreshes
Services and ingress or load balancing
Horizontal Pod Autoscaler
ConfigMaps plus Secrets Manager integration
Health and readiness probes
Resource requests and limits
Big-data foundation
Services that become useful as data grows
Amazon S3 data foundation
A larger platform could organise historical farm observations, soil and weather information, inputs, training datasets, recommendation outputs and audit artefacts into raw, validated and analytics-ready layers.
AWS Glue
Glue could catalogue datasets, discover schemas, prepare data through ETL jobs and make S3 datasets easier to query.
Amazon EMR Serverless
EMR Serverless runs Spark or Hive jobs without a permanent cluster. It becomes relevant for large seasonal and regional datasets, wide joins, feature generation or batch recommendations across many farms.
Analytics
Amazon Athena supports direct SQL analysis over S3. Redshift Serverless becomes useful only when frequent dashboard queries or complex cross-dataset reporting justify a managed analytical warehouse.
Model lifecycle
Amazon SageMaker is one option, not a requirement.
Version training data and feature definitions
Track model and domain-rule versions
Record evaluation results and deployment approval
Monitor deployed behaviour
Retain a tested rollback path
Optionally use Amazon SageMaker for training jobs, a model registry, batch or asynchronous inference, and hosted endpoints
Architecture comparison
Original scope and a modern reference design
The original design suited its context. Modern services become relevant when operating scale and reliability requirements change.
Original implementation
Modern AWS reference architecture
More tightly coupled workflow
Independently deployable services
Manual or batch-heavy processing
Event-driven orchestration
Relational operational storage
S3 data lake plus fit-for-purpose stores
Limited stage-level visibility
Centralised logs, metrics and tracing
Shared runtime dependencies
Docker-packaged components
Primarily vertical scaling
Serverless or Kubernetes-based scaling
Shared technical controls
Observability, security and deployment
Security
IAM least-privilege access
AWS KMS encryption and TLS
AWS Secrets Manager
Private networking where appropriate
Audit logs, data minimisation and approved retention policies
Environment separation, container-image scanning and dependency scanning
Observability
Amazon CloudWatch logs and metrics
AWS X-Ray or OpenTelemetry tracing
Correlation IDs across service calls
Queue depth, processing latency and error rate
Model-confidence distributions and data-quality failures
Kubernetes pod health plus model and rules versions
Infrastructure and deployment
Docker for repeatable packaging and Amazon ECR for image storage
Terraform for infrastructure as code
Automated tests and CI/CD pipelines
Separate development, staging and production environments
Rolling or canary releases
Automated rollback based on health checks
What organisations could achieve
Customer possibilities
These are careful, non-quantified outcomes that a suitable implementation could support.
Deliver personalised guidance through mobile and web channels
Update domain rules independently from application code
Support multiple crops and regions
Process seasonal batch workloads
Trace recommendations to input, model and rule versions
Monitor failures at each processing stage
Scale services according to demand
Maintain human review for high-impact recommendations
Architecture must match data volume, response-time requirements, model complexity, available engineering capacity, privacy risk, budget and expected growth.
A pipeline design for cleaning conversational data, integrating multiple language-analysis services and retaining predictions with confidence and history.
