Small Voice Agent

Turns small frontline workplace concerns into structured, reviewable improvement signals — while keeping the final decision with people.

Comment

Inspiration

Small workplace problems are often noticed first by the people closest to the task.

But many of these observations never become formal reports. An awkward reach may be repeated throughout the day. Two experienced workers may teach the same task differently. A temporary workaround may quietly become normal because the work still gets finished.

These are not always major incidents, but they may contain useful knowledge about safety, quality, workload, and how work is actually done.

I built Small Voice Agent to help people capture these small voices before they disappear. The goal is not to let AI decide what is correct. The goal is to make an overlooked concern visible, organize it into something reviewable, and return the final judgment to people.

What it does

A worker or reviewer enters a short workplace concern and optional context through a public web interface.

Small Voice Agent then:

  1. validates and records the report;
  2. gives it a durable report ID;
  3. queues the work asynchronously;
  4. uses a Strands Agents SDK Agent backed by Amazon Bedrock and Amazon Nova Lite;
  5. organizes the concern into a practical proposal;
  6. stores the result, model ID, timestamps, and processing state in DynamoDB;
  7. returns a clear DONE or FAILED status to the web interface; and
  8. displays “Human review required” so the AI output is never mistaken for a final workplace decision.

The system is designed for small concerns that are easy to overlook but may become meaningful when they are recorded and reviewed.

How we built it

The public interface is hosted with AWS Amplify Hosting and sends reports through Amazon API Gateway.

A submit Lambda validates the input, creates a report in Amazon DynamoDB, and sends a message to Amazon SQS. SQS invokes SmallVoiceWorkerFunction asynchronously.

Inside the worker, I use the Strands Agents SDK to create an Agent backed by BedrockModel. The model is configured as amazon.nova-lite-v1:0 in the Tokyo Region. The Agent turns the report into a structured, reviewable Japanese proposal.

The worker then stores:

  • agent_result_text;
  • bedrock_model;
  • processing_status;
  • worker_started_at; and
  • worker_finished_at.

A status Lambda reads the durable DynamoDB record and returns it to the web interface. The interface continues polling until processing reaches DONE or FAILED.

The processing lifecycle is:

QUEUED → PROCESSING → DONE / FAILED

The Strands update was deliberately minimal. The existing public URL, API contract, SQS workflow, DynamoDB table, status polling, and human-review boundary were preserved while the worker’s direct model invocation was replaced with an actual Strands Agent invocation.

Architecture

AWS Amplify → API Gateway → Submit Lambda → DynamoDB → Amazon SQS → SmallVoiceWorkerFunction (Strands Agents SDK) → Amazon Bedrock / Amazon Nova Lite → DynamoDB → Status Lambda → Web UI

Amazon CloudWatch provides runtime logs and processing evidence. Failed SQS messages retain the existing retry and dead-letter queue path.

Why this is more than a chatbot

Small Voice Agent does not simply return text from one synchronous prompt.

It performs a stateful task across multiple AWS services. A report is accepted, assigned an ID, stored, queued, processed by an Agent, written back to durable storage, and returned to the user only after completion is confirmed.

The interface does not treat “submitted” as “complete.” Completion is shown only when DynamoDB confirms processing_status = DONE.

This creates a traceable workflow that can be reviewed by people instead of presenting an AI response as an unverified answer.

Human review boundary

Small Voice Agent does not automatically:

  • change workplace rules;
  • rewrite standard operating procedures;
  • rank workers;
  • score productivity;
  • determine disciplinary action;
  • make medical or safety diagnoses; or
  • treat an AI proposal as the final answer.

The Agent helps organize the concern and suggest a proportionate first step. A person decides whether to act, revise, investigate, or close it.

Challenges we ran into

One challenge was making asynchronous completion understandable to the user. Receiving a report ID only proves that a request was accepted; it does not prove that Agent processing finished successfully.

To address this, I used durable processing states in DynamoDB and made the frontend wait for DONE or FAILED. The completed screen displays the report ID, model used, Agent result, and the message “Human review required.”

Another challenge was adding Strands without unnecessarily rebuilding a working AWS pipeline. I kept the established SQS, DynamoDB, API, and frontend contracts and limited the change to the worker layer.

As a non-engineer, I also learned that a useful AI response is only one part of a dependable system. Queue state, durable records, retries, failure handling, completion signals, and human responsibility are equally important.

Accomplishments that we’re proud of

  • Built and deployed a public AWS application.
  • Implemented a real Strands Agents SDK Agent inside the Worker Lambda.
  • Preserved asynchronous processing with Amazon SQS.
  • Stored durable results and processing evidence in DynamoDB.
  • Made successful and failed completion states visible to users.
  • Kept the final decision explicitly with a human reviewer.
  • Verified the live pipeline with multiple workplace scenarios.
  • Confirmed that the main SQS queue and dead-letter queue returned to zero visible messages after successful processing.

Live verification

The following pipeline was verified end to end:

Amplify → API Gateway → Submit Lambda → SQS → Strands Worker → Bedrock / Nova Lite → DynamoDB → Status Lambda → Web UI

Three scenarios were tested:

  1. two experienced workers teaching the same task differently;
  2. a repeated reach across a workbench causing shoulder fatigue; and
  3. temporary use of another shelf when the normal storage area is full.

All three reached DONE and returned a reviewable Agent result.

What we learned

The most important lesson was that AI should not erase differences in workplace experience.

When two experienced people use different methods, the useful first step is not always to choose a winner. It may be better to clarify the differences, understand the conditions behind each method, and examine possible effects on safety, quality, time, and physical burden.

AI can add another perspective and help organize that discussion. It should not replace the people who understand the work.

What’s next for Small Voice Agent

Possible next steps include:

  • reviewer feedback on Agent proposals;
  • grouping repeated concerns while preserving local context;
  • comparing recurring patterns over time;
  • measuring whether proposed changes lead to safe, reversible improvements; and
  • improving multilingual support for frontline teams.

The long-term goal is to help small workplace observations become shared improvement knowledge without turning the system into a top-down employee evaluation tool.

Try it

Live application: https://main.dsof2wtaq9pwf.amplifyapp.com/

Public source repository: https://github.com/genba-daiichi-ai/small-voice-agent

Built With

Share this project:

Updates

Submission history