Módulo 1: Por qué operar es distinto de construir

Descripción

agent-fundamentals-and-tool-calling-guide terminó con un agente que funciona: el agente de Reservo, capaz de listar salas, cotizar, reservar y cancelar, encadenando esas cuatro herramientas en varios pasos, auto-corrigiéndose cuando el modelo pide algo inválido, y respondiendo con una confirmación anclada en resultados reales. Ese agente vive en reservo_agent.py, detrás de una sola función: run_reservo_agent(question, model_script). Le das una pregunta y un guion de turnos, y te devuelve una respuesta de texto.

Esta guía parte exactamente de ahí — sin reconstruir una sola línea de esa función — y se hace una pregunta distinta: ¿qué cambia cuando ese mismo agente deja de resolver el guion de pruebas que tú mismo escribiste, y empieza a resolver lo que usuarios reales le pidan, uno detrás de otro, a lo largo de un día entero? La respuesta corta, y el tema de las ocho lecciones de este módulo: casi todo lo que necesitas para confiar en un sistema en producción es información que el agente, tal como quedó construido, no te da. Y dártela — sin tocar su lógica — es un oficio propio, distinto del oficio de construirlo. Ese oficio es operar.

Regla dura de esta guía (léela antes de seguir)

Esta guía hereda, literalmente, la regla dura de agent-fundamentals-and-tool-calling-guide: la decisión del modelo no se ejecuta. Cuando una lección dice "el modelo (claude-sonnet-5, concepto) decidió llamar get_quote", eso es un guion de turnos escrito a mano — nunca una llamada real a una API. Esa parte no cambia.

Lo que esta guía agrega es una capa de reglas propias, porque el tema ahora es medir un sistema, no solo construirlo, y medir mal es peor que no medir:

El costo se estima, y la aritmética del costo SÍ se ejecuta. La conversión de texto a tokens usa la misma convención honesta de agent-fundamentals: len(texto) // 4, rotulada siempre como estimación de orden de magnitud — nunca como el conteo exacto de un tokenizer real. El pricing de claude-sonnet-5 es una constante fija y citada: $3.00 por cada millón de tokens de entrada, $15.00 por cada millón de tokens de salida — el precio de lista, verificado en la documentación oficial de Claude. (Existió un precio promocional de lanzamiento, $2.00/$10.00, vigente solo hasta agosto de 2026; esta guía usa el precio de lista porque es el número que sigue siendo cierto después de esa fecha.) El cálculo de centavos con esa estimación y ese precio fijo sí corre de verdad, y vas a ver su salida real desde la lección 05.
La latencia se modela, nunca se mide con el reloj real. En ningún bloque de código de esta guía vas a ver time.time() ni time.perf_counter(). En su lugar, cada herramienta tiene una latencia fija, declarada en un diccionario (TOOL_LATENCY_MS), y la latencia de un run es la suma de las latencias de sus pasos. Esto es una simplificación deliberada: en producción de verdad, la latencia se mide con un cronómetro alrededor de cada llamada — eso es trivial de programar y no enseña nada nuevo. Lo que sí enseña algo es decidir qué hacer con esa medición una vez que la tienes: cuál herramienta domina el total, qué tan estable es de un run a otro, cuándo una cifra es sospechosa. Modelar la latencia con datos fijos hace que cada ejemplo sea reproducible byte a byte, para que puedas confirmar exactamente lo mismo que ves aquí en tu propia máquina.
Nada de aleatoriedad ni de relojes reales en los datos. Sin random, sin datetime.now(), sin uuid4(). Cualquier identificador que necesite ser único —como un trace_id, que vas a construir a fondo en el Módulo 2— es determinista: un contador, o un hash de las entradas del run.
La ingeniería de operación sí se ejecuta, de verdad, con Python 3.14.0 y su librería estándar (logging, json, dataclasses, statistics, entre otras según el módulo). No hay red, no hay git, no hay gh. Todo corre local, y cada salida que ves en un bloque "Qué esperar" es la salida real de haber ejecutado ese código.

Guárdate esta frase, porque la vas a usar en cada módulo que sigue: el modelo decide (concepto); el agente actúa (ya construido, en agent-fundamentals); esta guía observa, mide, gatea y endurece esa actuación (ingeniería real, aquí).

Dónde estamos en el ecosistema

Agentes en producción — operar el agente de Reservo
├── Módulo 1: Por qué operar es distinto de construir  ← ESTÁS AQUÍ
│   → El puente desde agent-fundamentals, un run sin instrumentar,
│     las señales que importan, la frontera operar-vs-construir
├── Módulo 2: Logging estructurado y trazado de un run
├── Módulo 3: Medir costo y tokens por run
├── Módulo 4: Medir latencia con honestidad
├── Módulo 5: Evals de regresión como gate de producción
├── Módulo 6: Fallos a escala — backoff, circuit breakers y rate limits
├── Módulo 7: Versionado y rollout seguro
└── Módulo 8: Proyecto — el agente de Reservo en producción

Este es el Módulo 1 de 8. No agrega ni una sola herramienta nueva, ni una línea nueva al bucle del agente — eso ya está resuelto, y resuelto bien, en agent-fundamentals-and-tool-calling-guide. Lo que hace es plantear, con precisión, el problema que los siete módulos siguientes resuelven uno por uno: un agente que funciona no es lo mismo que un agente que puedes confiar en operar. Los módulos 2 a 7 son las cuatro disciplinas que cierran esa brecha —observar, medir, gatear, endurecer y versionar—, y el Módulo 8 las junta todas sobre el mismo agente de Reservo, con evidencia real: cuatro archivos entregables (RUN_LOG.jsonl, un resumen de métricas, un regression_report.json, un AGENT_CHANGELOG.md).

El agente, sin instrumentar: la misma pregunta de siempre

Antes de nombrar ninguna disciplina, vale la pena ver el problema con tus propios ojos. Reservo, tal como quedó en agent-fundamentals M8, resuelve la tarea canónica de esa guía: "reserva Focus pro 3h para Ana". El guion de turnos (concepto, claude-sonnet-5) explora las salas, tropieza con un tier inválido, se auto-corrige, reserva, y responde:

import reservo_agent as ra

model_script_demo = [
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_01", "name": "list_rooms", "input": {}}]},
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_02", "name": "get_quote",
         "input": {"room": "Focus", "tier": "premium", "hours": 3}}]},
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_03", "name": "get_quote",
         "input": {"room": "Focus", "tier": "pro", "hours": 3}}]},
    {"stop_reason": "tool_use", "content": [
        {"type": "tool_use", "id": "toolu_04", "name": "book_room",
         "input": {"room": "Focus", "tier": "pro", "hours": 3, "member": "Ana"}}]},
    {"stop_reason": "end_turn", "content": [
        {"type": "text", "text": "Reservé Focus pro por 3 horas para Ana. Total $60.00. Confirmación #1."}]},
]

final, history = ra.run_reservo_agent("Reserva Focus pro 3h para Ana", model_script_demo)
print("RESPUESTA:", final["content"][0]["text"])

Qué esperar:

RESPUESTA: Reservé Focus pro por 3 horas para Ana. Total $60.00. Confirmación #1.

Una línea. Ese print es, literalmente, todo lo que un sistema que llama a run_reservo_agent y usa su resultado necesita para responderle al usuario — y es exactamente lo que la mayoría de las integraciones reales de un agente hacen: reciben la pregunta, llaman a la función, toman final["content"][0]["text"], se lo devuelven a quien preguntó. La tarea se resolvió. Nadie se quejó. Si esto fuera todo lo que existe, no habría nada que operar.

Pero ahora hazte estas cinco preguntas, con esa sola línea delante:

¿Cuántos pasos dio el agente para llegar a esa respuesta? ¿Uno? ¿Diez?
¿Qué herramientas llamó, y en qué orden?
¿Algo falló en el camino? ¿El modelo pidió algo inválido y tuvo que corregir?
¿Cuánto costó este run? ¿Cuántos tokens de entrada y salida consumió, a cuántos centavos equivalen?
¿Cuánto tardó? ¿Qué parte del tiempo se la llevó cada herramienta?

Con el código de arriba, no puedes responder ni una sola de las cinco. history sí existe como variable local mientras el proceso sigue vivo —podrías, en este mismo momento, inspeccionarla a mano—, pero en el instante en que la función retorna y nadie más la mira, esa información se pierde. Y ni siquiera inspeccionándola a mano llegas a las preguntas 4 y 5: no hay ningún tokens, ningún costo, ningún tiempo en ningún lugar de esa estructura. history registra qué pasó, no cuánto costó que pasara ni cuánto tardó en pasar. La lección 03 de este módulo se detiene exactamente en este punto, con más detalle y con el resto de las cinco preguntas puestas a prueba una por una.

Las cuatro disciplinas de esta guía

agent-fundamentals respondió "¿cómo construyo un agente que resuelve una tarea de varios pasos?". Esta guía responde una pregunta distinta y posterior: "¿cómo confío en que ese mismo agente, corriendo sin que yo lo esté mirando, sigue haciendo lo correcto?" Esa confianza se construye en cuatro capas, cada una apoyada en la anterior:

1. OBSERVAR   -> ¿qué pasó, exactamente, en este run?          (Módulo 2)
   Logging estructurado + un trace_id que correlaciona cada
   paso del loop, de punta a punta.

2. MEDIR      -> ¿cuánto costó y cuánto tardó?                  (Módulos 3-4)
   Costo por run (tokens estimados x precio fijo) y latencia
   por herramienta y total (modelada, honesta sobre su límite).

3. GATEAR     -> ¿sigue comportándose como se espera?            (Módulo 5)
   Un harness de regresión determinista -- de FORMA, nunca un
   juez semántico -- que falla el build si algo se rompió.

4. ENDURECER
   Y VERSIONAR -> ¿sobrevive a fallos repetidos, y puedo
                  cambiarlo sin apostar a ciegas?                (Módulos 6-7)
   Un circuit breaker por herramienta entre runs, y una
   comparación disciplinada entre una versión vieja y una nueva
   antes de decidir GO/NO-GO.

Fíjate en el orden: no puedes gatear (capa 3) lo que no puedes medir (capa 2), y no puedes medir con sentido lo que no puedes observar primero (capa 1). Por eso el Módulo 2 —logging y trazado— es el primero de los siete que quedan: es el cimiento sobre el que se paran los otros seis. El Módulo 8 no agrega una quinta disciplina — junta las cuatro sobre el mismo agente de Reservo y entrega la evidencia.

Este módulo, el 1, no construye ninguna de las cuatro todavía. Introduce el logging y un trazado mínimo de un run en la lección 08 — lo suficiente para que veas, con tus manos, la forma general de "envolver" un run con instrumentación — pero el desarrollo a fondo de esa capa (un trace_id que correlaciona de verdad, los campos completos de cada evento, un archivo RUN_LOG.jsonl) es trabajo del Módulo 2. Lo que este módulo sí hace, completo, es plantear el problema con precisión y nombrar las cuatro señales operacionales que vas a medir desde la lección 04 en adelante: tasa de error, tasa de fallo por herramienta, costo por run, latencia por run.

El caso que sigue acompañando la guía: Reservo, sin reconstruir nada

El sistema es el mismo de siempre — Reservo, reservas de salas de coworking — y las cuatro herramientas son exactamente las que agent-fundamentals M2 declaró y M8 ensambló, sin cambiar una línea:

list_rooms() — lista las salas con su tarifa base por hora, en centavos. Solo lectura.
get_quote(room, tier, hours) — cotiza una sala. Devuelve {price_cents}. Solo lectura.
book_room(room, tier, hours, member) — crea una reserva. Devuelve {booking_id, confirmed}. Escritura.
cancel_booking(id) — cancela una reserva. Devuelve {cancelled}. Destructiva.

Las dos anclas de precio que ya conoces siguen siendo el punto de referencia:

Focus basic 3h  ->  2500 * 3            = 7500  ($75.00)
Focus pro   3h  ->  2500 * 3 * 80 // 100 = 6000  ($60.00)

Y el runner que orquesta todo esto —el que llamamos arriba, run_reservo_agent— es literalmente el de agent-fundamentals M8, lección 05: valida cada argumento antes de ejecutar, atrapa cualquier excepción real, reintenta lo transitorio, corta lo que tarda demasiado, y nunca lanza una excepción sin control hacia quien lo llama — salvo RuntimeError cuando se agota el tope de iteraciones, el único caso que sí se propaga. Esta guía importa ese archivo, lo llama, y construye alrededor de él — nunca reescribe su lógica interna. Cuando una lección diga "el runner reintenta esto", está describiendo un comportamiento que ya existe y ya se probó, no algo que se está inventando aquí.

Lo genuinamente nuevo de esta guía son los artefactos de la capa de operación — módulos que se construyen alrededor del agente, nunca dentro de él: un logger estructurado, un calculador de costo, un modelo de latencia, un harness de regresión, un circuit breaker por herramienta, y un registro versionado de configuración. Identificadores y código, siempre en inglés; prosa y comentarios, en español; dinero, siempre en centavos int.

Prerequisitos

Conocimiento requerido:

✅ Haber completado (o conocer bien) agent-fundamentals-and-tool-calling-guide, en especial los Módulos 4 (el bucle), 7 (robustez) y 8 (el agente de Reservo completo). Esta guía asume ese agente construido y no vuelve a explicar tool_use/tool_result, el contrato de una tool, ni is_error.
✅ Python: funciones, diccionarios, comprensión de listas, try/except. Toda la ingeniería de esta guía es stdlib.

NO requerido:

❌ No necesitas una API key ni conexión a internet: la decisión del modelo sigue siendo concepto, y toda la ingeniería de operación corre 100% local.
❌ No necesitas conocer un framework de observabilidad (Datadog, LangSmith, Sentry). Los patrones —logging estructurado, trace_id, harness de regresión, circuit breaker— son los mismos con cualquiera; aquí los construyes a mano para entenderlos.
❌ No necesitas saber de infraestructura, SRE, Prometheus ni Grafana: eso es sre-and-incident-response-guide, una guía vecina que opera infraestructura, no el agente en sí. La lección 06 de este módulo traza esa frontera con precisión.

Entorno:

✅ Python 3.14.0 con su librería estándar. Nada que instalar.
✅ Un editor de texto y una terminal. Eso es todo.

Roadmap del módulo

Lección 01 — Introducción al módulo (esta)

El puente desde agent-fundamentals, la regla dura de esta guía, un run sin instrumentar y las cinco preguntas que no se pueden responder, las cuatro disciplinas, y el mapa de las ocho lecciones.

Lección 02 — El agente ya funciona en un notebook, ¿y ahora qué?

Qué cambia exactamente cuando el mismo run_reservo_agent deja de resolver un guion de prueba fijo y empieza a resolver preguntas distintas, una detrás de otra, sin que nadie las haya escrito de antemano.

Lección 03 — Lo que no puedes ver sin instrumentación

La analogía central del módulo —un auto sin tablero— puesta a prueba con código real: qué preguntas se pueden responder mirando history a mano, y cuáles ni siquiera están ahí.

Lección 04 — Las señales operacionales que importan

Cuatro señales, definidas con precisión y calculadas sobre runs reales: tasa de error (a nivel de run), tasa de fallo por herramienta (a nivel de tool call), costo por run, latencia por run.

Lección 05 — Un primer vistazo a costo, latencia y errores

La primera vez que esta guía calcula, de verdad, cuánto costó y cuánto tardó un run — con la fórmula de precio fija y la latencia modelada, ejecutadas sobre el run canónico.

Lección 06 — Operar vs. construir: la frontera

Dónde termina exactamente lo que agent-fundamentals ya resolvió (el loop, is_error dentro de un run) y dónde empieza esta guía; y dónde termina esta guía (el agente) y empieza sre-and-incident-response-guide (la infraestructura).

Lección 07 — El encargo: opera el agente de Reservo para usuarios reales

El caso de esta guía, planteado como un encargo concreto: cuatro preguntas de negocio que hoy no se pueden responder, y el mapa de qué módulo responde cuál.

Lección 08 — Mini-proyecto: envuelve un run y mira adentro

Construyes tu primera envoltura de instrumentación —ligera, sin logging formal todavía— alrededor de run_reservo_agent: costo en centavos, latencia modelada, y las señales de la lección 04, todas juntas, sobre un lote de runs reales.

Mapa de progresión

Lección 01 (esta)  → El puente, la regla dura, las cuatro disciplinas
Lección 02         → Qué cambia con usuarios reales
Lección 03         → El auto sin tablero, con código real
Lección 04         → Las cuatro señales, definidas y calculadas
Lección 05         → Costo + latencia + errores, por primera vez
Lección 06         → La frontera operar-vs-construir (y vs. infra)
Lección 07         → El encargo de esta guía
Lección 08         → Mini-proyecto: la primera envoltura

Dificultad: ⭐ ──────────────────▶ ⭐⭐

Qué lograrás en este módulo

Al completar las 8 lecciones, podrás:

Explicar por qué "funciona en el notebook" no es lo mismo que "está listo para operar", con el ejemplo concreto de Reservo.
Nombrar las cinco preguntas que un run sin instrumentar no puede responder, y por qué ninguna de las cinco vive en history.
Distinguir las cuatro disciplinas de esta guía —observar, medir, gatear, endurecer+versionar— y en qué módulo se construye cada una.
Definir con precisión tasa de error, tasa de fallo por herramienta, costo por run y latencia por run — y calcular las primeras dos sobre runs reales.
Trazar la frontera entre lo que ya construyó agent-fundamentals y lo que opera esta guía, y entre lo que opera esta guía (el agente) y lo que opera sre-and-incident-response-guide (la infraestructura).
Envolver un run de run_reservo_agent con una medición mínima de costo, latencia y señales — tu primer artefacto de operación, ejecutado.

El antes y después

ANTES del módulo:
→ "Si el agente responde bien, ya está listo para producción"
→ "history ya me dice todo lo que necesito saber de un run"
→ "medir el costo es un detalle de facturación, no ingeniería"
→ "la latencia se mide poniendo un cronómetro, eso ya lo sé hacer"

DESPUÉS del módulo:
→ Un agente que resuelve la tarea de un guion no es lo mismo que
  uno confiable con usuarios reales, a escala
→ history registra QUÉ pasó, nunca CUÁNTO costó ni CUÁNTO tardó
→ costo y latencia por run son señales operacionales de primera
  clase, con la misma seriedad que la tasa de error
→ observar, medir, gatear y endurecer son CUATRO disciplinas
  distintas, cada una apoyada en la anterior

Trampas a evitar al cursar este módulo

1. "Este módulo va a reconstruir el agente, mejor"

No. Ni una línea de reservo_tools.py, reservo_contracts.py, reservo_robust.py ni reservo_agent.py cambia en esta guía. Si algo de esa lógica te parece mejorable, esa es una nota para una revisión de agent-fundamentals, no una reescritura silenciosa aquí — reescribirla rompería la trazabilidad de qué se probó dónde.

2. "Si el `is_error` de una tool call ya se maneja en M7, no hay nada más que endurecer"

Hay una distinción real que la lección 06 traza con precisión: agent-fundamentals M7 resuelve "¿qué hace el agente cuando ESTA llamada a ESTA tool falla, ahora mismo, dentro de este run?" (auto-corrección, un reintento acotado). Esta guía, en el Módulo 6, resuelve una pregunta distinta: "¿qué hace el sistema cuando esa tool lleva fallando varios runs seguidos?" — un circuit breaker con estado que persiste entre runs, no dentro de uno solo.

3. "Medir latencia es solo poner `time.perf_counter()` alrededor de una llamada"

Programáticamente, sí — y por eso esta guía no se detiene ahí. Lo que sí exige trabajo real es decidir qué hacer con esa medición: qué herramienta domina el total, qué percentil importa, cuándo una cifra es una señal y cuándo es ruido. Por eso esta guía modela la latencia con datos fijos: para poder enfocarse en esas preguntas sin que la reproducibilidad del ejemplo dependa de cuánto tardó tu máquina en este momento exacto.

4. "El costo de un run es un problema de facturación, no de ingeniería"

No en esta guía. Medir cuánto cuesta un run —y por qué costó eso— es una señal operacional de primera clase, igual de importante que si falló o no. Lo que esta guía no hace es enseñarte a reducir ese costo (caching de prompts, selección de modelo, batching) — eso es cost-optimization-caching-guide, nombrada con precisión donde corresponde.

5. "Esto ya es SRE, o ya es evaluación de calidad semántica"

No. Esta guía opera el agente —sus runs, sus tool calls, sus tokens, sus prompts— a nivel de aplicación, con Python puro, costo cero. SRE de infraestructura (SLI/SLO de un servicio, Prometheus, el ciclo de vida de un incidente) es sre-and-incident-response-guide. Y el gate de regresión de esta guía (Módulo 5) nunca juzga si una respuesta es semánticamente buena —eso es evaluation-frameworks-guide—; solo confirma que la forma no se rompió: el schema, la tool elegida, el costo y la latencia bajo un umbral fijo.

Cómo trabajar este módulo

Corre cada ejemplo tú mismo. Cada lección trae código ejecutable con su "Qué esperar" real. Ver 185 milisegundos o 0 centavos salir de tu propia terminal vale más que leerlo.
No confundas "modelado" con "inventado". Cuando una lección dice que la latencia está modelada, no significa que el número sea arbitrario — significa que es un dato fijo y declarado, no una medición del reloj. La honestidad sobre esa diferencia es parte de lo que este módulo enseña.
El mini-proyecto (lección 08) es la síntesis. Ahí vas a envolver run_reservo_agent con tu primera medición real de costo, latencia y señales — el punto de partida conceptual de los Módulos 2 a 8.

Tiempo estimado:

Lección 01 (esta)  →  20 min lectura
Lección 02         →  20 min + correr el ejemplo
Lección 03         →  25 min + correr el ejemplo
Lección 04         →  25 min + correr el ejemplo
Lección 05         →  25 min + correr el ejemplo
Lección 06         →  20 min lectura
Lección 07         →  20 min lectura
Lección 08         →  35 min + armar la envoltura

Total: ~3 horas

Evidencia de éxito

Antes de avanzar al Módulo 2 (Logging estructurado y trazado de un run), deberías poder:

✅ Explicar, con el ejemplo de Reservo, por qué "el agente responde bien" no es lo mismo que "el agente está listo para operar".
✅ Nombrar las cinco preguntas que un run sin instrumentar deja sin respuesta.
✅ Distinguir las cuatro disciplinas de esta guía y su orden de dependencia.
✅ Calcular, sobre un run real, su tasa de fallo por herramienta y decir si el run se completó o no.
✅ Estimar, con la fórmula fija, el costo en centavos y la latencia modelada de un run.
✅ Trazar la frontera entre esta guía, agent-fundamentals y sre-and-incident-response.

Resumen

Esta guía opera el agente de Reservo que agent-fundamentals-and-tool-calling-guide ya construyó — no lo reconstruye, lo envuelve.
Regla dura: la decisión del modelo sigue siendo concepto (claude-sonnet-5); la ingeniería de operación —logging, costo, latencia modelada, regresión, circuit breaker, versionado— se ejecuta de verdad con Python 3.14.0.
Lo demostramos ejecutado: ante "reserva Focus pro 3h para Ana", el agente responde una sola línea de texto — y esa línea, por sí sola, no responde ni una de cinco preguntas operacionales básicas: pasos, herramientas, fallos, costo, latencia.
Las cuatro disciplinas de esta guía son observar → medir → gatear → endurecer+versionar, cada una apoyada en la anterior, desarrolladas en los Módulos 2 a 7 y unidas en el Módulo 8.
La frontera es doble: hacia agent-fundamentals (el loop y el manejo básico de errores ya están construidos, no se repiten) y hacia sre-and-incident-response (esa guía opera infraestructura; esta opera el agente).

Siguiente lección: 02 — El agente ya funciona en un notebook, ¿y ahora qué?. Vemos, con código ejecutado, exactamente qué cambia cuando run_reservo_agent deja de resolver el guion que tú escribiste y empieza a resolver preguntas que no controlas.

Recursos adicionales

Anthropic — Tool use (function calling) overview — El protocolo completo que el agente de Reservo ya implementa, y que esta guía opera sin volver a explicar.
Anthropic — Building effective agents — Sobre por qué la confiabilidad de un agente en producción depende de la disciplina de operarlo, no solo de construirlo bien una vez.
Anthropic — Pricing — La fuente del precio de lista de claude-sonnet-5 que esta guía fija como constante desde la lección 05.
Python 3.14 — What's New — La versión exacta con la que se ejecuta toda la ingeniería de esta guía.
Python — logging — La librería que el Módulo 2 desarrolla a fondo, y que esta lección introduce por nombre.

Siguiente →El agente ya funciona en un notebook, ¿y ahora qué?