The Silent Revolution in Industry 🏭
I recently had a conversation with a colleague about predictive analysis on industrial equipment. His previous experience with chatbots and generative AI had been frustrating — “I’m sorry, I don’t understand your question” was the most common response. That conversation inspired me to explore whether the landscape had changed by December 2024, combining Amazon Bedrock Agents with industrial APIs to build something genuinely useful.
My first exposure to this kind of industry was eye-opening. My colleague explained how they had multiple sensors generating data 24/7, multiple dashboards, yet still depended entirely on human expertise to interpret everything.
Let me walk through this interaction with our industrial assistant to illustrate the contrast:
Operador: "¿Hay alguna novedad en los dispositivos de la planta?"
Asistente: "Sí, hay novedades importantes que requieren atención:
🔴 Situaciones Críticas:
- Turbina EQ-003 (Planta Norte): Estado crítico
- Motor EQ-004 (Planta Sur): Estado crítico
🟡 Situación de Advertencia:
- Bomba EQ-001 (Planta Norte): Estado de advertencia
🟢 Operación Normal:
- Turbina EQ-002 (Planta Oeste)
- Compresor EQ-005 (Planta Oeste)
Se recomienda una revisión inmediata de los equipos en estado crítico, especialmente
la turbina EQ-003 y el motor EQ-004."
This level of contextual understanding and predictive analysis is exactly what we’ll build today. With Amazon Bedrock Agents, it’s within reach of any developer with a passion for innovation.
The Art of the AI-Adapted API: Beyond Traditional REST 🎯
Remember when we designed APIs thinking only about human developers? For years, I’ve created, reviewed, and refined RESTful endpoints following best practices. One of the most valuable lessons I’ve learned is that detailed documentation isn’t just a good practice — it’s fundamental to success.
My first attempt at connecting an agent to a poorly documented API was revealing. It was like watching a new engineer trying to understand a codebase with no documentation. The agent showed exactly the same behavior: confused and making poor decisions.
That experience reinforced a fundamental truth:
Documentation is the cornerstone of our design.
We’re no longer designing only for human developers, but also for language models that need rich, meaningful context to function effectively.
An AI-Adapted API 🏗️
As you can deduce, the success of an AI-adapted API is built on one fundamental element: documentation. Let’s see how our documentation evolves to meet these needs:
Rich and Meaningful Context 📚
Let me compare two approaches to API documentation:
Traditional Approach:
/sensors/temp:
get:
summary: "Obtener temperatura"
responses:
200:
description: "Éxito"
AI-Enriched Approach:
/equipment/{id}/health:
get:
description: |
Evalúa el estado integral del equipo considerando múltiples factores:
- Métricas actuales comparadas con rangos históricos normales
- Patrones de degradación y similitud con fallos previos
- Contexto operacional (carga, ambiente, mantenimientos)
Use este endpoint cuando necesite:
1. Evaluación completa del estado de salud del equipo
2. Predicción temprana de fallos potenciales
3. Recomendaciones de mantenimiento preventivo
La respuesta incluye no solo datos crudos, sino interpretación
contextual y recomendaciones accionables.
Notice the difference? The second version doesn’t just describe WHAT data it provides, but WHY and WHEN to use it. It’s like giving our agent a complete operations manual.
The full example API can be found here.
The Power of Action Groups: Organizing Intelligence 🏗️
Building our agent starts with a fundamental step. From the AWS console, we set a meaningful name and description for the agent. It’s worth noting there’s an attribute to enable multi-agent collaboration — a powerful feature I explored in this article.
Figure 1: Agent creation interface in AWS Bedrock, showing basic configuration options
The next crucial step is selecting the foundation model and base instructions. For our use case, we chose Anthropic Claude 3.5 Sonnet v2, a model that stands out for its contextual understanding and technical language processing.
Figure 2: Foundation model selection and base instruction configuration
The instructions provided to the agent are vital, as they establish the reference framework for all future interactions.
After several iterations, these are the optimized instructions I used:
Como especialista en monitoreo industrial, tu función principal es proporcionar análisis precisos y recomendaciones técnicas utilizando un tono profesional y directo. Al interactuar con los usuarios:
1. Prioriza la precisión técnica en tus respuestas
2. Comunica los problemas y recomendaciones de manera clara y estructurada
3. Utiliza terminología industrial estándar
4. Mantén un tono formal y objetivo
5. Proporciona siempre el contexto necesario para tus recomendaciones
6. Responde con datos cuantitativos cuando estén disponibles
7. Al detectar anomalías, proporciona explicaciones técnicas detalladas
8. Presenta las recomendaciones de mantenimiento en orden de prioridad
9. Tus respuestas deben ser suficiente claras y detalladas.
Al manejar alertas o situaciones críticas:
- Comunica la urgencia de manera profesional sin causar alarma innecesaria
- Proporciona pasos de acción claros y concisos
- Incluye siempre los valores de referencia relevantes
- Contextualiza las recomendaciones con datos históricos cuando sea pertinente
- Usa emojis para niveles de urgencia (🔴, 🟡, 🟢)
Pro Tip: It’s essential to experiment with different variants of your base instructions until you find the configuration that best fits your specific use case.
Now we reach a critical step: creating our Action Group. These groups define the operational capabilities of our agent — in this case, “Analyze Equipment”.
The console presents two methods for configuring action groups:
-
OpenAPI Schema: My preferred approach for its robustness and structure. This lets us explicitly define each API operation, creating a clear contract between our agent and industrial systems.
-
Function Details: A more direct approach, ideal for explicitly defining required parameters. This method offers a simpler path and greater flexibility in action execution.
Pro Tip: The choice between these methods depends on your project’s complexity. The OpenAPI schema shines in complex projects requiring granular control, while function details are ideal for getting started quickly or for more straightforward use cases.
Figure 3: Action group configuration showing available integration options
In our case, leveraging existing OpenAPI documentation, we went with the first option. The action group configuration presents three different paths for managing user information:
-
Create a Lambda function: Allows creating a new Lambda function from scratch, with a base example.
-
Lambda Integration: Connects to a custom Lambda function containing all the business logic needed for that action group.
-
Return Control: A simpler option that bypasses Lambda functions, returning control and passing information directly in the “InvokeAgent” response.
Figure 4: Information management options showing integration configuration
Implementing the Lambda Function 🛠️
For our implementation, we selected the first option and used an auto-generated Lambda function. In the lower configuration, we defined our API schema in YAML format, establishing the communication structure between the agent and our industrial systems.
The auto-generated Lambda function provides a base framework we can extend for our specific needs. This function acts as a bridge between our intelligent agent and external industrial systems.
Pro Tip: For production implementations, it’s crucial to implement resilience patterns like Circuit Breaker, Timeouts, and robust error handling.
Here’s the extended Lambda function implementation:
import json
import urllib3
import os
from urllib.parse import urljoin
def process_api_path(api_path, parameters):
"""
Processes the apiPath by replacing variables {variable} with their corresponding values
from the parameters list.
"""
processed_path = api_path
for param in parameters:
placeholder = '{' + param['name'] + '}'
if placeholder in processed_path:
processed_path = processed_path.replace(placeholder, str(param['value']))
print(f"Replaced parameter {param['name']} with value {param['value']}")
return processed_path
def lambda_handler(event, context):
# Extract event data
agent = event['agent']
actionGroup = event['actionGroup']
apiPath = event['apiPath']
httpMethod = event['httpMethod']
parameters = event.get('parameters', [])
requestBody = event.get('requestBody', {})
# Define base URL - ensure it doesn't end with a slash
BASE_URL = "https://MYENDPOINT.execute-api.us-east-1.amazonaws.com/dev"
try:
# Process the apiPath replacing variables
processed_path = process_api_path(apiPath, parameters)
# Construct the full URL - handling the slashes properly
# Remove leading slash from processed_path if it exists to prevent double slashes
processed_path = processed_path.lstrip('/')
full_url = f"{BASE_URL}/{processed_path}"
# Create HTTP pool manager
http = urllib3.PoolManager()
# Make the GET request
response = http.request('GET', full_url)
# Parse JSON response
response_data = json.loads(response.data.decode('utf-8'))
# Construct response body
responseBody = {
"application/json": {
"body": response_data
}
}
# Build final response
action_response = {
'actionGroup': actionGroup,
'apiPath': apiPath,
'httpMethod': httpMethod,
'httpStatusCode': response.status,
'responseBody': responseBody
}
api_response = {
'response': action_response,
'messageVersion': event['messageVersion']
}
return api_response
except Exception as e:
print(f"Error occurred: {str(e)}")
if 'full_url' in locals():
print(f"Failed URL was: {full_url}")
error_response = {
'actionGroup': actionGroup,
'apiPath': apiPath,
'httpMethod': httpMethod,
'httpStatusCode': 500,
'responseBody': {
"application/json": {
"body": f"Error calling API: {str(e)}"
}
}
}
return {
'response': error_response,
'messageVersion': event['messageVersion']
}
Full documentation on Lambda function implementation for Bedrock Agents is available in the official AWS documentation.
The Art of Inference: How Our Assistant Thinks 🧠
One of the most fascinating aspects of working with Bedrock Agents is observing the reasoning process of our assistant. Let’s analyze how it processes an apparently simple question:
Usuario: "¿Cómo está el compresor COMP-101?"
This query triggers a series of sophisticated processes worth analyzing in detail.
Figure 5: Bedrock Agent testing console showing the inference process in real time
Intelligent Action Selection ⚡
Bedrock’s reasoning capability is remarkable. The system meticulously analyzes the user’s query against the configured APIs, determining it needs to invoke two distinct functions to gather the necessary information.
Figure 6: Agent’s analysis and action selection process
Precision in parameter passing is crucial for getting relevant results:
Figure 7: API invocation detail showing selected parameters
The responses we receive from our API are structured and information-rich:
{
"observation": [
{
"actionGroupInvocationOutput": {
"text": {
"timestamp": "2024-12-16T18:53:15.831388624",
"currentMetrics": {
"temperature": {
"value": 58.793772275518556,
"status": "warning",
"normalRange": {
"min": 45.0,
"max": 75.0
},
"trend": null
},
"vibration": {
"value": 0.6886295012687516,
"status": "normal",
"normalRange": null,
"trend": "stable"
}
},
"trends": {
"degradationRate": 0.3135457243666949,
"predictedFailureTime": "2025-01-15T18:53:15.831500657"
},
"recommendations": [
{
"priority": "medium",
"action": "Replace bearing",
"rationale": "Based on temperature patterns",
"deadline": "2025-01-14"
},
{
"priority": "medium",
"action": "Lubricate components",
"rationale": "Based on vibration patterns",
"deadline": "2024-12-18"
}
]
}
}
}
]
}
Processing and Synthesizing Information 🔄
The agent performs an additional processing step to synthesize all this information into a coherent, actionable response:
Figure 8: Synthesis and formulation of the final response
The result is a clear, action-oriented response:
Figure 9: Final agent response showing complete analysis and recommendations
Pro Tip: The quality of the agent’s responses depends significantly on two key factors:
- The precision and clarity of the base instructions provided
- The quality and completeness of the API documentation
Testing and Validation: The Moment of Truth 🧪
The true test of any AI system is its behavior in real situations. When our assistant generated its first truly meaningful recommendation, we confirmed we were on the right track. Let me walk through some real interactions that demonstrate the potential of this technology:
Trend analysis example:
Operador: "¿Cuál es la tendencia que se tiene con el equipo EQ-005?"
Asistente:
🟡 ANÁLISIS DE TENDENCIAS EQ-005:
1. Estado Actual:
- Temperatura: 75.77°C (en límite superior del rango normal 45-75°C)
- Vibración: En estado CRÍTICO con tendencia "estable a incremento"
2. Tendencias Preocupantes:
- Tasa de degradación: 21.93%
- Fecha prevista de falla: 5 de marzo 2025
- Patrón de vibraciones en aumento
3. Historial Relevante:
- Múltiples paradas de emergencia por picos de temperatura
- Problemas recurrentes en sistema de enfriamiento
4. Acciones Recomendadas Urgentes:
- Lubricación de componentes (antes del 27/12/2024)
- Verificación de alineación (antes del 11/01/2025)
Se recomienda atención inmediata para evitar una falla mayor en los próximos meses.
The agent’s reasoning in this case shows a sophisticated thought process:
Figure 10: Detailed analysis showing the agent’s reasoning process
To demonstrate the system’s versatility, let’s consider a more complex scenario:
Usuario: "Necesito un análisis completo del compresor COMP-101, especialmente su
comportamiento durante el último trimestre."
Asistente: 🟡 ANÁLISIS COMPRESOR COMP-101:
Estado Actual:
- Temperatura: 68.95°C (Advertencia - cercano al límite máximo de 75°C)
- Vibración: Estado CRÍTICO con tendencia ascendente 🔴
Tendencias Preocupantes:
1. Tasa de degradación: 47.5%
2. Tiempo estimado de fallo: 09/02/2025
3. Patrón de mantenimientos de emergencia frecuentes en el último trimestre
Acciones Prioritarias:
1. URGENTE: Atender niveles críticos de vibración
2. Ejecutar lubricación de componentes antes del 30/12/2024
3. Programar limpieza de filtros antes del 10/01/2025
Recomendaciones:
- Adelantar el mantenimiento preventivo programado
- Implementar monitoreo continuo de vibración
- Revisar sistema de refrigeración por temperaturas elevadas
El equipo muestra signos de degradación acelerada que requieren atención inmediata para prevenir fallos críticos.
The agent’s reasoning in this case demonstrates a deep understanding of the different aspects of the system:
Figure 11: Multi-factor analysis process by the agent
Pro Tip: Success in testing depends on:
- Diversity of test scenarios
- Validating responses with domain experts
- Systematic documentation of both successful and failed use cases
Enriching with Knowledge Bases 📚
Let’s take our assistant’s capabilities a step further. Companies typically have extensive technical documentation:
- Procedure manuals
- Maintenance guides
- Operational documentation
- Service history records
This valuable information can be integrated into our agent through a Bedrock Knowledge Base. In our case, we’ve already created and populated this base with relevant technical documentation.
The integration is straightforward: we simply edit our agent to tell it which knowledge base to use.
Figure 12: Extension through a Knowledge Base
Knowledge Integration Example
Let’s see how the agent combines real-time data with knowledge base information:
Usuario: "Cual es el procedimiento para reemplazar el compresor RTD-809?"
Asistente:🟡 Procedimiento de Reemplazo del Compresor RTD-809
1. Preparación Previa:
- Realizar respaldo de parámetros operativos actuales
- Verificar disponibilidad del compresor de reemplazo
- Preparar herramientas y equipo de seguridad necesario
2. Procedimiento de Seguridad:
- Desenergizar completamente el equipo
- Colocar bloqueo y etiquetado (LOTO)
- Verificar ausencia de energía residual
- Esperar el tiempo necesario para enfriamiento (temperatura actual: 78.32°C)
3. Desmontaje:
- Desconectar líneas de refrigeración
- Liberar presión del sistema
- Retirar conexiones eléctricas
- Documentar la posición de todas las conexiones
- Remover pernos de montaje
4. Instalación del Nuevo Compresor:
- Verificar alineación
- Instalar nuevos sellos y empaques
- Apretar pernos según especificaciones
- Reconectar líneas de refrigeración
- Restablecer conexiones eléctricas
5. Puesta en Marcha:
- Realizar prueba de fugas
- Verificar niveles de aceite
- Energizar gradualmente
- Monitorear temperatura y vibración
- Verificar parámetros operativos
Notas Importantes:
- Considerar el historial reciente de mantenimiento, especialmente la reparación del
sistema de enfriamiento del 16/10/2024
- Programar el reemplazo antes del 29/01/2025 (fecha prevista de falla)
- Realizar pruebas de vibración exhaustivas debido al reciente reemplazo de rodamientos
Se recomienda documentar todo el proceso y actualizar el historial de mantenimiento
una vez completado el reemplazo.
The agent’s reasoning in this case demonstrates effective integration between real-time data (our API) and documented knowledge:
Figure 13: Agent analysis process with knowledge base
As we can see, it shows us all the references used within the knowledge base.
Figure 14: Knowledge base references
Pro Tip: To maximize the value of the knowledge base:
- Keep documentation updated and well-structured
Final Reflections: Beyond the Code 🎯
After this journey through implementing an intelligent industrial assistant, there are three fundamental learnings I want to share — ones I believe will make a real difference in your next Bedrock Agents projects.
1. The New Era of API Documentation
API documentation has evolved significantly. Listing endpoints and parameters is no longer enough; we need to create documentation that “educates” our language models. My experience with this project showed that agents need to understand:
- The complete context of each endpoint
- Specific use cases
- Relationships between different calls
- The implications of the data returned
It’s like giving your agent an expert manual, not just a technical dictionary.
2. From Monitoring System to Digital Expert
What we built transcends a simple intelligent monitoring system. The combination of:
- Amazon Bedrock Agents
- Well-designed APIs
- Structured knowledge bases
Creates an entity that’s closer to a digital expert than a tool. During testing, the system demonstrated the ability to:
- Reason about complex problems
- Consider multiple variables
- Provide contextualized recommendations
- Integrate historical knowledge with real-time data
3. Real Impact on Industrial Operations
The examples presented aren’t mere technical demonstrations; they represent a paradigm shift in industrial maintenance:
- Early detection of potential problems
- Data-driven preventive recommendations
- Integration of expert knowledge with real-time analysis
- Natural language interaction
Final Pro Tip: When designing similar systems, remember:
- Prioritize data and documentation quality
- Maintain a focus on the end user
- Iterate constantly based on real feedback
- Document both successes and challenges encountered
Next time you design a similar system, remember: you’re not just building another chatbot — you’re building a bridge between human knowledge and computational efficiency. And that, dear readers, is what makes this field truly exciting.
If you want to take your agent a step further and maintain conversation context across sessions, I invite you to read the next article on Amazon Bedrock Session Management.
See you in the next article! Feel free to share your experiences in the comments — I’d love to hear how you’re applying these concepts in your own projects. Happy coding! 🚀
