Lampson como motor

Sin interfaz: lampson run

El mismo agente, sin terminal ni web: un mensaje entra, la respuesta sale. Para scripts, tareas de cron, otros programas.

lampson run "resume los cambios de hoy"                         # la respuesta por stdout
lampson run --agent plan "revisa el último commit"              # cualquier agente, integrado o tuyo
echo "hola" | lampson run --agent tienda --thread cliente-42    # el mensaje también puede venir por stdin
lampson run --session 20261016-122626 "¿y los tests?"           # seguir una sesión conocida

lampson run no arranca el hub ni el servidor web: prepara la carpeta del proyecto y corre el turno.

Opciones§

Sin nadie delante, lo que pediría aprobación se deniega: el modelo lo ve y lo explica en su respuesta.

Código de salida: 0 bien · 1 el turno terminó en error · 2 uso inválido (agente inexistente, mensaje vacío).

--json: los eventos§

Una línea JSON por evento. Primero session, después lo que hace el agente, y done al final:

{"kind": "session", "data": {"session": "20261016-125226-8941", "agent": "tienda", "thread": "cliente-42", "mode": "strict"}, "agent": "tienda", "thread": "cliente-42"}
{"kind": "tool_call", "data": {"name": "read", "args": {"path": ".lampson/tienda/catalogo.json"}}, "agent": "tienda", "thread": "cliente-42"}
{"kind": "tool_result", "data": {"call": {…}, "output": "…"}, "agent": "tienda", "thread": "cliente-42"}
{"kind": "assistant", "data": "Sí, tenemos pan integral a $3.200.", "agent": "tienda", "thread": "cliente-42"}
{"kind": "done", "data": {"agent": "tienda", "thread": "cliente-42", "session": "…", "text": "Sí, tenemos pan integral a $3.200.", "steps": 2, "usage": {"input": 1079, "output": 357, "cached": 448}, "stopped": "done"}, "agent": "tienda", "thread": "cliente-42"}

Los tipos de evento: session, assistant, tool_call, tool_result, tool_denied, usage, inbox, error, compact y done. En done, stopped es done, max_steps, budget o error: ….

--stdio: un proceso abierto (modo local)§

lampson run --stdio queda abierto y atiende muchos pedidos: uno por línea en stdin, con un id tuyo. Es lo que usa el SDK en modo local — Lampson adentro de tu programa, sin servidor.

{"id": "r1", "op": "ask", "to": "tienda", "thread": "cliente-42", "text": "¿tienen pan integral?"}
{"id": "r2", "op": "agents"}
{"id": "r3", "op": "ping"}

Por stdout salen los mismos eventos que con --json, cada uno con el id de su pedido, y un done al terminar cada ask. Al arrancar emite {"kind": "ready", "data": {"agents": […], "protocol": 2, "warnings": […]}}: en warnings, una línea por cada herramienta que algún agente lista y no va a tener (un plugin apagado, un nombre mal escrito). Antes de un ask de ese agente sale también un evento warning. Con la variable LAMPSON_BUILTIN_TOOLS=off, el proceso no ofrece ninguna herramienta propia de Lampson (es la opción lampsonTools: false del SDK).

• Conversaciones distintas van en paralelo; dos pedidos de la misma conversación (agente + thread) se atienden en orden.
• "mode": "strict" o "yolo" en un ask fija los permisos de ese pedido (es tu programa, en tu máquina).
• Herramientas de la app (lo que usa lampson.tool() del SDK): {"op": "tools", "tools": [{"name", "description", "parameters", "timeout"}]} reemplaza la lista entera. Cuando el modelo llama a una, sale {"kind": "tool_request", "data": {"call_id", "name", "args", "ctx"}}, y tu programa contesta {"op": "tool_result", "call_id", "output"} (o "error"). ctx es el contexto del pedido (from, thread, meta…), que el modelo no escribe.
• Una línea que no es JSON devuelve un error y el proceso sigue. Cerrar stdin lo termina cuando acaban los pedidos en curso.