DEV Community: ricardoceci

Memory-Aware Shopping Agents with Strands Agents and Mem0

ricardoceci — Thu, 09 Apr 2026 13:05:20 +0000

A research paper from Alibaba proposes a two-stage e-commerce agent that remembers customer preferences across sessions. In this post, you learn how to build it as a working chat app using Strands Agents, Amazon Bedrock, Mem0, and the Shopify Storefront Model Context Protocol (MCP).

Why e-commerce agents forget everything

Most e-commerce chatbots have goldfish memory.

A customer tells your assistant: "I'm a size M, I hate synthetic fabrics, my budget is around $200." Three sessions later, they're back. The bot asks again. This is not only a UX annoyance. It's a conversion problem. And it's entirely avoidable.

A paper published in March 2026, Shopping Companion (arXiv:2603.14864) from Alibaba's international commerce team, tackles this directly. The researchers build a large language model (LLM) agent that remembers customer preferences across sessions, retrieves them before searching, and asks the customer to confirm before recommending anything.

What the paper proposes

The core idea is splitting the agent into two stages instead of one.

Stage 1, Preference Identification: Before touching the catalog, the agent reads past conversation history and extracts implicit style preferences: size, fit, occasion, fabric aversions, color preferences, and budget. It surfaces a summary and asks the customer to confirm. They can correct anything before the search starts.

Stage 2, Shopping Assistance: With confirmed preferences in hand, the agent searches the catalog and verifies each candidate before recommending. For outfit bundles, it coordinates across products and validates budget math. The paper trains the whole pipeline end-to-end with reinforcement learning (RL). Their fine-tuned 4B model reaches 84% success on single-product tasks, surpassing GPT-4o (72%). You don't need to replicate the RL training. The inference architecture is fully buildable today.

Architecture

Stack:

Component	Service	Cost
LLM	Amazon Bedrock Claude Sonnet 4	Pay per token
Embeddings	Amazon Bedrock Titan Embed v2 (via Mem0)	Pay per token
Cross-session memory	Mem0 free tier	Free
Product catalog	Shopify Storefront MCP	Free, no auth
Chat server	FastAPI + uvicorn	Free
Agent framework	Strands Agents (open source)	Free

Stage 1: Cross-session memory with AWS Strands Agents and Mem0

The paper externalizes memory into retrievable records injected into generation at runtime. In this implementation, Mem0 handles extraction, deduplication, storage, and semantic retrieval, using Amazon Bedrock Titan Embed v2 as the embedding model.

mem0_memory ships as a built-in tool in strands-agents-tools, which means Stage 1 is a single-tool agent:

# agents/shopping_companion.py
from strands_tools import mem0_memory

def identify_preferences(self, user_id: str, query: str) -> str:
    agent = Agent(
        model=self._model,
        system_prompt=STAGE1_SYSTEM_PROMPT,
        tools=[mem0_memory],
    )
    return str(agent(
        f"user_id: {user_id}\n"
        f"Shopping request: {query}\n\n"
        f"Retrieve this customer's style preferences relevant to this request."
    ))

Before this can work, you need to index past conversations. Mem0 extracts structured facts from raw turns automatically:

from mem0 import MemoryClient

client = MemoryClient(api_key=os.environ["MEM0_API_KEY"])

turns = [
    {"role": "user", "content": "I always size up. I find fitted styles uncomfortable."},
    {"role": "assistant", "content": "Good to know. Sizing up for relaxed fit."},
    {"role": "user", "content": "I basically live in linen when it gets warm."},
    {"role": "assistant", "content": "Linen it is. Any fabrics to avoid?"},
    {"role": "user", "content": "Anything synthetic. Polyester makes me overheat."},
]

client.add(turns, user_id="user_123")

# Mem0 extracts:
# - "Customer sizes up, prefers relaxed fit"
# - "Customer prefers linen fabric"
# - "Customer avoids synthetic / polyester fabrics"

Five raw turns become three clean, queryable facts. Deduplication is automatic: running twice won't create duplicates, and when a customer says "actually I moved to size L last month," Mem0 updates the existing fact rather than adding a contradiction. According to the Mem0 paper, this approach delivers 91% lower latency and 90% lower token cost compared to full-context approaches, with 26% better accuracy on the LOCOMO memory benchmark than OpenAI's memory system.

Stage 2: Live catalog search via the Shopify Storefront MCP

The paper implements product_search and product_view as tools over a BM25 (Best Match 25) index. In this implementation, those tools come directly from the store via the Shopify Storefront MCP, so the catalog is always live: real prices, real stock, real variants.

Every Shopify store exposes a public MCP endpoint at https://{store}.myshopify.com/api/mcp. No OAuth or API key is required. The endpoint is open by design for storefront interactions. Strands has native MCP support:

# tools/product_tools.py
from strands.tools.mcp import MCPClient
from mcp.client.streamable_http import streamable_http_client

def get_shopify_mcp_client():
    endpoint = f"https://{os.environ['SHOPIFY_STORE_DOMAIN']}/api/mcp"
    # MCPClient requires a transport callable, not a url= keyword argument
    return MCPClient(lambda: streamable_http_client(endpoint))

list_tools_sync() must be called inside the context manager. The connection is not open until you enter it. This is where Stage 2 runs:

# agents/shopping_companion.py
def find_products(self, user_id, query, confirmed_preferences, bundle=False) -> str:
    _, mcp_client = get_product_tools()
    with mcp_client:
        # connection is open here — fetch tools and run agent
        tools = mcp_client.list_tools_sync()
        agent = Agent(model=self._model, system_prompt=STAGE2_PROMPT, tools=tools)
        return str(agent(
            f"Query: {query}\n\n"
            f"Confirmed preferences:\n{confirmed_preferences}"
        ))

The store's native search_shop_catalog tool accepts a context parameter. This is how confirmed preferences flow from Stage 1 into the catalog search:

search_shop_catalog(
  query="maxi dress",
  context="size M, relaxed fit, linen only, midi or maxi, avoids orange"
)

The user intervention loop: the detail that matters most

The paper explicitly models user intervention as a first-class part of the architecture. After Stage 1 retrieves preferences, the agent surfaces them for confirmation before Stage 2 runs. The customer can correct anything.

This implementation adds one critical refinement: once you confirm preferences in a session, they persist for all follow-up requests. Stage 1 only runs once, on the first message of a new session. The distinction between pending_preferences (pre-confirmation) and confirmed_preferences (persisted for the session) is what makes this work:

# app.py
if session["state"] == "awaiting_query":

    # Preferences already confirmed earlier in this session:
    # skip Stage 1 and go straight to product search
    if session["confirmed_preferences"] is not None:
        recommendation = companion.find_products(
            user_id=session["user_id"],
            query=req.message,
            confirmed_preferences=session["confirmed_preferences"],
        )
        return ChatResponse(reply=recommendation, stage=2, ...)

    # First request in session: run Stage 1
    preferences = companion.identify_preferences(...)
    session["pending_preferences"] = preferences
    session["state"] = "awaiting_confirmation"
    return ChatResponse(reply=preferences, state="awaiting_confirmation", stage=1, ...)

elif session["state"] == "awaiting_confirmation":
    confirmed = companion.process_confirmation(
        user_id=session["user_id"],
        identified_preferences=session["pending_preferences"],
        user_response=req.message.strip(),
    )
    session["confirmed_preferences"] = confirmed  # persists for whole session
    session["state"] = "awaiting_query"

    recommendation = companion.find_products(...)
    return ChatResponse(reply=recommendation, stage=2, ...)

The process_confirmation method delegates the correction-vs-confirmation decision to the agent itself. The agent has the full context of what was identified and what the customer said, which is exactly the kind of reasoning LLMs handle well. If the response is "looks perfect," nothing gets saved to Mem0. If it's "actually I moved to size L," the new fact gets stored and confirmed preferences are updated before Stage 2 runs.

The resulting conversation flow:

Turn 1: "I need a dress for a wedding"
  → Stage 1 runs, retrieves: size M, midi/maxi, linen, avoids orange
  → "Do these look right?"

Turn 2: "Looks perfect"
  → Stage 2 runs, returns dress recommendation
  → confirmed_preferences saved to session

Turn 3: "I liked that one. Can you find a blazer to go with it?"
  → confirmed_preferences already in session
  → Stage 1 SKIPPED, Stage 2 runs directly

Turn 4: "What about shoes?"
  → Stage 1 still SKIPPED, Stage 2 runs with same preferences

What to build next

The paper's main result is a 4B model that outperforms GPT-4o. This comes from RL training with a dual reward: one for how well Stage 1 extracted preferences, one for whether Stage 2's recommendation was correct. A third tool-wise reward scores each individual tool call, not only the final result. This significantly improves credit assignment in multi-turn interactions and also reduces response verbosity, because the model learns that unnecessary tool calls are penalized.

Replicating that training requires labeled trajectories and GPU compute. What you get from this repo is the full inference architecture running with Claude Sonnet 4 zero-shot. It works well in practice and gives you a production-ready foundation to layer the training on top of later.

Get started

pip install strands-agents "strands-agents-tools[mem0-memory]" \
    rank_bm25 fastapi uvicorn boto3 python-dotenv mem0ai

# .env
AWS_DEFAULT_REGION=us-east-1
BEDROCK_MODEL_ID=anthropic.claude-sonnet-4-20250514-v1:0
MEM0_API_KEY=your-mem0-api-key
MEM0_LLM_MODEL=anthropic.claude-3-5-haiku-20241022-v1:0
MEM0_EMBEDDER_MODEL=amazon.titan-embed-text-v2:0
PRODUCT_BACKEND=shopify
SHOPIFY_STORE_DOMAIN=your-store.myshopify.com

python scripts/index_history.py   # seed sample conversation history into Mem0
python app.py                     # start server at http://localhost:8000

The sample history includes preference sessions interleaved with unrelated conversations. This mirrors the paper's "needle in a haystack" setup, so the agent has to retrieve the right preferences from across multiple sessions.

Frequently asked questions

Does this work with any Shopify store?
Yes. Every Shopify store has a public MCP endpoint at https://{store}.myshopify.com/api/mcp enabled by default since the Summer 2025 Edition.

What happens if a customer has no memory yet?
Stage 1 returns an empty preference list and tells the customer so. Stage 2 runs with whatever the customer provides in that first message.

Can I use a model other than Claude Sonnet 4?
Yes. Strands Agents is model-agnostic. Replace BedrockModel with AnthropicModel or OpenAIModel in one line.

Do I need GPU compute to run this?
No. This implementation runs entirely on API calls to Amazon Bedrock and Mem0. The RL training from the original paper requires GPU compute, but that is not part of this repo.

Is Mem0 free?
Mem0 has a free tier at mem0.ai. You can also run it self-hosted with a local FAISS backend by setting USE_LOCAL_MEMORY=true in your .env file.

References

Lo que más me sorprendió de re:Invent 2025 (hasta ahora)

ricardoceci — Thu, 04 Dec 2025 18:59:36 +0000

Este año vine a re:Invent *con muchas expectativas… y AWS no defraudó.
Entre anuncios de modelos, agentes autónomos y nuevas formas de entrenar IA sin hipotecar tu empresa, siento que estamos entrando en otra liga.

Y sí: Matt Garman lo dijo en el keynote — “The future belongs to developers” — y estos lanzamientos lo dejan clarísimo.

Acá van los que, personalmente, más me volaron la cabeza.

Amazon Nova Forge — entrenar tu propio frontier model ya no es ciencia ficción

Hasta ahora, entrenar un modelo “estilo GPT” era un privilegio para 5 empresas en el planeta.

Con Nova Forge, AWS abre la puerta para que cualquier organización pueda entrenar su propio frontier model, partiendo de checkpoints de la familia Nova.

¿La traducción práctica?

Podés construir un modelo que entienda profundamente tu industria, tus datos y tus procesos… sin invertir una fortuna en GPUs ni esperar meses.

Lo que más me entusiasma:

Podés mezclar tus datos reales con los datos curados de Nova.
Tiene soporte para pre-training, fine-tuning e incluso reinforcement fine-tuning.
El modelo resultante se puede usar en Bedrock como si fuera un modelo propio más del catálogo.

Esto no es “un modelo personalizado”:

Es tu propio frontier model, hecho a tu medida.

Para los que trabajamos en e-commerce, retail, logística y automatización, esto abre una puerta gigante para crear modelos que entiendan inventarios, SKUs, productos, temporadas, comportamiento de clientes… con una precisión que un modelo genérico no puede igualar.

Amazon Nova 2 Omni — un solo modelo que lo hace todo

Otro anuncio fuerte fue Nova 2 Omni, un modelo multimodal que entiende:

texto
imágenes
video
audio

…y además puede generar texto e imágenes.

Lo más interesante para mí no es la multimodalidad en sí (que ya esperábamos), sino que AWS esté apostando a un único modelo unificado. Eso simplifica arquitectura, desarrollo y mantenimiento.

Imaginá flujos donde un cliente te manda un video, y el modelo:

lo entiende,
lo resume,
describe ítems,
genera imágenes de variantes,
y responde por texto o voz.

Todo con un solo endpoint.

Estamos yendo hacia modelos más “generalistas pero especializados en ejecución”. Y eso abre posibilidades enormes para agentes.

Bedrock AgentCore — agentes que por fin se pueden controlar

Si venís siguiendo los avances en agentes autónomos, sabés que el gran problema es que se vuelven… demasiado autónomos 😅

AWS anunció mejoras en AgentCore que apuntan justamente a eso:

Policies: reglas en lenguaje natural para definir qué puede y no puede hacer un agente.
Evaluaciones integradas: monitorean calidad, seguridad, utilidad.
Mejor memoria: los agentes mantienen contexto de forma más natural y consistente.

La parte de quality evaluations me parece clave: ya no tenés un agente que “esperás que se porte bien”; ahora tenés métricas que te dicen si realmente se está comportando como debería.

Esto es fundamental para llevar agentes a producción en empresas reales — no en demos.

Los tres “Frontier Agents”, y el que puede programar durante días

AWS presentó tres agentes que llama “frontier agents, pensados para cambiar la forma en la que desarrollamos, aseguramos y operamos software.

El que más ruido hizo: Kiro Autonomous Agent, un agente que puede codear durante horas o días, de forma autónoma, siguiendo un objetivo.

No es un Copilot mejorado.

Es otra categoría.

La apuesta de AWS es clara:

el futuro del desarrollo no es escribir código, sino explicar lo que querés construir.

Todavía está en preview, pero conceptualmente es enorme. Combina modelos Nova + AgentCore + memoria + políticas + herramientas. Es decir: un agente que realmente puede trabajar.

Para quienes construimos productos, integraciones y automatizaciones, esto es una señal fuerte de hacia dónde va la industria.

En resumen

Este re:Invent marca un cambio de etapa:

IA más personalizada (Nova Forge)
IA más capaz (Nova 2 Omni)
IA más controlada (AgentCore)
IA más autónoma (Frontier Agents)

Es el combo completo: poder, personalización, seguridad y autonomía.

Y todo dentro del ecosistema que ya usamos: Bedrock, SageMaker, IAM, CloudWatch, etc.

El mensaje es claro:

los developers ahora tenemos herramientas que hace dos años eran ciencia ficción.

MCP en acción: integra datos del sistema en tus modelos generativos

ricardoceci — Fri, 09 May 2025 15:42:13 +0000

En 2025, la velocidad con la que aparecen nuevos conceptos y funcionalidades en el campo de la inteligencia artificial generativa hace que parezca que han pasado décadas desde el lanzamiento de la primera versión de ChatGPT. Sin embargo, han pasado menos de tres años.

A fines de 2024, Anthropic, los creadores de Claude, publicaron el Model Context Protocol (MCP) como código abierto. Aunque inicialmente pasó desapercibido, hoy está presente en casi todos los artículos, herramientas o funcionalidades relacionadas con la IA generativa. MCP se menciona en todas partes.

¿Qué es MCP?

MCP (Model Context Protocol) es una especificación de código abierto desarrollada por Anthropic.

Según su documentación oficial, MCP actúa como el “USB-C para la IA”: una interfaz unificada que permite conectar modelos de lenguaje con herramientas externas de forma estandarizada.

La verdadera ventaja de MCP radica en la estandarización.

Técnicamente, un LLM que actúa como cliente puede conectarse a un servidor MCP para acceder a datos o funcionalidades externas.

Componentes estándar del protocolo MCP

El Model Context Protocol (MCP) se basa en tres componentes fundamentales que permiten a los servidores exponer capacidades a los clientes:

Recursos: Datos estructurados que proporcionan contexto adicional al modelo. Pueden incluir contenidos de archivos, registros de bases de datos, respuestas de APIs, entre otros. Los recursos son controlados por la aplicación y pueden ser seleccionados explícitamente por el usuario o automáticamente por el cliente. Más Info
Prompts: Plantillas reutilizables que definen interacciones comunes con el modelo. Permiten estandarizar y compartir flujos de trabajo, y pueden aceptar argumentos dinámicos, incluir contexto de recursos y guiar procesos específicos. Más Info
Herramientas: Funciones ejecutables que el modelo puede invocar para realizar acciones, como interactuar con sistemas externos, realizar cálculos o ejecutar comandos. Las herramientas son controladas por el modelo y pueden ser descubiertas e invocadas automáticamente por este.Más Info

“MCP proporciona una estructura modular que organiza claramente la entrada, el conocimiento y la capacidad de acción del modelo.”

¿Por qué es relevante?

Gracias a su estructura modular, MCP permite:

Separación de responsabilidades: cada bloque tiene un propósito específico.
Mayor claridad contextual: el modelo comprende mejor sus objetivos.
Agentes más avanzados: habilita el uso de memoria, herramientas y razonamiento intermedio.
Escalabilidad: permite construir arquitecturas modulares y sostenibles.

No estás escribiendo un solo prompt. Estás diseñando un protocolo.

Ejemplo práctico

Si le preguntas a un modelo cuál es el uso actual de la CPU de tu computadora, probablemente no lo sepa. No tiene acceso a tu sistema operativo, ya que su función principal es generar texto, no interactuar con hardware.

Ahí es donde entra MCP: permite que el modelo acceda a información externa a través de herramientas definidas por el servidor.

Cómo construir un servidor MCP en 4 pasos

Puedes crear un servidor MCP utilizando Python y la biblioteca fastmcp.

1. Crear `server.py`

from typing import Dict
import psutil
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("sys-monitor")

@mcp.tool()
def get_system_stats() -> Dict[str, float]:
    cpu_percent = psutil.cpu_percent(interval=1)
    virtual_mem = psutil.virtual_memory()
    return {
        "cpu_percent": cpu_percent,
        "memory_total_gb": round(virtual_mem.total / (1024 ** 3), 2),
        "memory_used_gb": round(virtual_mem.used / (1024 ** 3), 2),
        "memory_percent": virtual_mem.percent
    }

if __name__ == "__main__":
    mcp.run()

2. Crear `requirements.txt`

psutil>=5.9.0
fastmcp>=0.1.0

3. Crear el `Dockerfile`

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "server.py"]

4. Construir la imagen de Docker (opcional)

Nota: esta configuración reportará el uso de CPU del contenedor, no del sistema anfitrión. A fines educativos, sigue siendo válido.

docker build -t cpusage .

Conectar el servidor MCP a un modelo

Este ejemplo utiliza Claude Desktop, pero también es compatible con Amazon Q CLI u otros LLM que soporten MCP.

Sigue la guía oficial para la integración.

Si tu archivo claude_desktop_config.json está vacío, agregá lo siguiente:

{
  "mcpServers": {
    "cpusage": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "cpusage"
      ]
    }
  }
}

Si deseas ejecutar el servidor directamente con Python:

{
  "mcpServers": {
    "cpusage": {
      "command": "python",
      "args": ["ruta/al/server.py"]
    }
  }
}

También podés reemplazar "python" por uv u otro comando si estás usando un entorno virtual.

Si ya existen otros servidores definidos, simplemente agregá el bloque correspondiente.

Reiniciá Claude Desktop. ¡Listo!

Demostración

Ve un video con la demo Aqui

Cómo lo estoy usando

Estoy utilizando MCP en proyectos sobre AWS que integran modelos con bases de datos y herramientas personalizadas. Esta estructura me permite:

Definir herramientas disponibles
Proporcionar contexto persistente y actualizado
Establecer límites operativos claros

Además, con un poco de creatividad, es fácilmente portable a otras plataformas.

Conclusión

MCP no es solo una forma distinta de estructurar prompts: es una forma de diseñar la arquitectura cognitiva de tus agentes.

Si estás trabajando con GenAI en 2025 y aún no exploraste MCP, ahora es el momento.

Hands on MCP: Extending LLMs with Real-Time Data

ricardoceci — Fri, 09 May 2025 15:39:57 +0000

In 2025, the pace at which new concepts and features appear in the field of generative AI makes it feel like decades have passed since the launch of the first version of ChatGPT. However, it's been less than three years.

In late 2024, Anthropic, the creators of Claude, released the Model Context Protocol (MCP) as open source. Although it initially went unnoticed, today it’s present in almost every article, tool, or feature related to generative AI. MCP is mentioned everywhere.

What is MCP?

MCP (Model Context Protocol) is an open-source specification developed by Anthropic.

According to its official documentation, MCP acts like the “USB-C for AI”: a unified interface that allows language models to connect with external tools in a standardized way.

The real advantage of MCP lies in standardization.

Technically, an LLM acting as a client can connect to an MCP server to access external data or functionality.

Standard Components of the MCP Protocol

The Model Context Protocol (MCP) is based on three fundamental components that allow servers to expose capabilities to clients:

Resources: Structured data that provides additional context to the model. They may include file contents, database records, API responses, and more. Resources are controlled by the application and can be explicitly selected by the user or automatically by the client. More Info
Prompts: Reusable templates that define common interactions with the model. They allow standardization and sharing of workflows, and can accept dynamic arguments, include resource context, and guide specific processes. More Info
Tools: Executable functions that the model can invoke to perform actions, such as interacting with external systems, performing calculations, or executing commands. Tools are controlled by the model and can be automatically discovered and invoked. More Info

“MCP provides a modular structure that clearly organizes the model’s input, knowledge, and ability to act.”

Why is it relevant?

Thanks to its modular structure, MCP allows:

Separation of concerns: each block has a specific purpose.
Greater contextual clarity: the model better understands its goals.
More advanced agents: enables memory, tools, and intermediate reasoning.
Scalability: allows building modular and sustainable architectures.

You're not just writing a prompt. You're designing a protocol.

Practical Example

If you ask a model what your computer’s current CPU usage is, it probably won’t know. It has no access to your operating system, since its main function is to generate text, not interact with hardware.

That’s where MCP comes in: it allows the model to access external information through tools defined by the server.

How to Build an MCP Server in 4 Steps

You can create an MCP server using Python and the fastmcp library.

1. Create `server.py`

from typing import Dict
import psutil
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("sys-monitor")

@mcp.tool()
def get_system_stats() -> Dict[str, float]:
    cpu_percent = psutil.cpu_percent(interval=1)
    virtual_mem = psutil.virtual_memory()
    return {
        "cpu_percent": cpu_percent,
        "memory_total_gb": round(virtual_mem.total / (1024 ** 3), 2),
        "memory_used_gb": round(virtual_mem.used / (1024 ** 3), 2),
        "memory_percent": virtual_mem.percent
    }

if __name__ == "__main__":
    mcp.run()

2. Create `requirements.txt`

psutil>=5.9.0
fastmcp>=0.1.0

3. Create the `Dockerfile`

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "server.py"]

4. Build the Docker Image (Optional)

Note: this setup will report CPU usage of the container, not the host system. For educational purposes, it's still valid.

docker build -t cpusage .

Connecting the MCP Server to a Model

This example uses Claude Desktop, but it's also compatible with Amazon Q CLI or other LLMs that support MCP.

Follow the official guide for integration.

If your claude_desktop_config.json file is empty, add the following:

{
  "mcpServers": {
    "cpusage": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "cpusage"
      ]
    }
  }
}

To run the server directly with Python:

{
  "mcpServers": {
    "cpusage": {
      "command": "python",
      "args": ["path/to/server.py"]
    }
  }
}

You can also replace "python" with uv or another command if using a virtual environment.

If other servers are already defined, simply add the corresponding block.

Restart Claude Desktop. Done!

Demo

Video with a demo here

How I'm Using It

I’m using MCP in AWS-based projects that integrate models with databases and custom tools. This structure allows me to:

Define available tools
Provide persistent and updated context
Set clear operational boundaries

Additionally, with a bit of creativity, it’s easily portable to other platforms.

Conclusion

MCP is not just a different way to structure prompts: it’s a way to design the cognitive architecture of your agents.

If you're working with GenAI in 2025 and haven't explored MCP yet, now is the time.

Creación de un agente de cafetería con Amazon Bedrock y Shopify

ricardoceci — Fri, 25 Oct 2024 21:35:03 +0000

Hoy te explicaré cómo poner manos a la obra con Bedrock de manera segura y confiable y de paso, aprender un poco sobre café.

Aprenderás cómo consumir la API de Amazon Bedrock de modelos de Texto y Multimodales utilizando Python para poder generar nombres, logo y menú para tu cafetería y para poder crear un agente que se conecta a una API de Shopify para tomar pedidos.

Shopify es (a mi criterio) la mejor plataforma de eCommerce que existe.

Y así como AWS, Shopify tiene una API para todo y una plataforma para desarrolladores

Por último crearás un frontend utilizando Streamlit para dar una experiencia de usuario única y darle vida a tu agente.

📝 Indice

Invocando la API de Bedrock
Creación de un agente de Amazon Bedrock que interactúa con Shopify

🧐 Invocando la API de Amazon Bedrock para generar nombres, logo y menú para tu cafetería

El momento de abrir una cafetería o de tener ideas creativas para el negocio que fuese es una excelente oportunidad para apoyarse en la IA Generativa (GenAI) y sacar su máximo provecho.

A través de Amazon Bedrock puedes hacer uso de ella, pero... ¿Cómo se consume ese servicio?

Todo servicio en AWS tiene una API, y Amazon Bedrock no es la excepción, a continuación te explico cómo consumir la API de Amazon Bedrock a través de un ejemplo para generar nombres y un menú para una Cafetería al paso.

Y además te muestro cómo consumir un modelo multimodal capaz de analizar imágenes.

Instrucciones para programar un script en Python para ejecutar localmente o en una función Lambda para invocar a Amazon Bedrock:

Primero debes habilitar el acceso a los modelos en Bedrock Instrucciones aqui

Requisitos:

Una cuenta en AWS, si no tienes una cuenta, puedes abrir una aqui
AWS CLI Instrucciones aqui
Python 3.11 o superior

Paso 1) Crear un entorno virtual de Python Instrucciones aqui

En la carpeta bedrock_examples de este repositorio encontrarás diferentes ejemplos utilizados a continuación para invocar el modelo fundacional.

En la carpeta prompts encontrarás los prompts de ejemplo, que vas a poder utilizar para generar El nombre, el Menú y un prompt para pasarle a un modelo de generación de imágenes que podrás invocar tanto en el playground de Amazon Bedrock cómo invocando la API desde Python.

Paso 2) Instalar los requerimientos

pip install -r requirements.txt

Paso 3) Configurar Boto3 Mas info sobre boto3

Aqui configuro el cliente de AWS indicandole que utilice el perfil genaiday instalado en mi computadora y llamo al cliente de bedrock-runtime que me va a permitir invocar al modelo fundacional.

#Cambiar la region y el perfil de AWS
aws = boto3.session.Session(profile_name='genaiday', region_name=region)
client = aws.client('bedrock-runtime')

Paso 4) Ejemplo: Invocar modelo de texto

Esta función llama al método invoke_model y le paso el prompt indicado por el usuario y le devuelvo la respuesta

La parte más importante son los mensajes enviados:

{
                "role": "user",
                "content": [{
                    "type": "text",
                    "text": prompt
                }]
            }

def call_text(prompt,modelId="anthropic.claude-3-haiku-20240307-v1:0"):
    #esta función es para llamar un modelo de texto
    config = {
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 4096,
        "messages": [
            {
                "role": "user",
                "content": [{
                    "type": "text",
                    "text": prompt
                }]
            }
        ]
    }

    body = json.dumps(config)
    modelId = modelId
    accept = "application/json"
    contentType = "application/json"

    response = client.invoke_model(
        body=body, modelId=modelId, accept=accept, contentType=contentType)
    response_body = json.loads(response.get("body").read())
    results = response_body.get("content")[0].get("text")
    return results

Ejemplo:

print("Haiku")
print(call_text("Estoy buscando armar un local de café al paso, dame 5 nombres para un local.")

Paso 5) Ejemplo: Invocar a un modelo multimodal.

Aquí el proceso es similar, solo que hay que agregar el mime type del archivo enviado, para esto hay una función que en base al nombre del archivo obtiene el mimetype

def read_mime_type(file_path):
    # Este hack es para versiones de python anteriores a 3.13
    # Esta función lee el mime type de un archivo
    mimetypes.add_type('image/webp', '.webp')
    mime_type = mimetypes.guess_type(file_path)
    return mime_type[0]

Luego para invocar al modelo, los mensajes deben ser los siguientes:

 "messages": [
        {
            "role": "user",
            "content": [
                {
                     "type": "image",
                        "source": {
                            "type": "base64",
                            "media_type": read_mime_type(file),
                            "data": base64.b64encode(open(file, "rb").read()).decode("utf-8")
                        }
                },
                {
                    "type": "text",
                    "text": caption
            }]
        }
    ]

La invocación del modelo queda así:

def call_multimodal(file,caption,modelId="anthropic.claude-3-haiku-20240307-v1:0"):
    #esta funcion es para llamar a un modelo multimodal con una imagen y un texto
    config = {
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 4096,
    "messages": [
        {
            "role": "user",
            "content": [
                {
                     "type": "image",
                        "source": {
                            "type": "base64",
                            "media_type": read_mime_type(file),
                            "data": base64.b64encode(open(file, "rb").read()).decode("utf-8")
                        }
                },
                {
                    "type": "text",
                    "text": caption
            }]
        }
    ]
    }

    body = json.dumps(config)
    modelId = modelId
    accept = "application/json"
    contentType = "application/json"

    response = client.invoke_model(
    body=body, modelId=modelId, accept=accept, contentType=contentType)
    response_body = json.loads(response.get("body").read())
    results = response_body.get("content")[0].get("text")
    return results

Ejemplo:

pic_path = "./meetup_test_image.jpg"
caption = "Cuantas personas hay en la imagen? cuantas laptos ves? cuantos usan gorro o sombrero?, de que color es el hoddie de la primer persona a la derecha de la foto?"
print("Haiku")
print(call_image(pic_path,caption,"anthropic.claude-3-haiku-20240307-v1:0"))
print("Sonnet")
print(call_image(pic_path,caption,"anthropic.claude-3-sonnet-20240229-v1:0"))

🏁 Creación de un agente de Amazon Bedrock que interactúa con Shopify

Para crear un agente de Amazon Bedrock:

Asegurate de tener los modelos de Bedrock que quieras usar con el acceso habilitado Instrucciones aqui, en este caso utilizaremos Claude 3 Haiku y Sonnet

Luego crear el agente de Bedrock en la consola de AWS:

1) Ir al servicio Bedrock
2) Agentes
3) Crear agente

4) Darle un nombre al agente, en nuestro caso "Pausa-Cafetera-Agente
5) La descripción es opcional.
6) Uno de los pasos más importantes es elegir el modelo fundacional que va a hacer que nuestro agente funcione adecuadamente, si deseas saber cómo hacer para elegir el mejor modelo que se adapte a tu caso de uso Aqui tienes una guía sobre el servicio Amazon Bedrock Model Evaluation .
7) El siguiente paso es el prompt que va a guiar a tu modelo, aqui tienes que ser lo más preciso posible y sacar a relucir tus habilidades como prompt engineer, si no sabes por donde comenzar, te recomiendo visitar esta guia donde vas a encontrar las mejores guidelines para el modelo que estes utilizando, y además otro recurso muy útil es la consola de anthropic.

Este es el prompt que utilicé para el agente de ejemplo, te recomiendo escribir el prompt en inglés dado que los modelos fueron entrenados en inglés y a veces escribir en el idioma de origen de entrenamiento ayuda a evitar comportamientos erroneos.

You are a helpful Bedrock agent working at a coffee shop.

Your goal is to assist customers in placing orders, offering them combos and creating orders by consuming a Shopify API.

When a customer interacts with you, greet them politely and ask how you can help them today.

If they indicate that they want to place an order, start by offering them popular combos or bundles that your coffee shop offers.

Before offering any product make sure to get the list of available products from the API.

Do not offer any product that is not in our list of products, never ask the customer for any recommendations.

If the customer expresses interest in a combo, you have to provide more details about the items included and the price, never ask for details to the customer, you are the one who knows about the products and combos.

Throughout the ordering process, be friendly and patient. If the customer is unsure or has questions, provide clear explanations to help them make a decision. Once the customer has finalized their order, confirm the details with them and let them know you'll be placing the order through the Shopify API.

Before creating the order through the API make sure to ask the customer for his/her name, never assume you know it.

When creating the order through the API, make sure to accurately capture all the items the customer requested, along with any customizations or special instructions they provided.

It's important to note that you should respond to the customer in their preferred language. If they initiate the conversation in a language other than English, reply in that same language to ensure smooth and effective communication.

Your goal is to provide an excellent customer experience by offering helpful recommendations, answering questions, and accurately processing orders through the Shopify API. Remember to be polite, patient, and adapt your language to match the customer's preference.

8) Configuración adicional, debes permitir al agente que capture input del usuario, dado que seguramente le falte información para procesar la orden, por ejemplo: Necesitará preguntar por los productos que el cliente desea, el nombre, entre otras cosas.

9) Grupos de acción: Un grupo de acción define las acciones en las que el agente puede ayudar al usuario. Por ejemplo, puedes definir un grupo de acciones que diga TomarPedido que puede tener las siguientes acciones

Listar productos
Procesar Pedido

Para crear un grupo de accion vas a necesitar para cada acción:

El nombre
Los parámetros

Los grupos de acción para ejecutarse generalmente invocan una función Lambda, desde Bedrock puedes:

Crear una función lambda desde la consola de Bedrock (Seleccionar Creación rápida de una función lambda)

Elegir una funcion lambda ya creada aqui las instrucciones de cómo es el evento y la respuesta esperada por cada action group (grupo de acción)

Si eliges crear la función lambda desde la consola de Bedrock, se creará una función en python con un código fuente básico que luego deberás modificar, en este repo en el archivo agents/action_group/lambda.py tienes el código de ejemplo modificado para que funcione con el agente.

Estas son las variables que te entregarán la información necesaria:

function: es el nombre de la acción invocada, en el caso del ejemplo puede ser: get_products (para listar productos), y place_order (para generar la orden en Shopify)
parameters: es un diccionario de parámetros.

En el siguiente ejemplo puedes observar que hay dos acciones:

get_products que no requiere ningun parámetro
place_order que lleva 3 parámetros:

Parametro	Descripcion	Tipo	Obligatorio
customerEmail	Email of the customer	string	False
customerName	Name of the customer	string	True
products	SKUs and quantities to add to the cart in the format [{ variantId: variantId, quantity: QUANTITY }]	array	True

Entonces, por ejemplo cuando se llame a la función get_products en la función lambda se maneja de esta manera:

Hay una función get_products definida que será la encargada de hacer la query a la API de Shopify (A fines didácticos retornamos todos los productos)

Si quieres que esto funcione en Shopify debes reemplazar las siguientes variables por las de tu tienda:

access_token = 'shpat_XXXXX'


url = 'https://XXXXXXX.myshopify.com/admin/api/2024-10/graphql.json'

def get_products():

   # Let's query all the products from the Shopify API paginate through the results and store them in a list and return it
    products = []
    cursor = None
    while True:
        query = """
        {
          products(first: 10%s) {
            pageInfo {
              hasNextPage
            }
            edges {
              cursor
              node {
                id
                title
                description
                variants(first: 10) {
                  edges {
                    node {
                        id
                        title
                        sku
                        price
                    }
                  }
                }
              }
            }
          }
        }
        """ % (', after: "%s"' % cursor if cursor else '')
        response = requests.post(url, headers=headers, data=query)

        data = response.json()
        for edge in data['data']['products']['edges']:
            product = edge['node']
            products.append(product)
        if not data['data']['products']['pageInfo']['hasNextPage']:
            break
        cursor = data['data']['products']['edges'][-1]['cursor']
    return products

Luego en el handler de la función lambda, se verifica el nombre de la función llamada y se devuelve la respuesta con el formato que el action_group necesita:

def lambda_handler(event, context):
    agent = event['agent']
    actionGroup = event['actionGroup']
    function = event['function']
    parameters = event.get('parameters', [])

    # Execute your business logic here. For more information, refer to: https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html

    if(function == 'get_products'):
        products = get_products()
        responseBody =  {
            "TEXT": {
                "body": json.dumps(products)
            }
        }

Los fragmentos de código expuestos anteriormente son parte de la función lambda que se encuentra aqui

10) Presionar Guardar y Salir, y listo!, ya el agente esta listo para ser probado.

El Agente en acción

Lo siguiente es probar el agente y validar que funcione, desde Bedrock puedes hacer las pruebas del agente, y si durante la conversación clickeas "Ver traza o Show Trace" te va a ir mostrando el proceso de razonamiento, aqui es donde debes prestar especial atención y hacer los ajustes que creas necesarios en el prompt o bien buscar otro modelo si ves que el que elgiste no funciona como esperabas.

Una vez que estes conforme con el agente, puedes crear un Alias, un alias es un ID a través del cual vas a poder invocar al agente desde la API de Amazon Bedrock, cuando crees el alias, te va a crear una versión del agente automáticamente, o puedes apuntar a una versión ya existente, tener diferentes alias y diferentes versiones te va a ayudar a controlar el proceso de despliegue del agente, por ejemplo:

Puedes tener un alias "development" que va a ir a las ultimas pruebas del Agente
Un alias "preprod" que sería el agente en modo pre producción
Un alias "prod" y este es el agente live.

Luego solo restaría apuntar el alias de producción correspondiente a la versión que desees que este en vivo.

Cómo invocar el agente

Para esto, en la carpeta agents/frontend he dejado un archivo que se llama agent.py.

Este desarrollo utiliza Streamlit, un poderoso framework para realizar aplicaciones de muestra de machine learning

La parte del código que hace la invocación al agente es la siguiente:

aws = boto3.session.Session(profile_name='genaiday', region_name=region)
client = aws.client('bedrock-agent-runtime')
def invokeAgent(agent_id,agent_alias_id,prompt,session_id):
    response = client.invoke_agent(
        agentId=agent_id,
        agentAliasId=agent_alias_id,
        inputText=prompt,
        sessionId=session_id
    )
    return response

Utilizamos boto3 para consumir la API de AWS, llamamos al bedrock-agent-runtime cliente para poder hacer la invocación del agente.

Los parámetros que necesitamos pasarle son:

agentId
agentAliasId
inputText (el prompt)
sessionId (la sesión, para identificar las conversaciones)

En este ejemplo, las variables las estoy definiendo aqui:

with st.sidebar:
    agent_id = st.text_input("Agent ID", key="bedrock_agent_id")
    agent_alias_id = st.text_input("Agent Alias", key="bedrock_agent_alias")
    session_id = st.text_input("Sesion Id", key="session_id")

Instalación:

Primero debes habilitar el acceso a los modelos en Bedrock Instrucciones aqui

Requisitos:

AWS CLI Instrucciones aqui
Python 3.11 o superior

Te recomiendo crear un entorno virtual de Python Instrucciones aqui

pip install -r requirements.txt

Ejecución

streamlit run agent.py

Esto comenzará a ejecutar streamlit en el puerto 8501 y puedes visitar la siguiente URL: http://localhost:8501/ para ver el frontend que invocará al agente

Conclusión

Si has seguido todos los pasos has:

Consumido la API de Amazon Bedrock desde el Playground de Bedrock y desde Python
Has invocado modelos fundacionales de texto y multimodales
Has creado un agente desde 0 que consume una API de Shopify

Algunos links para que sigas tu camino dentro de GenerativeAI

Workshop AWS generative AI
Bedrock Knowledge Bases
Anthropic Console (Para hacer debug de nuestros prompts)
Community.aws (más artículos generados por y para la comunidad)

Llevando la gestión de Shopify al siguiente nivel con GenAI

ricardoceci — Mon, 11 Mar 2024 10:53:15 +0000

Tu empresa de venta online recibe muchos pedidos de atención al cliente (Customer Care), y generalmente las preguntas son las mismas siempre, ¿Dónde está mi orden?, ¿Cómo hago una devolución?, Quise aplicar un descuento a mi orden y no funcionó, entre otras, en períodos de muchas ventas y promociones pueden provocar que el equipo de atención al cliente se sature respondiendo emails, contestando llamados telefónicos para justamente responder a estas preguntas para abordar estos temas recurrentes.

Hoy día existen integraciones telefónicas donde un cliente al llamar tendrá que pasar al menos 3 o 4 minutos presionando los botones de su teléfono para llegar a dar con el estado de su orden o hablar con un represente, o tal vez intentando que un robot entienda lo que quiere decir “en pocas palabras” para terminar derivando con un agente para responder siempre las mismas preguntas.

Para solucionar esto, construí una solución que utiliza Generative AI para entender lo que el cliente quiere y armar un agente capaz de responder a las preguntas del cliente utilizando llamadas a una API de GenAI - Amazon Bedrock.

Si estás dando tus primeros pasos y quieres descubrir cómo aplicar inteligencia artificial a casos de uso de la vida real, si tienes una tienda online y quieres llevar la experiencia de atención al cliente al siguiente nivel, en esta serie de episodios te voy a mostrar cómo utilizando Amazon Bedrock agents y AWS Lambda construí un agente que se encargará de mantener informados a los clientes sobre el estado de sus pedidos realizados en una tienda en Shopify.

¿Qué vas a aprender?

Crear un Agente de Bedrock utilizando uno de los modelos fundacionales disponibles: Claude Instant V1
Crear una especificación openAPI 3.0 que funcione con un Agente de Bedrock
Crear una función lambda que cumpla con los requisitos para un agente de Bedrock

¿Cómo funciona la aplicación?

La aplicación comprende el backend para que luego la puedas integrar a cualquier cliente de Chat a través de API Gateway o bien mediante llamados a una API.

Esta aplicación consultará a la API de Bedrock Agents e interpretará lo que el cliente está solicitando y buscará recolectar toda la información necesaria para poder consultar la información de la orden y entregarla a nuestro cliente.

Para esto, el agente al tener la información necesaria, invocará una Función Lambda que será la encargada de interactuar con la API de Shopify y devolverle al agente la información que necesita para poder responder la pregunta que el cliente necesita.

El producto final

Amazon Bedrock Agents Demo - YouTube

youtube.com

🤓¿Qué son los Amazon Bedrock Agents?

Los Agentes de Amazon Bedrock son herramientas de IA que automatizan tareas empresariales, como la gestión de pedidos, mediante instrucciones en lenguaje natural y AWS Lambda, mejorando la eficiencia y reduciendo el trabajo manual.

☑️ Armar un Agente de Bedrock en 4 pasos

Para que el agente funcione vamos a necesitar

Generar credenciales de Shopify: Dado que vamos a utilizar Shopify para este tutorial, es necesario un access Token.
Escribir una especificación OpenAPI 3.0: Aquí le indicaremos al agente cómo funciona la función, que parámetros recibe y qué respuestas envía y cómo llamarla.
Creación de una función Lambda que se encargue de obtener el estado de la orden de Shopify.
Creación y configuración del agente.

🔑 Paso 1: Generar las credenciales en Shopify

Shopify es una plataforma líder de ecommerce que fue creada por desarrolladores y permite realizar la gestión de una tienda online de manera muy sencilla, ha sido pensada y creada por programadores por lo que para cada funcionalidad tiene una API.

La Función Lambda hace un llamado a una de las API de Shopify, y va a necesitar unas credenciales y permisos para consultar información de los pedidos de la tienda.

a) Obtener las credenciales, (si ya sabes cómo obtener estas credenciales puedes saltarte esta paso).
b) Crear una aplicación personalizada (Custom App) en Shopify:
Tutorial paso a paso: https://help.shopify.com/es/manual/apps/app-types/custom-apps#create-and-install-a-custom-app
c) Definir los permisos que se necesitan:
En este caso el unico necesario es: permiso para leer las ordenes (read_orders) https://help.shopify.com/es/manual/apps/app-types/custom-apps#get-the-api-credentials-for-a-custom-app
d) Instalar la app y obtener las credenciales:

📃 Paso 2: Crear la especificación OpenAPI 3.0

Este es el punto clave y el secreto de la magia, cuanto mejor este especificada y documentada la API, mejor va a funcionar el Agente de Bedrock.

Una especificación openAPI 3.0 es un archivo de texto json donde con un formato específico se indica:

Los endpoints de la API
Los métodos HTTP que acepta
Los parámetros que requiere y sus formatos
La respuesta que va a devolver y sus formatos.

Para cada uno de estos existe un campo description donde se debe indicar en lenguaje natural que es lo que hace, esto es lo que ayudará al Agente de Bedrock a tomar una decisión

Cabecera del documento:

{
    "openapi": "3.0.0", 
    "info": {
        "title": "Order Info API", 
        "version": "1.0.0",
        "description": "API that provides and identifies order details"
            },
    "paths":{}
}

Path:
/orders/{orderId}: Recibirá requests GET y va a devolver la información de la orden, para esto indicar que el orderId es un parámetro requerido y se recibe por URL.

"paths": {
        "/orders/{orderNumber}": {
            "get": {
                "summary": "Gets information about an order",
                "description": "Gets the entire information about an order based on its number",
                "operationId": "getOrderInfo",
                "parameters": [
                    {
                        "name": "orderNumber",
                        "in": "path",
                        "description": "ID of the order that needs to be fetched",
                        "required": true,
                        "schema": {
                            "type": "integer",
                            "format": "int64"
                        }
                    }
                ],
                "responses": {}
            }

Respuesta:

Armar una respuesta formateada de acuerdo a los requerimientos de un agente de Bedrock:

Status Code: 200
Un objeto con una propiedad content, application/json
Una enumeración de las propiedades de dicho objeto.

Crear un objeto con las siguientes propiedades:

Id: Numero de la orden
Status: El estado de la orden
MoreInfo: Si la orden esta en estado Fulfilled aqui enviaremos la URL para que el cliente pueda hacer el tracking del envío.

Aquí una representación del objeto final:

{
 'application/json': {
            'body': JSON.stringify({
                "id": orderNumber,
                "status": orderStatus,
                "moreInfo": moreInfo
            })
        }
}

La especificación openAPI 3.0 de la respuesta:

 "responses": {
                    "200": {
                        "description": "Object with the order information",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "object",
                                    "properties": {
                                        "id": {
                                            "type": "integer",
                                            "format": "int64"
                                        },
                                        "status": {
                                            "type": "string",
                                            "description": "Status of the order"
                                        },
                                        "moreInfo": {
                                            "type" :"string",
                                            "description": "More information about the order usually the tracking URL"
                                        }
                                    }
                                }
                            }
                        }
                    }
                }

Especificación openAPI 3.0 completa:

{
    "openapi": "3.0.0", 
    "info": {
        "title": "Order Info API", 
        "version": "1.0.0",
        "description": "API that provides and identifies order details"
            },
    "paths": {
        "/orders/{orderNumber}": {
            "get": {
                "summary": "Gets information about an order",
                "description": "Gets the entire information about an order based on its number",
                "operationId": "getOrderInfo",
                "parameters": [
                    {
                        "name": "orderNumber",
                        "in": "path",
                        "description": "ID of the order that needs to be fetched",
                        "required": true,
                        "schema": {
                            "type": "integer",
                            "format": "int64"
                        }
                    }
                ],
                "responses": {
                    "200": {
                        "description": "Object with the order information",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "object",
                                    "properties": {
                                        "id": {
                                            "type": "integer",
                                            "format": "int64"
                                        },
                                        "status": {
                                            "type": "string",
                                            "description": "Status of the order"
                                        },
                                        "moreInfo": {
                                            "type" :"string",
                                            "description": "More information about the order usually the tracking URL"
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

El archivo final debe ser cargado a un Bucket de S3, será necesario al momento de la creación del Agente.

🧑‍💻 Paso 3: Creación de la función Lambda

Crear una función Lambda que será la encargada de consultar la información de la orden en Shopify, para esto crea una función Lambda:

Ingresar a la consola de AWS Lambda https://console.aws.amazon.com/lambda/home#/functions
Presionar Create Function
Author from Scratch (Crear desde 0)
Asignar un nombre
Elegir el runtime, en este caso el ejemplo lo haré con NodeJS pero puedes hacerlo con el lenguaje de programación que gustes.
Arquitectura: x86_64

Para hacer consultas a una API Externa por HTTPs se utilizará la librería Axios de NodeJS y en el cuerpo de la función lambda se arma el objeto.

Si necesitas ayuda sobre cómo utilizar librerías de terceros en NodeJS y Lambda dejame un comentario y escribo un artículo sobre este tema.

El objeto de Axios necesita 2 propiedades:

La URL donde vamos a hacer el request
Los Headers (Cabeceras del request):
Shopify requiere un Header especial llamado X-Shopify-Access-Token, el mismo sirve para autenticar el request
El content type del request.

const axios = require('axios');

/** 
Let's create the axios request to Shopify
In order to get the Shopify-Access Token we'll need to create a custom app in Shopify to use the token 
*/
const shopifyRequest = axios.create({
        baseURL: `https://your-shopify-store.myshopify.com/admin/api/2024-01/graphql.json`,
        headers: {
            'X-Shopify-Access-Token': '[AQUI VA EL TOKEN GENERADO]',
            'Content-Type': 'application/json'
        }
    });

exports.handler = async (event) => {
// Lambda Function Code GOES here

}

La API de Shopify es GraphQL el siguiente request le indica que recibirá el orderNumber como parámetro, y que queremos traer el fulfillment status de la orden y en caso que haya fulfillments, la información del dicho Fulfillment. (Fulfillment es un objeto que trae información sobre el paquete del cliente cuando el mismo ha sido preparado y enviado)

A fines didácticos dado que ya se que el orderNumber va a venir en la posición 0 de los parámetros especificamos, esto se puede mejorar buscando la propiedad con el nombre orderNumber dentro del array parameters del objeto event de Lambda.

const orderNumber = event.parameters[0].value;
    const query = `{
        orders(first:1,query: "name:${orderNumber}") {
            edges {
                node {
                    name
                    displayFulfillmentStatus
                    fulfillments {
                        trackingInfo {
                            number
                            url
                        }
                    }
                }
            }
        }
    }`;

    // Let's get the response from Shopify

    const shopifyResponse = await shopifyRequest.post('', { query: query });

En el objeto shopifyResponse se guardará la información buscada y responseBody es la respuesta formateada tal como la necesita el Agente de Bedrock

// Let's get the order fulfillment status from the response

    const orderStatus = shopifyResponse.data.data.orders?.edges[0]?.node.displayFulfillmentStatus;
    const moreInfo = shopifyResponse.data.data.orders?.edges[0]?.node.fulfillments[0]?.trackingInfo[0]?.url;
    // Let's return the response

    let responseBody = {
        'application/json': {
            'body': JSON.stringify({
                "id": orderNumber,
                "status": orderStatus,
                "moreInfo": moreInfo
            })
        }
    }

El Agente de Bedrock necesita recibir en la respuesta algunos atributos para poder continuar con el flujo:

Como se verá mås adelante las respuestas de la API van a pertenecer a un ActionGroup del agente, entonces se debe devolver una respuesta para ese ActionGroup específico, el objeto debe tener las siguientes propiedades:

El ActionGroup
El Path
El Método HTTP que invocó al evento
El Status Code
El Body de la respuesta (responseBody)

let actionResponse = {
        actionGroup: event.actionGroup,
        apiPath: event.apiPath,
        httpMethod: event.httpMethod,
        httpStatusCode: 200,
        responseBody: responseBody,

    }

Luego se debe devolver esta actionResponse como respuesta al request:

 let response = {
        messageVersion: '1.0',
        statusCode: 200,
        response: actionResponse,
    };
    return response;

Repositorio con la función y la especificación OpenAPI: https://github.com/ricardoceci/aws-bedrock-agents-demo/

👔 Paso 4: Creación de un agente de Bedrock

Lo primero es ir al servicio “Amazon Bedrock”: https://console.aws.amazon.com/bedrock/ y allí seleccionar Agents y luego Create Agent

En el siguiente paso:

Asignar un nombre al Agente, por ejemplo: OrderInfoAgent
Indicar si el agente debe solicitar más información en caso que le falte: Si
Indicar si deseas utilizar un rol ya creado o crear uno nuevo, las opciones de encriptación y el timeout (en cuanto tiempo el agente considera que la sesión terminó) y los tags

A continuación:

Seleccionar el FM (Foundational Model) que va a darle vida al agente: Aquí una guía sobre cómo elegir un modelo fundacional: https://dev.to/aws-espanol/como-elegir-un-llm-272o Si no te aparece ninguno es porque debes primero habilitarlos (https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html).
Escribir las instrucciones para el agente, aquí es donde es muy importante el prompt que escribas, si bien el modelo puede interpretar múltiples idiomas, escribirlo en inglés hará las cosas más divertidas, por ejemplo: You're a kind customer care agent that is here to provide order status information to our customers, on each response you'll provide as much information as you can grab about the order and you'll always thank our customer for being a loyal customer, if you don't know the answer tell the customer to contact customercare@mycompany.com

Configurar los action groups, un agente puede tener múltiples grupos de acción, que son los que ejecutará en base a lo que el cliente escriba en el chat, en este caso el agente tendrá un solo actiongroup

Name: GetOrderInformation
Elegir la lambda function recién creada
Y la ubicación de la especificación OpenAPI en un bucket S3 que fue creada al principio.

Omitir la creación de una base de conocimientos, en la pantalla de revisión revisar que todo esté correcto y presionar “Create Agent”

Voilá, en unos minutos el agente estará listo para probar:
Alerta de Spoiler: Copiar el ARN que lo será necesario en breve:

💣 Probar el agente:

Explotó!. 🤯

¿Qué pasó?
Apreció el siguiente error: Access denied while invoking Lambda function arn:aws:lambda:us-east-1:XXXXXXX:function:XXXXXXX. Check the permissions on Lambda function and retry the request.

Si presionamos Show trace, no dice nada que ayude, el problema radica en que en ningún momento se le dió permiso al agente para Invocar la Función Lambda.

😱 Mi agente de Bedrock no funciona: Permisos necesarios de la Función Lambda

Para que el agente de Bedrock pueda invocar la Función Lambda tiene que tener permisos, para esto hay que agregar una Resouce Based Policy a la Función.

Desde la consola hacerlo de la siguiente manera:

1) Dentro de la función lambda, ir a Configurations -> Permissions

2) En la sección resource based policy statements, presionar “Add Permissions”

3) Seleccionamos AWS Service, y desplegar la lista de servicios, desafortunadamente, Bedrock no aparece como lista de servicios, así que seleccionar: Other (Otro)

4) Completar la información del Agente:

StatementId: Un identificador para la policy
Principal: bedrock.amazonaws.com
Source ARN: El ARN del agente de Bedrock
Action: lambda:invokeFunction

🎉 Todo funciona 🙂

Ahora al probar el agente y preguntarle sobre el estado de la orden, será capaz de responder con información y no con un error de permisos, el agente está listo.

El agente además es capaz de hablar en múltiples idiomas dado que el modelo fundacional Claude v1 tiene la capacidad de hacerlo, no todos los modelos tienen esta opción.

En español:

En inglés:

🎯 Conclusión:

En este episodio has aprendido a crear un Agente de Bedrock en pocos pasos y con muy poco código relacionado a la inteligencia en si del Agente dado que el mismo es capaz de interpretar las necesidades del cliente porque está construido con Generative AI.

Con este agente se busca reducir la cantidad de llamadas telefónicas o correos electrónicos con preguntas que ya se sabe donde ir a buscar la respuesta o a que endpoints de una API llamar.

El foco principal de los Agentes de Bedrock es que el desarrollador se ocupe de armar el código que le entregue la información al Agente y que el Agente sea quien se encargue de:
Entender qué quiere el cliente
Buscar la información, Llamar a una API para realizar una acción.
Entregar la respuesta al cliente.

También has aprendido a sortear el error sobre el permiso de invocación de la Función Lambda desde un Agente de Bedrock 🙂.

⏭️ Siguientes pasos (Próximo episodio):

El Agente de Bedrock está funcionando, los siguientes pasos son modificar el prompt, mejorar la Función Lambda para que devuelva más información, y disponibilizar para que sea invocado desde cualquier sitio web, esto lo veremos en el próximo episodio de esta serie 🙂

AWS Community Builder - ¿Cómo entrar al programa? (Spanish)

ricardoceci — Tue, 12 Jul 2022 11:20:13 +0000

Si te apasiona el desarrollo o eres curioso, te gusta compartir tus conocimientos y quieres aprender cómo hacerlo de manera profesional, Amazon Web Services creó un programa para estas personas, que es un lujo.

Soy miembro del programa desde Octubre 2021 y aquí te cuento cómo hice para entrar.

Desde mis inicios en la programación siempre me apasionó transmitir el conocimiento que iba adquiriendo, y esto lo hacía escribiendo artículos, dictando capacitaciones, y armando comunidades de desarrolladores.

He organizado la comunidad de Desarrolladores de PHP de Buenos Aires (alla por 2006), luego la de Shopify en Argentina y ahora estoy activamente participando en el AWS Users Group de Buenos Aires (Argentina).

Personalmente es lo que me apasiona, relacionarme con otros desarrolladores, aprender y compartir conocimiento, estas son las 3 principales características que busca el programa para aceptar a nuevos miembros.

¿De qué se trata el programa?

Este programa, además de los swags increibles que recibes, viene acompañado de un grupo en Slack donde tienes contacto directo con gente de AWS, con otros miembros del programa que estan allí para ayudarte en tu carrera.

Contacto directo con todos los miembros del programa AWS Heroes
Charlas exclusivas donde te enseñan a generar contenido, y te cuentan experiencias.
Oportunidades para dar charlas en distintos grupos de usuarios y eventos de todo el mundo.
Charlas y capacitaciones de acceso anticipado a nuevas features que AWS esta por lanzar al mercado.
USD 500 de crédito de AWS
1 año de acceso a CloudAcademy
1 Voucher de certificación gratis por año
Posibilidad de publicar en dev.to

Todo el tiempo se van agregando beneficios

¿Cuál es el criterio de aceptación?

No hay un criterio de aceptación específico, pero si dejame decirte que todo aquel entusiasta por el desarrollo de comunidades, generación de contenido y que tenga pasión por lo que hace y pueda demostrarlo, es muy bienvenido al programa.

¿Qué pasa si no me aceptan?

Un tropezón no es caída, el que no te acepten no significa que no puedas volver a anotarte en el próximo período, el que no te acepten te tiene que dar más fuerzas para continuar generando contenido e involucrándote y mejorando tu presentacíon / aplicación para la próxima apertura.

¿Tengo que tener contenido publicado?

El programa esta pensado para todos aquellas personas que deseen potenciar sus habilidades en la generación de contenido, dictado de charlas, transmisión de conocimientos y el networking entre desarrolladores.

Todo aquello que hayas hecho para potenciar las comunidades en el pasado ayudan, y te van a ayudar en el proceso de aplicación al programa.

¿Tengo que hablar inglés?

El programa esta abierto a cualquier persona del mundo, y se aconseja que personas de las comunidades menos representadas se inscriban (Latinos, Hispanos, entre otros).

Puedes no hablar inglés, pero un conocimiento mínimo es requerido, y si quieres aprovechar al máximo todas las charlas, debes saber algo, dado que la mayoría de las charlas están en este idioma.

El formulario de inscripción está en inglés, luego puedes desarrollar tu contenido en Español si gustas (yo lo hago).

¿Tengo que ser un experto en el tema?

La respuesta corta es no, como mencionaba anteriormente, es importante que si tengas ganas de compartir contenido y tus conocimientos, de involucrarte con las comunidades y hacer crecer el ecosistema de desarrolladores, este es tu lugar.

¿Cómo me inscribo?

Las inscripciones abren dos veces por año y se hacen desde el siguiente sitio web:

https://aws.amazon.com/es/developer/community/community-builders/

Las inscripciones a la fecha de escritura de este artículo están abiertas hasta el 17 de Julio de 2022 a la media noche, hora del pacífico.

Swag de bienvenida

Si todavía no te decidiste, aquí una ayuda más:

¿A quién no le gustan los regalos?….

Crear un recomendador de productos con Amazon Personalize (Spanish)

ricardoceci — Thu, 23 Jun 2022 11:31:55 +0000

Esta vez investigando alguna herramienta para recomendación de productos en mi trabajo, me encontré con Personalize (Amazon Personalize), poderosa pero ¿Simple?. Veamos!

A continuación una guía de cómo dar tus primeros pasos.

¿Qué es Amazon Personalize?

Según AWS
Amazon Personalize es un servicio administrado (fully managed) de Machine Learning que hace “fácil” a los desarrolladores presentar experiencias personalizadas a sus usuarios, y refleja el conocimiento y la experiencia que tiene Amazon al momento de construir sistemas de personalización.

https://docs.aws.amazon.com/personalize/latest/dg/what-is-personalize.html

El producto final

El objetivo de esta guía es que puedas conocer los fundamentos de Amazon Personalize, el resultado final será una recomendación de productos específicos para cada uno de los clientes de nuestro sitio.

Materiales

En este caso nos vamos a focalizar en generar un “recommender”para recomendar productos a nuestros usuarios

Tiempo requerido para este laboratorio: 1 – 2 horas.
Una cuenta de AWS (Si no tienes cuenta, debes crear una: https://portal.aws.amazon.com/billing/signup#/start/email
Lo que vamos a utilizar cuesta aproximadamente aprox USD 2 si ya no tienes free tier disponible.
Un bucket de S3 para poder subir los archivos de datos. Datasets (archivos CSV con información)
Nivel Padawan (aprendiz): Interacciones de los usuarios con tus productos
Nivel Jedi (Intermedio): Interacciones + Productos con atributos
Nivel Yoda (Avanzado): Interacciones + Productos con atributos + Usuarios

Preparación

Creación del Bucket de S3

(si ya tienes un bucket de S3 para guardar información, pasa a la sección de configuración adicional del bucket para Amazon Personalize)

En la consola de AWS buscamos S3 en el buscador de servicios que se presenta arriba a la izquierda.

Luego vamos a “Buckets” – Create Bucket

Elegimos un nombre representativo para el Bucket:

A los fines de este paso a paso dejamos los valores del formulario por defecto, pero sugiero en caso de quere pasar a producción el trabajo evaluar si hay algún requisito adicional necesario en lo que respecta a copia de seguridad, versionado y cifrado de la información.

Presionamos: Crear Bucket

Configuración adicional del Bucket para Amazon Personalize

Es requerido que el Bucket de S3 permita el acceso desde el servicio de Amazon Personalize para poder leer los archivos que hay dentro del bucket.

Desde el listado de Buckets clickeamos sobre el bucket recién creado

En la siguiente pantalla nos vamos a donde dice “Permisos”

En la sección Política del bucket, clickeamos “Editar”

Allí, en caso de ser este un bucket nuevo, eliminamos el valor por defecto y copiamos y pegamos el siguiente JSON reemplazando bucket-name por el nombre de nuestro bucket.

Si no es un bucket nuevo y tiene alguna politica adjunta, agregar los permisos requeridos (Effect, Pricipal, Action y Resource) a la política actual.

{ "Version": "2012-10-17", "Id": "PersonalizeS3BucketAccessPolicy", "Statement": [ { "Sid": "PersonalizeS3BucketAccessPolicy", "Effect": "Allow", "Principal": { "Service": "personalize.amazonaws.com" }, "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] } ] }

Deberá quedar así:

Preparar los archivos de datos: (Datasets)

Asegúrate de tener archivos CSV preparados con las siguientes estructuras

Interacciones

Es recomendable que este CSV tenga al menos 1000 registros del tipo “View” para sacar provecho de las diferentes “recetas”que hay para recomendar productos.

Es importante que aquí haya eventos solo “Positivos” Amazon Personalize no reconoce eventos “Negativos”, ejemplo: Eliminar un producto del carrito, para Amazon Personalize no es significativo.

Los eventos que AWS Personalize indica que debemos registrar son los: View y los Purchase

Es importante respetar el nombre de las columnas requeridas y opcionales.

Se pueden agregar hasta 5 columnas adicionales de metadata que combinadas con los diferent event types no superen las 10 columnas respetando los formatos establecidos: https://docs.aws.amazon.com/personalize/latest/dg/how-it-works-dataset-schema.html#personalize-datatypes

Si alguna de las columnas es del tipo CATEGORICAL y contiene más de un valor, separar las columnas con pipes “|”

Columnas Requeridas

USER_ID (string)
ITEM_ID (string)
TIMESTAMP (long)
EVENT_TYPE (string, (Purchase, View))

Columnas Opcionales

EVENT_VALUE (float), por si queremos darle más peso a un evento
IMPRESSION (string), aca podemos pasar que conjunto de productos se presentaron al usuario cuando interactuó con el producto que estamos enviando (Más info: https://docs.aws.amazon.com/personalize/latest/dg/interactions-datasets.html#interactions-impressions-data)
RECOMMENDATION_ID (string)

Items (Productos con atributos)

Este dataset es opcional, pero te lo recomiendo si queres obtener recomendaciones más acordes a tus usuarios.

Columnas Requeridas

ITEM_ID (string)
PRICE (float)
CATEGORY_L1

Columnas Opcionales

CATEGORY_L2 (string)
CATEGORY_L3 (string)
PRODUCT_DESCRIPTION (textual)
CREATION_TIMESTAMP (float)
AGE_GROUP (categorical, string)
ADULT (categorical, string): Yes, No
GENDER (categorical, string): Male, Female, Unisex

Usuarios

Este dataset también es opcional, pero como mencione anteriormente, cuanto más especificas quieras las recomendaciones y más información le des al sistema, mejor.

En este dataset debemos volcar la información que nos parezca relevante de los usuarios, el ID, si tenemos algún loyalty program el nivel en el que se encuentran (Bronze, Gold, Platinum, Diamond, o el nombre que le hayamos dado), la edad, género, o por ejemplo que tipos de series le gustan.

Columnas Requeridas

USER_ID
Algun metafield (Ejemplo Loyalty_program, age, gender)

Subir los Datasets al Bucket de S3

Estos 3 Datasets (recuerda que el único obligatorio es el de interactions) los debemos subir al Bucket de S3 creado al principio.

Dentro del Bucket presionamos: Cargar

Agregar Archivos

Luego elegimos en nuestra carpeta local los archivos que queremos subir y presionamos “Cargar”

Una vez terminada la carga, presionamos “Cerrar”

Paso a paso

Suponiendo que ya tienes los datasets creados, los pasos a seguir son los siguientes:

En la consola de AWS buscamos Amazon Personalize

Crear Dataset Group

Dentro de Amazon Personalize nos vamos a donde dice Create Dataset Group

Un datasetgroup es un “Agrupador de información”, aquí es donde agruparemos los distintos contenidos para recomendar, por ejemplo podemos tener un dataset group para recomendar libros, otro para recomendar videos, otro para recomendar ropa.

Le asignamos un nombre, y en seleccionamos el tipo de “Dominio” para los casos de uso, en este caso vamos a seleccionar Ecommerce, dado que estamos buscando recomendar productos.

Crear el primer dataset en Amazon Personalize

Ahora crearemos nuestro primer dataset, en este caso el de interacciones, un dataset es justamente la información que vamos a cargar, le ponemos un nombre al dataset de interacciones y un nombre al schema.

Definir el Schema

En este caso podemos dejar el schema por defecto dado que es el que vamos a estar utilizando en nuestro sistema, pero si gustamos debemos hacer las modificaciones que deseemos aqui.

Tipos de datos para los Schemas

Esta es una lista de los diferentes tipos soportados por AWS Personalize para los schemas:

Tipo	JSON
float	{"name":"Valor","type":"float",}
double	{"name":"Price","type":"double",}
int	{"name":"Quantity","type":"int",}
long	{"name":"Valor_Preciso","type":"long",}
string	{"name":"ITEM_ID","type":"string",}
boolean (true o false)	{"name":"LIKES_FRUIT","type":boolean,}
null (Si queremos indicar que algun valor puede ser nulo, debemos incluirlo al momento de la definición)	{"name":"GENRES","type":["null","string"]"categorical":true}

Cuando un campo es del tipo Categorical, debe aclararse al momento de definir el schema (en el caso del dataset de interactions, no tenemos ningun tipo categorical, pero probablemente en el dataset de usuarios o productos lo tendremos

{
"name":"GENRES",
"type":"string",
"categorical":true
}

Importar el Dataset (Crear un import job) en Amazon Personalize

El paso siguiente es importar los datos, para esto Personalize nos solicita crear un import job, cada vez que querramos importar nuevos datos, debemos crear un Import Job.

Aquí le definimos un nombre a nuestro import job y escribimos la ubicación del archivo CSV con las interacciones de los usuarios. Recuerda que el Bucket tiene que tener la policy que creamos en el apartado “Preparación”, sino no va a funcionar.

A continuación nos solicita que le indiquemos cuál es el Rol que puede acceder a el bucket de S3 creado anteriormente, este rol debe tener la política AmazonPersonalizeFullAccess.

En mi caso no tengo este rol creado, por lo que voy a elegir ‘Create a new role’ y Amazon Personalize lo hará por mí.

Luego indicamos a que Bucket / Buckets tendrá acceso este rol.

Podemos escribir el nombre de nuestro Bucket, en mi caso es redundante dado que el Bucket ya contiene el nombre personalize dentro de él (rc-personalize-datos), por ende al utilizar el wizard de AWS está creando un rol para todos los buckets que contengan el nombre Personalize.

Presionamos Create Role y ya tendremos nuestro Rol creado.

En la ventana original presionamos: Create dataset import job

Si todo sale bien, comenzara la importación del dataset.

Si clickeamos en “Overview” dentro de Amazon Personalize, podremos observar que la importación del dataset de interactions está en curso, en mi caso fueron 250Mb de datos, y tardó en procesarse aproximadamente 3 minutos.

Crear el Recomendador

Una vez que ya nos aparece “Active” el dataset de interactions, se nos habilita el siguiente paso para comenzar a crear los “Recommenders”, en la pantalla de Overview presionamos “Create Recommenders”

Aquí AWS Personalize nos muestra las diferentes opciones de recomendadores que podemos crear (son las recetas/casos de uso), aquí debemos tener especial cuidado con las recetas que utilizamos dado que se nos cobrará por cada receta que decidamos crear y cada recomendador activo que tengamos. (Ver Explicación de Precios)

En nuestro caso vamos a elegir el caso de uso: Recommended for you

Aquí un detalle de los casos de uso:

Caso de uso	Input	Output
Customers who viewed X also viewed	Item ID	Listado de items que otros customers vieron luego de ver el que pasamos como input
Frequently Bought Together	Item ID	Listado de items que otros customers frecuentemente compraron junto a este.
Best Sellers	User_ID	De acuerdo a los items que compró el usuario devuelve un listado de otros items que mejor se vendieron
Most Viewed	User_ID	Basado en las veces que el Customer vio un item, trae items recomendados para ver
Recommended for you	User_ID	Devuelve items que son recomendados para el usuario.

Amazon Personalize luego nos da la opción de configurar de manera avanzada este recomendador (o los que hayamos seleccionado)

En este caso:

Minimum recommendation requests per second: Este parámetro es muy importante dado que aqui debemos especificar cuantas veces por segundo vamos a utilizar el recomendador y amazon nos cobra por la cantida de horas/recomendaciones generadas, si nos excedemos de esta cantidad, Amazon Personalize auto escalará para poder satisfacer los requests, y luego cuando la demanda baje, volverá a lo que configuremos aquí, pero nunca menos.

En este caso podremos realizar un request por segundo, lo que nos indica 60 requests por minuto, son 3.600 requests por hora. Recomiendo dejarlo en 1 si no sabemos la cantidad de requests minimos e ir ajustando este parámetro.

Emphasis on exploring less relevent items: El sistema para poder recomendar generalmente empieza con los items con mayores interacciones, dado que asume que estos son los más claros, pero también se sugiere dejar un margen para “Explorar”, aqui es un valor que va de 0 a 1, en este caso por ejemplo 0.3 significa que el 30% de los items recomendados podrán ser exploratorios, es deecir que se usarán para experimentar. (Supongamos que recomendamos de a 4 items, 1.2 items podrian ser exploratorios). (Para que esto funcione bien, se recomienda subir un dataset de interactions nuevo periódicamente, o utilizar un Event Tracker. (https://docs.aws.amazon.com/personalize/latest/dg/recording-events.html)

Exploration item age cut off: En caso que deseemos explorar, lo que va a hacer el sistema es no utilizar para las recomendaciones items que no hayan tenido interacciones en los últimos días especificados en este parámetro, en nuestro caso no recomendará items que no hayan tenido interacciones en los últimos 30 días.

Presionamos: Create Recommenders

El Recommender pasará a crearse, este proceso demora varios minutos, en mi caso duró 60 minutos.

Evaluando el recomendador creado

Hay dos maneras de evaluar las recomendaciones de Amazon Personalize, una y la más recomendable es la denominada “online”, es aquella que se mide en base a los clicks que hicieron los usuarios a los productos recomendados por Amazon Personalize.

La segunda, es en base a las métricas que arroja Amazon Personalize al momento de crear el recomendador.

Una vez finalizada la creación del Recommender, vemos que nos devuelve métricas en base a lo que pudo entrenar el sistema y las recomendaciones que arrojará.

Estas métricas se generan de la siguiente manera:

El sistema toma el 10% como muestra para testeo.

Se utiliza el dataset para entrenar el modelo.

Luego se le pasa el 90% de la data más vieja como parámetro al modelo y trata de predecir el 10% que luego es comparado con la data de testeo.

A modo de resumen estos valores van de 0 a 1, cuando más cerca del 1, mejor.

Métrica	Descripción
Coverage	Cuántos items diferentes recomienda el sistema sin entrar a repetir el mismo item. Si utilizamos exploración es probable que este número sea más alto
Mean Reciprocal Rank at 25	Esta medida nos sirve para evaluar la precisión del recomendador para acertar el Top 1 recomendado.
Normalized Discounted Cumulative Gain at (5,10,25)	Este valor nos indica para el Top 5,10,25 el grado de relevancia de los resultados, penalizando los resultados que el sistema consideró relevantes pero en el testing aparecieron en ubicaciones más abajo, es decir aqui se premian los resultados relevantes que aparecieron arriba en las listas.
Precision at 5,10,25	Esta métrica nos indica la relevancia de los resultados en un Top 5,10 y 25, en este caso en vez de considerar la relevancia de los resultados, se considera la precisión de la recomendacion de los elementos relevantes.

Probando el recomendador

En la pantalla principal del recomendador nos vamos a “Test Recommender”

Luego nos solicitará ingresar el parámetro User ID:

Ingresamos algun usuario de nuestra base de datos:

A continuacion nos mostrará 25 recomendaciones para este usuario:

¿Cómo seguir?

A continuación queda a nuestro criterio como continuar, por ejemplo podemos:

Crear un script en nuestro lenguaje de programación favorito que consulte la API de Recomendaciones
Utilizar recomendaciones en Batch para crear campañas específicas
Implementar un Event Tracker para ir optimizando el recomendador

Explicación de los costos

Los precios se encuentran en el siguiente link: https://aws.amazon.com/es/personalize/pricing/

Dado que a veces cuesta entender el pricing, voy a tratar de hacerlo más sencillo

Amazon cobra por:

Ingesta de datos (proceso de los datasets + store de los datasets en S3)
Por hora que el recommender esté ejecutandose y cada 100.000 usuarios (hasta 4000 recomendaciones por hora) y escalando en recomendaciones por hora en base a la cantidad de usuarios. (un usuario es un USER_ID dentro del dataset de interacciones y de usuarios).
Si excedemos las 4000 recomendaciones por hora (o las que vengan incluidas en cada hora de recommender), por cada 1.000 se cobran valores adicionales (ej. $0.0833 a hoy para 1000 recomendaciones para 100.000 usuarios)

Recomendaciones finales

Para no incurrir en costos inesperados:

Una vez finalizado el ejercicio mencionado en este artículo

Recuerda borrar los archivos de datos subidos y eliminar el Bucket de S3
Elimina los recommenders que no uses como sus datgaset groups y sus datasets.

En caso que desees pausar y continuar en otro momento, te recomiendo presionar el botón “Stop recommender” que pausara el billing y el entrenamiento del Recommender hasta que vuelvas lo reactives.

Una vez detenido para reactivarlo hay que ingresar al recommender y presionar “Start Recommender”

DEV Community: ricardoceci

Memory-Aware Shopping Agents with Strands Agents and Mem0

Why e-commerce agents forget everything

What the paper proposes

Architecture

Stage 1: Cross-session memory with AWS Strands Agents and Mem0

Stage 2: Live catalog search via the Shopify Storefront MCP

The user intervention loop: the detail that matters most

What to build next

Get started

Frequently asked questions

References

Lo que más me sorprendió de re:Invent 2025 (hasta ahora)

Amazon Nova Forge — entrenar tu propio frontier model ya no es ciencia ficción

Amazon Nova 2 Omni — un solo modelo que lo hace todo

Bedrock AgentCore — agentes que por fin se pueden controlar

Los tres “Frontier Agents”, y el que puede programar durante días

En resumen

MCP en acción: integra datos del sistema en tus modelos generativos

¿Qué es MCP?

Componentes estándar del protocolo MCP

¿Por qué es relevante?

Ejemplo práctico

Cómo construir un servidor MCP en 4 pasos

1. Crear server.py

2. Crear requirements.txt

3. Crear el Dockerfile

4. Construir la imagen de Docker (opcional)

Conectar el servidor MCP a un modelo

Demostración

Cómo lo estoy usando

Conclusión

Hands on MCP: Extending LLMs with Real-Time Data

What is MCP?

Standard Components of the MCP Protocol

Why is it relevant?

Practical Example

How to Build an MCP Server in 4 Steps

1. Create server.py

2. Create requirements.txt

3. Create the Dockerfile

4. Build the Docker Image (Optional)

Connecting the MCP Server to a Model

Demo

How I'm Using It

Conclusion

Creación de un agente de cafetería con Amazon Bedrock y Shopify

📝 Indice

🧐 Invocando la API de Amazon Bedrock para generar nombres, logo y menú para tu cafetería

🏁 Creación de un agente de Amazon Bedrock que interactúa con Shopify

El Agente en acción

Instalación:

Ejecución

Conclusión

Llevando la gestión de Shopify al siguiente nivel con GenAI

¿Cómo funciona la aplicación?

El producto final

Amazon Bedrock Agents Demo - YouTube

🤓¿Qué son los Amazon Bedrock Agents?

☑️ Armar un Agente de Bedrock en 4 pasos

🔑 Paso 1: Generar las credenciales en Shopify

📃 Paso 2: Crear la especificación OpenAPI 3.0

🧑‍💻 Paso 3: Creación de la función Lambda

👔 Paso 4: Creación de un agente de Bedrock

💣 Probar el agente:

😱 Mi agente de Bedrock no funciona: Permisos necesarios de la Función Lambda

🎉 Todo funciona 🙂

🎯 Conclusión:

⏭️ Siguientes pasos (Próximo episodio):

AWS Community Builder - ¿Cómo entrar al programa? (Spanish)

¿De qué se trata el programa?

¿Cuál es el criterio de aceptación?

¿Qué pasa si no me aceptan?

¿Tengo que tener contenido publicado?

¿Tengo que hablar inglés?

¿Tengo que ser un experto en el tema?

¿Cómo me inscribo?

Swag de bienvenida

Crear un recomendador de productos con Amazon Personalize (Spanish)

¿Qué es Amazon Personalize?

1. Crear `server.py`

2. Crear `requirements.txt`

3. Crear el `Dockerfile`

1. Create `server.py`

2. Create `requirements.txt`

3. Create the `Dockerfile`