---
title: Sin interfaz (lampson run)
description: Usa un agente de Lampson desde un script, un cron u otro programa — un mensaje entra y la respuesta sale, en texto o como eventos JSON, o un proceso abierto con --stdio.
---
# Sin interfaz: `lampson run`

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

```sh
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

| opción | |
|---|---|
| `--agent ID` | el agente que contesta (por defecto, `build`) |
| `--thread T` | la identidad de la conversación fuera de Lampson: un teléfono, un ticket, `cto:tarea-17`. **Mismo agente + mismo thread = misma conversación**, con su historial |
| `--session ID` | o seguir una sesión por su id |
| `--json` | cada paso como una línea JSON (ver abajo) |
| `--ask` · `--strict` · `--yolo` | el modo de permisos; sin opción, el del agente, y si no dice, `strict` |

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:

```json
{"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](/es/docs/sdk) en modo local — Lampson adentro de tu programa, sin servidor.

```json
{"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.