Notas prácticas: agentes, herramientas y habilidades para un asistente mini IA funcional
Guía paso a paso para utilizar las notas prácticas: agentes, herramientas y habilidades necesarias para un asistente mini IA funcional; contratos, verificaciones y espacios para código listo para usar destinados a los equipos que implementan este patrón.
Esta guía reconstruye el camino desde las materias primas hasta un sistema funcional para: agentes, herramientas y habilidades destinadas a un asistente mini IA operativo. El enfoque está en pasos ejecutables, verificaciones explícitas y código que se puede incorporar directamente a un repositorio sin tener que adivinar su propósito. En la fase de visión general, se deben definir las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin necesidad de adivinar el estado oculto. Se deben registrar los tiempos y el costo en tokens o consultas junto con los resultados funcionales. La visibilidad temprana del costo evita facturas inesperadas cuando el proceso pasa de una demostración a entornos compartidos.
¿Qué son las herramientas, habilidades y agentes?
Al trabajar en la etapa de “¿Cuáles son las habilidades y herramientas?”, anote primero el contrato: los insumos necesarios, la señal de éxito y qué ocurre en caso de un fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben encontrarse en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar sin ese historial desperdicia horas.
get_current_conditions
get_forecast
get_alerts
get_historical_weather
get_air_quality
get_marine_conditions
get_river_conditions
get_wildfire_info
search_location
check_service_status
Temperature = Celsius, Fahrenheit, Kelvin
Length / Distance = Inches, Feet, Yards, Miles, Millimeters, Centimeters, Meters, Kilometers
Mass / Weight = Ounces, Pounds, Stone, Grams, Kilograms, Metric Tons
Volume / Capacity = Fluid Ounces, Cups, Pints, Quarts, Gallons, Milliliters, Liters, Cubic Meters
Area = Square Feet, Square Meters, Acres, Hectares
Speed = Miles per Hour (mph), Kilometers per Hour (km/h), Knots, Meters per Second (m/s)
Time Zones = UTC/GMT offsets, Daylight Saving Time (DST) transitions, Unix timestamps to human-readable dates
Storage = Bytes, Kilobytes (KB), Megabytes (MB), Gigabytes (GB), Terabytes (TB)
Pruebe con código de ejemplo.
Al trabajar en la etapa de Experimento con Código de Ejemplo, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Documente junto con ello el camino óptimo y el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar agentes en bucles sin esa huella desperdicia horas.
Paso 1: Importar las bibliotecas necesarias
Al trabajar en la etapa de “Importar paso 1”, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Prefiera unidades pequeñas y verificables a scripts extensos. Cuando un paso falla, el fallo debe indicar una única responsabilidad y no un proceso complicado. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar bucles sin ese registro desperdicia horas. Al trabajar en la etapa de “Importar paso 1”, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Anote los tiempos de ejecución y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la fase de demostración a entornos compartidos.
import re
import os
import getpass
import requests
Paso 2: Crear una herramienta de calculadora
La fase de Paso 2 para crear la herramienta funciona mejor si se trata como una superficie medible. Capture una transcripción exitosa, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema.
def calculator_tool(prompt: str) -> str:
print(" [Tool 1: Calculator] scanning prompt for dollar amounts...")
dollar_amounts = re.findall(r'\$\s?(\d+(?:\.\d{1,2})?)', prompt)
if not dollar_amounts:
result = "no dollar amounts found"
print(f" [Tool 1: Calculator] {result}")
return result
values = [float(a) for a in dollar_amounts]
total = sum(values)
breakdown = " + ".join(f"${v:g}" for v in values)
result = f"{breakdown} = ${total:.2f}"
print(f" [Tool 1: Calculator] found {len(values)} amount(s) {values} -> {result}")
return result
Paso 3: Crear la herramienta de conversor de unidades
La Etapa 3, Crear el escenario, funciona mejor cuando se trata como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente junto con ello el camino óptimo y el camino de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Exponga herramientas con esquemas limitados y etiquetas explícitas de efectos secundarios. Los administradores necesitan saber qué llamadas modifican el estado antes de aprobarlas automáticamente.
UNIT_ALIASES = {
"kilometers": "km", "kilometer": "km", "km": "km",
"mile": "miles", "miles": "miles",
"m": "meters", "meter": "meters", "meters": "meters",
"ft": "feet", "foot": "feet", "feet": "feet",
}
DISTANCE_TO_MILES = {"km": 0.621371, "miles": 1.0, "meters": 0.000621371, "feet": 0.000189394}
def unit_converter_tool(prompt: str) -> str:
print(" [Tool 2: Unit Converter] scanning prompt for distance legs...")
legs = re.findall(r'(\d+(?:\.\d+)?)\s*(kilometers?|km|miles?|meters?|feet|ft)\b',
prompt, re.IGNORECASE)
if not legs:
result = "no distances found"
print(f" [Tool 2: Unit Converter] {result}")
return result
total_miles = 0.0
breakdown = []
for value, unit in legs:
value = float(value)
unit_norm = UNIT_ALIASES.get(unit.lower(), unit.lower())
total_miles += value * DISTANCE_TO_MILES.get(unit_norm, 1.0)
breakdown.append(f"{value:g} {unit_norm}")
result = f"{' + '.join(breakdown)} = {round(total_miles, 2)} miles total"
print(f" [Tool 2: Unit Converter] found {len(legs)} leg(s) -> {result}")
return result
Etapa 4: Crear la habilidad de resumen
El paso 4, “Crear la etapa”, funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Exponga herramientas con esquemas limitados y etiquetas claras sobre efectos secundarios. Los administradores necesitan saber qué llamadas modifican el estado antes de aprobarlas automáticamente. El paso 4, “Crear la etapa”, funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la fase de demostración a entornos compartidos.
def summarizer_skill(text: str, max_sentences: int = 2) -> str:
print(" [Skill: Summarizer] scanning message for key sentence(s)...")
sentences = [s for s in re.split(r'(?<=[.!?])\s+', text.strip()) if s]
if len(sentences) <= max_sentences:
print(f" [Skill: Summarizer] only {len(sentences)} sentence(s) -- returning as-is")
return text.strip()
stopwords = {"the","a","an","is","are","was","were","in","on","at","to","of","and",
"or","for","it","this","that","i","you","he","she","they","we","really"}
words = re.findall(r'\b\w+\b', text.lower())
freq = {}
for w in words:
if w not in stopwords:
freq[w] = freq.get(w, 0) + 1
scored = []
for idx, sentence in enumerate(sentences):
s_words = re.findall(r'\b\w+\b', sentence.lower())
score = sum(freq.get(w, 0) for w in s_words)
scored.append((score, idx, sentence))
top = sorted(scored, key=lambda x: x[0], reverse=True)[:max_sentences]
top_in_order = sorted(top, key=lambda x: x[1])
summary = " ".join(s for _, _, s in top_in_order)
print(f" [Skill: Summarizer] kept {len(top_in_order)} of {len(sentences)} sentence(s) -> {summary}")
return summary
Paso 5: Conéctese a su LLM
En el Paso 5, Conectar con la etapa, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben encontrarse en un lugar donde los operadores puedan auditarlos sin necesidad de leer todo el sistema. Prefiera salidas estructuradas con validación de esquema sobre texto libre cuando el siguiente paso sea código o una llamada a una herramienta.
GROQ_API_KEY = os.environ.get("GROQ_API_KEY") or getpass.getpass(
"Enter your free Groq API key (from https://console.groq.com/keys), "
"or press Enter to skip: "
)
GROQ_MODEL = "openai/gpt-oss-20b"
GROQ_ENDPOINT = "https://api.groq.com/openai/v1/chat/completions"
def call_llm(augmented_prompt: str,
system_prompt: str = "You are a helpful, concise assistant.") -> str:
if not GROQ_API_KEY:
return ("[No LLM reply -- no Groq API key was provided. Get a free one at "
"https://console.groq.com/keys, then re-run the setup cell above.]\n"
f"Here is the augmented prompt that would have been sent:\n\"\"\"\n{augmented_prompt}\n\"\"\"")
try:
response = requests.post(
GROQ_ENDPOINT,
headers={
"Content-Type": "application/json",
"Authorization": f"Bearer {GROQ_API_KEY}",
},
json={
"model": GROQ_MODEL,
"messages": [
{"role": "system", "content": system_prompt},
{"role": "user", "content": augmented_prompt},
],
"temperature": 0.7,
"max_tokens": 400,
},
timeout=30,
)
response.raise_for_status()
data = response.json()
return data["choices"][0]["message"]["content"].strip()
except requests.exceptions.RequestException as e:
return f"[LLM request failed -- {e}]"
except (KeyError, IndexError, ValueError):
return "[LLM returned an unexpected response format.]"
print("LLM configured." if GROQ_API_KEY else "No key entered -- running in fallback mode.")
Paso 6: Cree sus agentes
En el Paso 6, “Construye tu etapa”, define las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documenta tanto la ruta óptima como la ruta de recuperación. Las intentonas, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Autentica en la pasarela y vuelve a autorizar en el plano de datos. Un token portador por sí solo no constituye un límite entre tenencias.
def show_step(step_num: int, label: str, content: str) -> None:
"""Small helper so every agent prints its pipeline the same, readable way."""
print(f"\n STEP {step_num} - {label}:")
for line in str(content).splitlines() or [""]:
print(f" {line}")
def trip_planner_agent(prompt: str) -> str:
"""Agent 1. Condition: 2+ dollar costs AND 2+ distances -- a multi-stop itinerary."""
print("[Router] -> Agent 1: Trip Planner Agent activated (detected an itinerary: multiple costs + multiple distances)")
show_step(1, "Original prompt", prompt)
cost_result = calculator_tool(prompt)
show_step(2, "Tool result (Calculator -- total cost)", cost_result)
distance_result = unit_converter_tool(prompt)
show_step(3, "Tool result (Unit Converter -- total distance)", distance_result)
augmented_prompt = (
f"The user asked: \"{prompt}\"\n\n"
f"A calculator tool already computed the total cost: {cost_result}\n"
f"A distance tool already computed the total distance traveled: {distance_result}\n\n"
"Using those two verified totals (don't redo either calculation yourself), give the "
"user a short, friendly trip summary that reports both totals clearly."
)
show_step(4, "Prompt has changed -- now the augmented prompt sent to the LLM", augmented_prompt)
reply = call_llm(augmented_prompt)
show_step(5, "Final response from Groq", reply)
return f"🧳 Agent 1: Trip Planner Agent:\n{reply}"
def text_agent(prompt: str) -> str:
"""Agent 2. Condition: default for any prompt, OR chained after Agent 1
when the itinerary prompt also has an extra narrative sentence."""
print("[Router] -> Agent 2: Text Analysis Agent activated")
show_step(1, "Original prompt", prompt)
summary = summarizer_skill(prompt)
show_step(2, "Skill result (Summarizer)", summary)
augmented_prompt = (
f"The user wrote: \"{prompt}\"\n\n"
f"Automatic summary of their message: {summary}\n\n"
"Write a short, thoughtful, natural-sounding reply to the user that responds "
"to what they actually said, informed by (but not just repeating) this summary."
)
show_step(3, "Prompt has changed -- now the augmented prompt sent to the LLM", augmented_prompt)
reply = call_llm(augmented_prompt)
show_step(4, "Final response from Groq", reply)
return f"📝 Agent 2: Text Analysis Agent:\n{reply}"
Paso 7: Enviar al agente correcto
Para llevar la Ruta Paso 7 a la fase de implementación, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado. Autentique en la pasarela de entrada y vuelva a autorizarlo en el plano de datos. Un token de portador por sí solo no constituye un límite entre entornos. Para llevar la Ruta Paso 7 a la fase de implementación, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo de los tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos.
def looks_like_itinerary(prompt: str) -> bool:
dollar_amounts = re.findall(r'\$\s?\d+(?:\.\d{1,2})?', prompt)
distance_legs = re.findall(r'\d+(?:\.\d+)?\s*(?:kilometers?|km|miles?|meters?|feet|ft)\b',
prompt, re.IGNORECASE)
return len(dollar_amounts) >= 2 and len(distance_legs) >= 2
def has_extra_narrative(prompt: str) -> bool:
sentences = [s for s in re.split(r'(?<=[.!?])\s+', prompt.strip()) if s]
extra = [
s for s in sentences
if "quot; not in s
and not re.search(r'\b(?:miles?|km|kilometers?|feet|ft)\b', s, re.IGNORECASE)
and not s.strip().endswith("?")
]
return len(extra) >= 1
def route_prompt(prompt: str) -> str:
if looks_like_itinerary(prompt):
reply = trip_planner_agent(prompt)
if has_extra_narrative(prompt):
print("[Router] -> also routing to Agent 2: Text Analysis Agent (extra narrative sentence detected)")
reply += "\n\n" + text_agent(prompt)
return reply
else:
return text_agent(prompt)
Paso 8: Prueba de tus resultados
Al trabajar en la fase de prueba del Paso 8, anota primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestas las futuras modificaciones en el código. Mantén la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el código. Registra el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar agentes sin ese registro desperdicia horas.
prompt = input("Ask me anything: ")
print("=" * 60)
print(f"PROMPT: {prompt}")
print("=" * 60)
final_answer = route_prompt(prompt)
print(f"\n >>> RETURNED: {final_answer}")
print("-" * 60 + "\n")
Comprensión de la lógica.
Al trabajar en la etapa de comprensión de la lógica, anote primero el contrato: las entradas requeridas, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestos los cambios posteriores en el código. Documente junto con ello la ruta de éxito y la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras realizadas posteriormente. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar agentes sin ese historial desperdicia horas.
Paso 1: Enrutamiento al agente
Al trabajar en la Etapa 1 de Enrutamiento hacia la fase de ejecución, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Prefiera unidades pequeñas y probables sobre scripts extensos. Cuando una etapa falla, el fallo debe apuntar a una única responsabilidad y no a un proceso complicado. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar bucles sin ese registro desperdicia horas. Al trabajar en la Etapa 1 de Enrutamiento hacia la fase de ejecución, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación garantiza que los cambios posteriores en el código sean transparentes. Anote los tiempos de ejecución y el costo del token o la consulta junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la versión de demostración a entornos compartidos.
Etapa 2: El agente planificador de viajes llama a sus herramientas
La etapa del planificador de viajes en el Paso 2 funciona mejor cuando se trata como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos confidenciales y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema.
Paso 3: Llamar a la herramienta de cálculo
La etapa 3, “Llamar al stage”, funciona mejor cuando se trata como una superficie medible. Capture un registro exitoso, un caso de fallo y la nota de reversión antes de ampliar el alcance. Documente tanto el camino óptimo como el camino de recuperación juntos. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Exponga herramientas con esquemas limitados y etiquetas explícitas de efectos secundarios. Los administradores necesitan saber qué llamadas modifican el estado antes de aprobarlas automáticamente.
Paso 4: Llamar a la herramienta de conversor de unidades
La etapa “Paso 4: Llamar” funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Exponga herramientas con esquemas limitados y etiquetas explícitas sobre efectos secundarios. Los administradores necesitan saber qué llamadas modifican el estado antes de aprobarlas automáticamente. La etapa “Paso 4: Llamar” funciona mejor cuando se trata como una superficie medible. Capture un registro ideal, un caso de fallo y la nota de reversión antes de ampliar el alcance. Registre los tiempos y el costo de tokens o consultas junto con los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la fase de demostración a entornos compartidos.
Paso 5: Crear un prompt actualizado
En el Paso 5, “Crear etapa actualizada”, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin necesidad de leer todo el sistema. Prefiera salidas estructuradas con validación de esquema sobre texto libre cuando el siguiente paso sea código o una llamada a una herramienta.
Paso 6: Enviar resultados a GROQ
En la fase de envío de resultados del Paso 6, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Autentique en la pasarela y vuelva a autorizarlo en el plano de datos. Un token portador por sí solo no constituye un límite entre tenencias.
Paso 7 — Utilizar text_agent
En la etapa Step 7 Use textagent, defina las entradas, el responsable de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea desde un punto de control conocido sin tener que adivinar el estado oculto. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando una tarea falla, el error debe indicar una única responsabilidad y no un proceso complicado. Autentique en la pasarela de entrada y vuelva a autorizarlo en el plano de datos. Un token de portador por sí solo no constituye un límite entre entornos. En la etapa Step 7 Use textagent, defina las entradas, el responsable de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea desde un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo de los tokens o consultas junto con los resultados funcionales. Tener visibilidad sobre los costos desde el principio evita facturas inesperadas cuando la tarea pasa de un entorno de demostración a uno compartido.
Paso 8: Utilizar la habilidad de resumen
Al trabajar en la fase del Paso 8 de uso del resumen, anote primero el contrato: los datos de entrada requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de secretos y las banderas de funcionalidad deben encontrarse en un lugar donde los operadores puedan auditarlos sin tener que leer todo el sistema. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar agentes sin ese registro desperdicia horas.
Paso 9: Enviar los resultados a GROQ nuevamente
Al trabajar en la etapa 9 de envío de resultados, anote primero el contrato: los datos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación ayuda a mantener honestos los cambios posteriores en el código. Documente junto con ello la ruta de éxito y la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar bucles de agentes sin esa información desperdicia horas.
Argumentos a favor de los agentes, las habilidades y las herramientas.
Al trabajar en “Making the case for stage”, anote primero el contrato: los insumos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Prefiera unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el fallo debe apuntar a una sola responsabilidad y no a un proceso complicado. Registre el nombre de la herramienta, el hash de los argumentos, la latencia y el resultado de cada llamada. Depurar bucles sin esa información desperdicia horas. Al trabajar en “Making the case for stage”, anote primero el contrato: los insumos requeridos, la señal de éxito y qué ocurre en caso de fallo parcial. Esa lista de verificación mantiene honestas las futuras modificaciones del código. Anote los tiempos de ejecución y el costo en tokens o consultas junto a los resultados funcionales. Tener visibilidad del costo desde el principio evita facturas inesperadas cuando el proceso pasa de la versión de demostración a entornos compartidos.
Lista de verificación operativa
La etapa de lista de verificación operativa funciona mejor cuando se trata como una superficie medible. Capture una transcripción ejemplar, un caso de fallo y la nota de reversión antes de ampliar el alcance.
Trate esta etapa como un contrato entre las entradas y las salidas validadas. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas.
Exponga herramientas con esquemas limitados y etiquetas explícitas de efectos secundarios. Los administradores necesitan saber qué llamadas modifican el estado antes de aprobarlas automáticamente.
Deje la aprobación humana para los casos en los que se gastan fondos o se modifican datos de producción. La conexión en tiempo de compilación no equivale a la completitud del proceso empresarial.
Escriba un manual breve: cómo rotar claves, cómo vaciar la cola y cómo revertir la última inserción.
Documente tanto el camino óptimo como el de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son algo que se añada posteriormente.
Antes de promocionar el stack, congele las versiones, capture una transcripción de referencia para la ruta crítica y confirme los pasos de reversión. Los entornos compartidos requieren límites de velocidad, verificaciones de tenencia y un responsable claro para la rotación de secretos. Prefiera una fiabilidad sencilla a demostraciones ingeniosas pero puntuales.
Nota por lotes para 6caa2a29578e: mantenga las claves del proveedor fuera del repositorio, establezca un límite máximo para tokens por sesión y almacene las transcripciones junto a los fixtures de evaluación para que los cambios posteriores en el modelo sigan siendo comparables.
Lecturas relacionadas
- Notas prácticas: Las 10 habilidades de agente más prácticas en 2026 (y la próxima generación) — Guía detallada de Notas prácticas: Las 10 habilidades de agente más prácticas en 2026 (y la próxima generación: contratos, verificaciones y espacios de código listos para usar en equipos que implementan este patrón.