Building Parali: A Hindi Voice-First Farmer Experience on AWS
A Hindi voice-first farmer experience built with Amazon Bedrock, Nova 2.5 Sonic, AWS Lambda, API Gateway, and temporary credentials. Here's how I connected conversational AI, application workflows, and cloud infrastructure—and the engineering challenges along the way.
Building Parali: A Hindi Voice-First Farmer Experience on AWS
The problem: Technology shouldn't be another barrier for farmers
Many digital tools assume that users are comfortable navigating forms, typing detailed information, and switching between screens. For a farmer working in the field, that isn't always the most natural way to interact with technology.
I wanted to explore a different approach: a voice-first web experience that lets users communicate in Hindi, access relevant field information, and move through a guided workflow without losing control over important actions.
That idea became Parali, an AWS-powered prototype combining conversational voice AI with a web interface, backend orchestration, temporary credentials, and cloud storage.
The goal wasn't simply to make an AI that talks. It was to build a system in which voice, application state, permissions, and real actions work together.
What I built
Parali brings together three core experiences:
- Live voice interaction: A voice assistant named Kiara listens to Hindi speech and responds with streamed speech.
- A farmer-facing web experience: A central interface for voice interaction, field mapping, and a collection desk.
- A controlled action workflow: Tool calls can capture crop details and guide the user through permission, mapping, and confirmation steps.
The important design decision was to keep the conversational experience connected to application logic. The assistant isn't intended to be a standalone chatbot that merely produces text; it operates within a system that can coordinate actions and manage shared request state.
The architecture and AWS stack
I used AWS services to separate the user experience, backend coordination, voice interaction, access control, and persistence into distinct components.
1. Frontend and delivery
AWS Amplify Hosting
Amplify hosts the web experience and delivers the application over HTTPS. This provides the entry point for users interacting with Parali.
Amazon API Gateway
The API layer exposes HTTPS routes for application actions and polling. Keeping these operations behind an API boundary separates browser interactions from backend execution.
2. Backend orchestration
AWS Lambda
Lambda handles validation, publishing, and coordination. It connects application requests to the relevant services and helps keep the workflow logic outside the frontend.
Amazon DynamoDB
DynamoDB stores shared request state. This gives different parts of the system a common place to access the state associated with a request.
Amazon S3
S3 provides storage for private media and the inference mailbox. Separating these objects from the application's request state gives the system a dedicated place for media and related artifacts.
3. Real-time voice AI
Amazon Bedrock — Amazon Nova 2.5 Sonic
The voice experience uses Nova 2.5 Sonic for streaming audio interaction. Kiara listens to Hindi speech and responds with generated speech, making voice the primary interaction mechanism rather than an additional feature bolted onto a conventional form-based interface.
The architecture connects the browser experience to the voice service through a bidirectional audio stream. Tool results are then returned to the application through its API workflow.
4. Identity and temporary access
AWS Security Token Service (AWS STS)
The design uses temporary voice credentials with a 15-minute lifetime. Lambda coordinates the credential workflow, allowing access to be time-bound instead of relying on long-lived credentials in the browser.
AWS Identity and Access Management (IAM)
IAM defines scoped roles and model access. This creates a boundary between the permissions needed by the application and the permissions available to individual components.
5. Operations and cleanup
Amazon EventBridge
EventBridge triggers hourly cleanup, helping automate recurring maintenance rather than requiring manual intervention.
Amazon CloudWatch Logs
CloudWatch captures Lambda execution diagnostics. The architecture specifies a three-day retention period for these logs, keeping operational visibility while limiting how long diagnostic records are retained.
What fought back: The engineering challenges
The most interesting part of this project was bringing the different pieces together. A working voice model alone doesn't solve the problems involved in building a dependable application around it.
1. Making voice interaction work with real application actions
A conversational assistant can understand a request and generate a response, but an application must still decide what action is appropriate, execute it, and communicate the result.
Parali's workflow connects voice interactions with crop-detail capture and a permission-to-map-to-confirmation sequence. This means the conversational layer and the application layer need to agree on the current request and its next step.
The lesson: Voice AI is most useful when it is connected to a clearly defined workflow, rather than being treated as the entire product.
2. Handling temporary credentials and permissions
Browser-based voice applications introduce a practical security challenge: the browser needs access to the functionality it uses, but that doesn't mean it should have unrestricted access to backend resources.
The architecture separates IAM permissions, Lambda orchestration, and temporary STS credentials. The 15-minute credential lifetime is part of that design.
Getting this boundary right is important because a system that works in a local prototype can still be poorly designed from a security perspective.
The lesson: Authentication, authorization, and credential lifetimes need to be considered as part of the product architecture, not added as an afterthought.
3. Keeping request state consistent across services
The frontend, backend, and voice interaction don't necessarily progress at the same pace. Requests need a shared state, and asynchronous operations need to be coordinated.
DynamoDB provides shared request state, while S3 handles private media and inference-related objects. Lambda coordinates the workflow, and API Gateway provides the application's HTTPS interface.
These responsibilities need to remain distinct; otherwise, debugging a failed operation can become difficult.
The lesson: Defining what belongs in application state, what belongs in object storage, and what belongs in backend orchestration makes the system easier to reason about.
4. Designing for cleanup and operational visibility
A prototype that works during a demonstration isn't automatically ready for ongoing use. Temporary data, failed executions, and debugging information all need a lifecycle.
EventBridge provides the scheduled cleanup trigger, and CloudWatch Logs provides execution diagnostics with a configured three-day retention period.
These are relatively small architectural details, but they matter when moving from a demo toward a service that can be operated responsibly.
The lesson: Maintenance and observability should be part of the first architecture, even when the application is still experimental.
What I learned
Building Parali reinforced three ideas for me.
First, the model is only one component of an AI product. The surrounding system determines how the model interacts with real users, application state, and external services.
Second, a natural interface still needs explicit guardrails. Voice can make an application easier to approach, but important actions still need controlled permissions and clear confirmation steps.
Finally, cloud architecture is about assigning responsibilities. Amplify serves the web experience, API Gateway exposes application routes, Lambda coordinates execution, DynamoDB maintains shared request state, S3 stores private objects, and IAM and STS govern access. Each service has a defined role rather than being included just to make the stack look more sophisticated.
What's next?
The next stage is to evaluate the experience beyond a successful demonstration: test the voice workflow under different network conditions, validate permission boundaries, verify cleanup behaviour, and measure how reliably users can complete the intended tasks.
I would also like to test the interface with actual users and identify where Hindi speech recognition, confirmation steps, or the overall workflow create friction.
Those results should guide the next iteration instead of assuming that adding more AI will automatically make the product better.
Try it yourself
Parali is a practical experiment in connecting conversational AI with application workflows on AWS.
The biggest takeaway from this build is simple: making an AI application useful requires more than choosing a capable model. It requires thoughtful orchestration, secure access, reliable state management, and a user experience designed around the people who will actually use it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article