Inspiration

Shop-floor breakdown reporting is often slow, incomplete and difficult to trace. Operators typically call someone or fill in a form, technicians arrive without enough context, and incident closures are rarely documented. This leaves teams without a reliable timeline, supporting evidence or a systematic way to learn from root causes. We built Hiberus Triage Agent to bring the entire incident lifecycle into the communication channels that operators, technicians and supervisors already use: WhatsApp and email.

What it does

Hiberus Triage Agent is a WhatsApp-first AI agent that manages an industrial incident from the operator’s first message to final closure. An operator reports a breakdown through WhatsApp using free text and, optionally, a photo. The agent identifies the relevant machine, asks clarifying questions when necessary and follows the appropriate diagnostic playbook. A multimodal model analyses the available evidence and refines the initial hypothesis. When the issue can probably be resolved by the operator, the agent presents step-by-step guidance through a WhatsApp carousel. Selecting “Fixed” automatically resolves the incident. If technical intervention is required, the agent:

  • Creates the incident.
  • Registers the diagnosis.
  • Classifies its type and severity.
  • Assigns an available technician.
  • Tracks whether the technician accepts or rejects it.
  • Reassigns the incident when an acceptance timeout occurs.
  • Escalates high- and critical-severity incidents.
  • Records the resolution and closes the incident.

At closure, the operator receives confirmation through WhatsApp, including the identified root cause. The supervisor receives an email containing the complete incident timeline, evidence and a comparison between the agent’s initial hypothesis and the actual root cause. A secure dashboard gives supervisors and technicians access to open incidents, assignment and resolution times, escalations, machines, technicians, incident evidence and the complete agent execution context.

How we built it

The agent was built with Strands Agents and runs on Amazon Bedrock AgentCore Runtime. AgentCore Memory preserves context for 90 days, allowing operators, technicians and supervisors to interact with the same incident from separate conversations. The solution uses Claude Sonnet 4.5 through Amazon Bedrock and is protected by Bedrock Guardrails. Eleven operational tools are exposed through MCP using Amazon Bedrock AgentCore Gateway. These tools allow the agent to find machines and playbooks, retrieve incident history, create tickets, register diagnoses, assign technicians, escalate incidents, close or automatically resolve them, generate evidence URLs and attach evidence. AWS End User Messaging Social provides the WhatsApp channel. Incoming events travel through Amazon SNS and Amazon SQS before reaching an ingestion Lambda. Photos are retrieved using the AWS social messaging API and stored in an encrypted Amazon S3 bucket. A central notifier Lambda sends WhatsApp messages, interactive Flows and carousel templates. The same component uses Amazon SES to send escalation and closure reports to supervisors. Amazon DynamoDB Streams, AWS Lambda and AWS Step Functions coordinate automatic reassignment and escalation timers. The dashboard is hosted in a private Amazon S3 bucket behind Amazon CloudFront. Its API uses Amazon API Gateway, Amazon Cognito and role-based authorization. The complete serverless infrastructure is defined in seven AWS CDK stacks written in Python.

Challenges

The main technical challenge was making an AI agent with real operational side effects safe behind an at-least-once messaging queue. Because the same message can be delivered more than once, ingestion had to be idempotent to prevent duplicate incidents or repeated actions. Another challenge was maintaining a coherent conversation for the same incident across multiple people and channels, while preserving the complete timeline and agent context. We also had to design dynamic WhatsApp Flows and carousels that the agent could populate for each incident, while providing a plain-text fallback whenever an interactive template was unavailable.

What we learned

We learned that an operational agent must do more than produce a plausible answer. Every action must be traceable, idempotent, authorised and observable. We also learned that comparing an AI-generated diagnosis with the confirmed root cause creates a valuable feedback signal. Each closed incident can be used to measure diagnostic quality and progressively improve the maintenance playbooks.

What’s next

The next steps are:

  • Adding SMS as a third communication channel.
  • Integrating technician shift calendars into the assignment process.
  • Using hypothesis-versus-root-cause data to improve diagnostic playbooks automatically.

Built With

  • agentic-ai
  • amazon-api-gateway
  • amazon-bedrock
  • amazon-bedrock-agentcore
  • amazon-cloudfront
  • amazon-cognito
  • amazon-dynamodb
  • amazon-ses
  • amazon-sns
  • amazon-sqs
  • amazon-web-services
  • aws-cdk
  • aws-end-user-messaging-social
  • aws-kms
  • aws-lambda
  • aws-step-functions
  • claude-sonnet-4.5
  • conversational-ai
  • generative-ai
  • mcp
  • multimodal-ai
  • python
  • serverless
  • strands-agents
  • whatsapp
Share this project:

Updates

Submission history