Inspiration
Enterprise service operations are still highly fragmented. An IoT platform may detect an equipment anomaly, a customer may report an outage through a contact channel, and a CRM or field-service platform may hold the service record - but converting that first signal into a successful resolution often requires a chain of manual handoffs. Teams still need to diagnose the issue, validate entitlement, identify parts, find the right technician, schedule service, communicate with the customer, and react when the original plan changes. We were inspired by a simple question: what if service operations could move from reacting to tickets to owning the resolution outcome? That led us to Agentic OpsResolve - a cross-industry service-resolution solution that combines IoT-driven sensing, grounded Agentic AI, enterprise transaction orchestration, and AWS Communication Developer Services (CDS). Instead of using communication channels only to send alerts, we designed AWS CDS as a conversational service-resolution fabric where customers, technicians, service managers, and AI agents can collaborate throughout the complete service journey.
What it does
Agentic OpsResolve manages a service case end-to-end using a simple operating model: Sense. Diagnose. Resolve. Recover. Sense - Captures IoT telemetry, predictive alerts, customer messages, work-order events, and enterprise signals, then builds a context-rich service case with customer, asset, contract, SLA, and service-history information. Diagnose - Specialist AI agents correlate telemetry, asset history, previous incidents, validated manuals, and service bulletins to identify the likely issue and recommend the safest next action. Resolve - The agentic layer coordinates entitlement checks, parts identification, technician matching, scheduling, dispatch, work-order updates, and customer consent across existing enterprise systems. Recover - After a resolution is committed, Agentic OpsResolve continues monitoring the journey. If a technician is delayed, a part becomes unavailable, or another condition threatens the service commitment, the solution can detect the risk early and re-plan before customer impact or an SLA breach occurs. Customers participate directly through channels such as WhatsApp, SMS, RCS, and email. This turns communication from a one-way notification step into an active part of diagnosis, approval, booking, recovery, and closure. For the hackathon, we built and demonstrated Industrial Equipment and Telecom scenarios. The same shared agentic core is designed to extend through industry packs to Medical Devices, Utilities, HVAC and Buildings, Automotive, Consumer Durables, and Critical Infrastructure.
How we built it
We designed Agentic OpsResolve as a reusable, governed agentic architecture rather than a standalone chatbot or ticketing automation. At its center is a Service Resolution Orchestrator supported by ten specialist agents covering asset context, diagnosis, enterprise knowledge, SLA and entitlement, parts, technician matching, scheduling and dispatch, communications, service recovery, and completion. Amazon Bedrock AgentCore provides the agent foundation for runtime, memory, tool access, identity, observability, and evaluation. AgentCore Gateway provides governed access to enterprise tools and systems. Amazon Bedrock Knowledge Bases ground diagnosis in validated enterprise knowledge, while Bedrock Guardrails, Cedar-based policy controls, and human checkpoints constrain autonomous actions according to business risk and authority. Connected assets can publish telemetry through AWS IoT Core. Those signals, together with customer and enterprise events, are converted into service cases and passed to the orchestrator. The agents reason over the case and use governed tools to interact with existing CRM, ERP, EAM, inventory, and field-service platforms. We embedded AWS Communication Developer Services directly into the resolution workflow: WhatsApp for conversational support, guided resolution, consent, and in-chat booking. SMS for urgent alerts, short updates, and approvals. RCS for richer interactive service experiences where supported. Amazon SES for formal and auditable communications such as confirmations, service reports, and completion records. A key design principle guided the implementation: Agents reason. Enterprise systems transact. Policy governs. Humans remain in control where it matters. This allowed us to add agentic intelligence without asking enterprises to replace their existing systems of record. We also separated the solution into a shared agentic core + Industry Pack model. The orchestration, policies, communication mechanisms, observability, and recovery patterns remain reusable, while industry-specific data, knowledge, thresholds, message templates, and connectors can be packaged independently.
Challenges we ran into
The hardest part was not generating an answer - it was coordinating an end-to-end resolution journey across signals, AI reasoning, people, communication channels, and transactional systems. Moving beyond alerts and chat: We had to make communications actionable. A customer conversation needed to trigger real workflow steps such as consent, scheduling, service updates, and recovery rather than remain a disconnected chat. Balancing autonomy with enterprise control: Service operations can affect customers, assets, costs, and contractual commitments. We therefore designed bounded autonomy with policy controls, governed tool access, and human checkpoints instead of giving agents unrestricted execution rights. Handling the unhappy path: A service journey rarely stays static. Technician delays, part shortages, changing availability, and emerging SLA risk required us to treat recovery as a first-class agentic capability rather than a manual exception process. Regional availability of RCS and SMS: Messaging capabilities varied by geography, carrier, and service provider. This made it challenging to design and demonstrate a consistent end-to-end experience across all intended regions and channels. Building for reuse under hackathon constraints: We focused the working demonstration on Industrial Equipment and Telecom, while keeping the architecture modular enough to extend through industry packs instead of hard-coding the solution for only two use cases.
Accomplishments that we're proud of
We are proud that OpsResolve is more than a conversational front end. It demonstrates how AWS services can be combined into a closed-loop service-resolution system that can sense, reason, act, communicate, recover, and verify completion. We turned AWS CDS from a notification layer into a conversational service-resolution fabric embedded in the workflow. We connected IoT-driven proactive sensing with Agentic AI so a service journey can begin before the customer reports a failure. We implemented a multi-agent resolution model with a central orchestrator and ten specialist capabilities. We treated proactive recovery as a differentiator - not only automating the happy path, but detecting risk and re-planning after a commitment has already been made. We demonstrated the solution for Industrial Equipment and Telecom while establishing a reusable shared core for cross-industry expansion. We aligned the solution to measurable service outcomes such as remote-resolution rate, first-time-fix rate, mean time to resolution, technician productivity, parts accuracy, SLA performance, cost per service order, and customer satisfaction.
What we learned
Building OpsResolve reinforced several important lessons about enterprise Agentic AI. Communication is part of orchestration, not an afterthought. When customers can approve, respond, choose a slot, receive recovery options, and confirm closure in the same conversational flow, the channel becomes part of the operating model. Resolution requires continuity of context. Diagnosis alone is not enough. The agentic layer must carry context from the first signal through entitlement, parts, scheduling, execution, recovery, and verified closure. The real test of autonomy is the exception path. Proactive recovery, what happens when a part is unavailable, a technician is delayed, or an SLA is at risk, is where agentic orchestration can create significant operational value. Governance has to be architectural. Identity, policy, tool access, guardrails, observability, evaluation, and human checkpoints cannot be added later if agents are expected to interact with enterprise systems. Reusable patterns matter more than one-off demos. Separating the shared agentic core from industry-specific packs makes it possible to scale the same resolution pattern across multiple service-intensive industries.
What's next for Agentic OpsResolve
Our next step is to evolve OpsResolve from the two hackathon scenarios into a broader reusable service-resolution platform. Expand Industry Packs for Medical Devices, Utilities, HVAC and Buildings, Automotive, Consumer Durables, and Critical Infrastructure. Broaden enterprise connectors across CRM, ERP, EAM, inventory, contact-center, and field-service ecosystems so the agentic layer can be adopted without disrupting systems of record. Deepen proactive service by using richer IoT and operational signals to identify emerging failures and service risks earlier. Strengthen evaluation and observability so enterprises can measure agent decisions, tool usage, policy compliance, recovery effectiveness, and business outcomes. Validate value against customer baselines using operational KPIs such as MTTR, remote resolution, first-time-fix, SLA performance, contact reduction, technician productivity, and cost per service order. The long-term vision is straightforward: move enterprise service operations from customer reports failure -> enterprise reacts to asset or customer signal -> AI diagnoses -> service is orchestrated -> customer is engaged -> risk is recovered -> outcome is verified. With Agentic OpsResolve, the goal is not simply to automate tickets or generate recommendations. The goal is to create a governed agentic layer that can own the resolution outcome - sensing earlier, diagnosing with evidence, resolving intelligently, recovering proactively, and closing with proof.
Built With
- amazon-api-gateway
- amazon-bedrock
- amazon-bedrock-agentcore
- amazon-bedrock-guardrails
- amazon-bedrock-knowledge-bases
- amazon-cloudfront
- amazon-cognito
- amazon-dynamodb
- amazon-eventbridge
- amazon-eventbridge-scheduler
- amazon-opensearch-serverless
- amazon-ses
- amazon-sns
- amazon-web-services
- anthropic-claude
- aws-cdk
- aws-communication-developer-services-(cds)
- aws-end-user-messaging-sms-(sms-&-rcs)
- aws-end-user-messaging-social-(whatsapp)
- aws-iot-core
- aws-lambda
- cedar
- model-context-protocol-(mcp)
- strands-agents-sdk
Log in or sign up for Devpost to join the conversation.