Colaboración con la IA

Colaborar de forma autónoma y continua

Contenido

En cuanto hayas conectado una herramienta de IA (Conectar una herramienta de IA), puedes hacer que la colaboración sea constante: con el skill de trabajo incluido, tu agente se ocupa de tu carpeta de datos por su cuenta, a petición o de forma continua en segundo plano, de modo que la colaboración es casi en tiempo real.

Una base de tareas común para ti y tus agentes

TandemLoop es ambas cosas: tu sistema personal para gestionar tu vida y tus proyectos, y una base de tareas compartida en la que colaboras con agentes de IA muy distintos. Como todo está guardado como archivos sencillos en la carpeta de datos, esa carpeta es la referencia común: tú planificas y decides; uno o varios agentes leen el mismo estado, proponen y completan lo que se les ha asignado. Ningún agente viene integrado ni es exclusivo: puedes cambiar de herramienta o combinarlas, y todas siguen trabajando sobre el mismo contenido.

El skill de trabajo

El skill de trabajo es unas instrucciones breves que le das a tu herramienta de IA. Describen un ciclo de trabajo recurrente:

  • recoger primero tus respuestas a sus devoluciones y ponerlas en práctica,
  • buscar las tareas disponibles asignadas a él (assigned_to: ai) y completarlas por orden de prioridad,
  • revisar las propuestas abiertas (si están activadas) por si tienen comentarios nuevos tuyos y rehacerlas,
  • devolverte los resultados para revisar o con una consulta.

Se atiene estrictamente al contrato de trabajo de AGENTS.md: sin propuestas, crea elementos nuevos y modifica directamente lo existente — de forma trazable en el historial de tus tareas —, pero solo elimina si tú se lo pides y no completa ni descarta tus tareas por su cuenta; con propuestas, plantea todo lo estructural como propuesta. Tú conservas el control.

Devueltas por el agente

Si le pasas tareas al agente, también te las devuelve: si ha preparado algo, te devuelve la tarea para revisar; si necesita una decisión, información o algo que solo tú puedes aportar, te hace una consulta. Cada devolución lleva una nota del agente: qué ha hecho, dónde está el resultado y qué debes hacer tú, o bien su pregunta.

Dónde ves las devoluciones:

  • En la barra lateral, debajo de la Bandeja de entrada, está Devueltas por el agente con el número de devoluciones pendientes y debajo, en cuanto las hay, por separado Para revisar, Consulta y Con el agente. En el iPhone es la pestaña Devueltas.
  • Allí donde aparezca la tarea (en proyectos, vistas, tablero, tabla o calendario) lleva un símbolo propio: un bocadillo con una marca de verificación (para revisar) o con un signo de interrogación (consulta). Al hacer clic en él ves la nota con formato y enlaces activos, junto con las reacciones.
  • En los detalles de la tarea, la devolución aparece arriba del todo.

Cómo reaccionas (directamente en la lista, en la ventana emergente del símbolo, en los detalles o en el menú contextual):

Reacción Efecto
Aceptar (con Para revisar) La tarea queda completada; consta que la completó el agente y que tú la aceptaste
Pedir correcciones (con Para revisar) Vuelve al agente con un breve comentario
Responder (con Consulta) Tu respuesta llega al agente y la tarea vuelve a estar en sus manos
Encargarme yo La tarea se te asigna a ti
Descartar tarea La tarea se descarta

Puedes revertir cualquier reacción con Deshacer en el mensaje de la parte inferior. Cada reacción, con su comentario o su respuesta, queda en el historial de la tarea, así que el ida y vuelta se puede seguir: quién dijo qué y cuándo. En su siguiente ciclo, el agente reconoce tu reacción sin ambigüedad y se ocupa primero de las correcciones y las respuestas. En las vistas puedes filtrar por el estado Para revisar o Consulta, por @is_handback y por tu reacción; en el tablero, ambos aparecen como columnas propias junto a Activo.

Con el agente: El agente se ejecuta fuera de TandemLoop, así que la app no puede iniciarlo. Hasta que retome tu corrección o tu respuesta, la tarea aparece en Devueltas por el agente, en Con el agente, con el tiempo transcurrido desde tu reacción y el momento en que el agente trabajó por última vez (lo anota en _config/agent.yaml en cada ciclo). Inicia entonces tu agente o dale la frase adecuada con Copiar encargo. En cuanto retome la tarea, desaparece de ahí y recibes una notificación. Si tu agente se ejecuta con regularidad, por ejemplo según una programación, no tienes que hacer nada.

Cómo devuelve el agente las tareas se describe en AGENTS.md. Ahí está el formato de archivo (status: needs-review o needs-input y la nota como entrada del historial). Un agente puede escribirlo y leerlo sin herramientas adicionales, también mientras la app está cerrada.

Instalación: copiar el texto y dárselo al agente

El skill se instala dándole su texto a tu herramienta: no hay descarga ni archivo de configuración.

  1. Apunta la herramienta a la carpeta de datos (consulta Conectar una herramienta de IA).
  2. Copia el texto del skill completo de la sección El texto del skill para copiar, al final de este capítulo.
  3. Dáselo a la herramienta. Pega el texto en tu herramienta de IA. La primera línea del texto le indica a la herramienta que lo convierta en un skill reutilizable llamado tandem-worker, así que no tienes que explicar nada más.
  4. Ejecútalo. A partir de ahí inicias una pasada con /tandem-worker (o con la forma de llamada equivalente de tu herramienta).

La instrucción va en el texto. Como la indicación “conviértelo en un skill” ya está al principio del texto copiado, basta con pegarlo una vez completo. Las herramientas con sistema de skills propio (por ejemplo, Claude Code/Cowork, OpenClaw, Hermes Agent) lo guardan entonces de forma permanente.

Funcionamiento continuo: casi en tiempo real

En lugar de iniciar cada pasada a mano, puedes hacer que el skill se ejecute de forma repetida. Cuanto más corto sea el intervalo, más se parece la colaboración al tiempo real: creas una tarea o escribes un comentario en una propuesta y, poco después, tu agente reacciona. El método exacto depende de la herramienta:

Herramienta Funcionamiento continuo (ejemplo)
Claude Code / Cowork Comando de bucle con intervalo, por ejemplo /loop 10m /tandem-worker
Codex CLI ejecución autónoma con el modo /goal o una ejecución --full-auto que repite el skill
OpenClaw tarea cron programada que lanza el skill a intervalos
Hermes Agent ya funciona de forma continua (24/7): haz que ejecute el skill en su programación
Genérico una entrada cron o un pequeño script que llama periódicamente a tu herramienta con /tandem-worker

La sintaxis exacta y la disponibilidad de estos mecanismos de bucle dependen de cada herramienta, no de TandemLoop; en caso de duda, consulta su documentación.

No dejes que varios agentes escriban a la vez. Si varias pasadas o varios agentes trabajan en paralelo en la misma carpeta de datos —sobre todo si se sincroniza a través de la nube—, pueden aparecer copias en conflicto o trabajo duplicado. Deja que escriba un solo agente cada vez y no elijas un intervalo más corto que una pasada habitual. Consulta también La carpeta de datos y el formato de archivo.

Conectar distintos agentes

El método es el mismo para cualquier herramienta con capacidad de agente: darle acceso a la carpeta de datos, indicarle AGENTS.md y pasarle el skill de trabajo. Dos ejemplos más allá de los citados en el capítulo anterior:

  • OpenClaw: un agente personal de código abierto que lee y escribe archivos locales, tiene su propio sistema de skills y ejecuta tareas programadas con cron. Lo apuntas a tu carpeta de datos y le das el skill de trabajo.
  • Hermes Agent: un agente de código abierto que funciona de forma continua, con acceso a archivos locales y su propio concepto de skills. Puede ocuparse de la carpeta de datos las 24 horas.

Como todos usan la misma carpeta de datos y el mismo contrato de trabajo (AGENTS.md), puedes combinar o cambiar de agente: mientras solo escriba uno cada vez, la base de tareas común se mantiene coherente.

El texto del skill para copiar

Copia el texto siguiente completo y dáselo a tu herramienta de IA. (Es idéntico al archivo de plantilla incluido docs/agent-skills/tandem-worker.md).

# /tandem-worker—Autonomous work cycle for TandemLoop

> **To the AI tool receiving this text:** Turn the following into a reusable skill (or a
> saved instruction / slash command) named `tandem-worker`. Run it whenever I say
> `/tandem-worker`—once or periodically in a loop. Requirement: you have read and
> write access to my TandemLoop vault folder.

One pass of an autonomous work cycle for a TandemLoop vault. You first collect the
human's answers to your handbacks, scan the vault for assigned, available tasks, check
open proposals for new feedback, work through tasks and hand results and questions back
to the human—always within the working agreement in `AGENTS.md`.

---

## Required reading

Read these files **once per session** (not on every pass). They are the binding source
of truth; this skill only describes the procedure.

| File | Provides |
|------|----------|
| `AGENTS.md` (vault root) | Working agreement: allowed/forbidden actions, directory structure |
| `_system/docs/data-model.md` | Fields, enums, required fields per entity |
| `_system/docs/proposal-system.md` | Proposal format, all action types, reference rules (only with proposals turned on) |
| `_system/docs/update-rules.md` | Write permissions, decision tree |

---

## Core principle

Tandem: the human sets the direction, the AI provides the power. Control always stays
with the human. Whether proposals are turned on is stated in `AGENTS.md`. This results in
three channels:

- **Allowed directly:** maintain the content of tasks with `assigned_to: ai` (title, body,
  `status`, date fields, `waiting_for`, `tags`, `delegation`, `repeat`, custom
  attributes). With proposals off, also create new things wherever they belong and
  change and move existing things (tasks, projects, milestones, areas, folders, views;
  create tags)—with a log entry on every changed task of the human. With proposals on,
  only new tasks in `_inbox/`. In both cases the exceptions in `AGENTS.md` apply
  (attribute definitions, themes, reminders at the human's request).
- **Only on request or as a proposal:** with proposals off, deleting, completing or
  dropping the human's tasks and changing specs—without a request, clarify it with a
  question (`needs-input`) on one of your own tasks; with proposals on, everything beyond
  the above **as a proposal** in `_proposals/`.
- **Communication & feedback:** through the **handback** (`status: needs-review` or
  `needs-input` + a handback note in the log), the **proposal discussion** and the
  **conversation log in the task body**—no separate message files, no workarounds via
  `waiting`, tags or `waiting_for`.

Never perform the forbidden actions listed in `AGENTS.md` (including `_system/`,
`_archive/`, `_conflicts/`, app settings in `_config/`, schema, restructuring directories)—not even as a
proposal.

---

## Phase 1: Orientation

First record your run: write `_config/agent.yaml` with exactly one line
`last_run: YYYY-MM-DDTHH:mm:ss` (current local time, no quotes). The app uses it to show
the human when you last worked.

### 1a) Collect the human's answers (before any new work)

- **Returns:** all tasks with `assigned_to: ai`, `status: active` and
  `handback_reply: revise` or `handback_reply: answered`. The newest `entry:human` entry
  holds the comment (`**Revise:** …`) or the answer (`**Answer:** …`; German vault:
  `**Nacharbeit:**` or `**Antwort:**`). Delete the
  `handback_reply` line right away when you pick the task up again—until then the app
  shows the task as "With the Agent". → Highest priority in phase 2.
- `handback_reply: accepted`, `taken-over` or `dropped`: nothing to do (approved, taken
  over, or dropped). Tasks in `needs-review`/`needs-input` are waiting for the human—leave
  them alone.
- Read **open proposals** in `_proposals/` (only with proposals turned on). On `status: revision_needed` or a new
  discussion entry from the human: incorporate the feedback, **revise the existing
  proposal in place** (adjust actions/title, update `modified`, add a new discussion
  entry with an explanation). Do not create a new proposal unless the human explicitly
  asks for a split. → Highest priority in phase 2.
- Also treat **assigned active tasks** (`assigned_to: ai`, `status: active`, no
  `handback_reply`) where the human commented in the body without a handback (newest
  entry is `entry:human`) as returns.

### 1b) Determine available tasks

A task is available when **all** conditions are met:

1. **Task:** `assigned_to: ai`, `status: active`, `waiting_for: null`, `defer_date` not in the future
   (tasks in `needs-review`/`needs-input` are never available—they are with the human)
2. **Project** (if any): `status: active`
3. **Milestone** (if any): `status: active`
4. **Sequence:** with `project_type: sequential`, formally only the first active task

Also scan `_inbox/` for tasks with `assigned_to: ai`.

**Think from the project goal, not from the task list.** Read all tasks of a project and
ask: "What has to happen next so this project reaches its goal (`success_criteria`)?"
That can mean: keep working, adjust the order (`sequence_order`), add missing tasks, or
merge redundant ones / mark them `dropped`. The task list is a tool; the project goal is
the truth. With proposals off, create missing tasks and reorder existing ones directly;
drop the human's redundant tasks only at their request (ask first). With proposals on, such adjustments
go through a proposal.

---

## Phase 2: Prioritization

Order of the available tasks:

1. **Returns** with feedback (from 1a)—always first
2. **Overdue**—`due_date` in the past
3. **Today**—`do_date` = today
4. **Delegation**—`do` before `draft` before `ask`
5. **Sequence**—lower `sequence_order` first

Choose by **complexity budget**, not by a fixed limit:

| Complexity | Examples | Share of budget |
|------------|----------|-----------------|
| Light | Fix a field, short research, vault maintenance | ~10% |
| Medium | Analysis, draft concept, compare options | ~30% |
| Heavy | Extensive concept, multi-step research, code feature | ~50% |

**Goal: 3–5 tasks per pass** (e.g., 1 heavy + 2–3 light, or 2 medium + 2 light).
Returns count as one task and do not block the pass.

**Review brake:** if **5 or more** of your tasks are already in `needs-review`, create no
new drafts (`draft`) in this pass—work on returns, `do` tasks and vault upkeep. The human
should not get more reviews than they can handle.

---

## Phase 3: Execution

For each task (or a related group of tasks in the same project):

1. **Load context:** task file, project file, milestone if any, and related material from
   the project's `reference_folder` (if set).
2. **Solve the task** according to its type:

| Task type | Approach |
|-----------|----------|
| Concept / strategy / research / analysis | Save the result as a file in the project's `reference_folder` (or, if none is set, summarize it in the task body) |
| Vault work | Carry it out directly on the assigned task (within the allowed fields) |
| Code | Own branch (`ai/<feature>`), work and commit locally there—never on `main`, no push without instruction |

**Obstacles are tasks.** Missing access, an awkward file format, information that is hard
to find—these are not limitations to note but subtasks to solve: write a script, use an
alternative source, change the approach. "Can't be done" is not an answer. The only
acceptable answers are: **"Done."** or **"I need X from the human to continue."**—the
latter as a question (`needs-input`, see phase 4).

> **Optional (depends on the tool):** If your AI tool supports parallel sub-agents with
> their own context, you can act as a "conductor": start one sub-agent per independent
> task with a complete briefing and let them work in parallel. This is an optimization,
> not a requirement—the cycle works just as well sequentially.

---

## Phase 4: Completing each task

Immediately after finishing a task (do not batch)—using TandemLoop's native mechanisms:

| Delegation | Completion |
|------------|------------|
| `do` | Task → `status: completed` (+ `completed_date`, `completed_by: ai`). Log entry in the body. Hand it back for review instead only if the result is risky/irreversible or explicitly requested. If the task has `repeat:`, the app creates the next occurrence—never create it yourself. |
| `draft` | Save the result; **hand the task back for review**: `status: needs-review` + handback note (`**For review:** …`). Never `completed` yourself. |
| `ask` | **Question**: `status: needs-input` + handback note (`**Question:** …`) with the concrete question, options numbered. |
| blocked (any mode) | **Question**: `status: needs-input` + handback note saying what you need. |

The handback note is a normal log entry (`entry:ai`): what you did, where the result is
(as a link), what the human should do or the question. In a German vault it starts with
`**Zur Prüfung:**` or `**Rückfrage:**`. Delete an existing
`handback_reply` line when handing back. Exact format and example: `AGENTS.md`,
"Handing a Task Back to the Human".

Update `modified` on every change. If completing the task needs something **new** or a
**restructuring** (follow-up task, project, milestone, tag, moving a task …), do it
directly when proposals are off (log entry on affected tasks of the human)—as a
**proposal** when they are on. Never **delete** without an explicit request.

**Conversation log in the task body** (format exactly as in `AGENTS.md` / `_system/docs/`):
Insert a new entry before the relations block, with the entry marker
`<!-- entry:ai:YYYY-MM-DDTHH:mm:ss -->`, the heading as given in `AGENTS.md` (English
vault: `## AI agent — YYYY-MM-DD`, German vault: `## KI-Agent — D.M.YYYY`) and a short
summary; link created artifacts and affected entities with wiki links.

---

## Phase 5: Next-action check

After execution, check for each affected project: **Does it still have a clear next
action?**

| Situation | Action |
|-----------|--------|
| A next active task exists | Fine—keep working or next pass |
| A task in `waiting`, `needs-review`, `needs-input` or an open proposal exists | Counts as a next action—the project is not stuck |
| No active task left | Proactively create a follow-up task (proposals off: directly in the project; proposals on: in the inbox or via a proposal) or note it in the project log |
| Project looks finished | "Complete project?" for a decision—as a proposal, or with proposals off as a question (`needs-input`) on one of your own tasks |

**No project may be left hanging without a next action.**

---

## Phase 6: Proactive

If capacity remains after the assigned tasks: **act instead of asking**, within the
working agreement.

- **Obviously right** → do it directly (if allowed) or as a proposal
- **Direction decision needed** → hand it back for review (`needs-review`) or as a proposal
- **Affects the human's life or external relationships** → ask (`needs-input`)

Proactively created entities carry `created_by: ai`. Make larger actions traceable in the
task/project log.

---

## Limits

Within the vault and the code repositories, the agent has wide freedom. Hard limits:

- **External communication**—no emails, messages or posts without instruction
- **`git push`**—only on explicit instruction (local commits and branches are free)
- **Deleting, completing or dropping the human's tasks, changing specs**—only on explicit
  request; restructuring as a proposal with proposals on, traceable with proposals off
  (log entry, summary)
- **Forbidden areas**—`_system/`, `_archive/`, `_conflicts/`, app settings in `_config/`,
  schema, directory structure (see `AGENTS.md`)
- **Private content**—personal notes/reflections remain reserved for the human

---

## Code projects: branch workflow

When a task involves code:

1. **Always a separate branch**—`ai/<feature-name>`
2. **Local commits are free**—no push without instruction
3. **Signal review**—hand the task back for review (`status: needs-review`), handback note with branch, changes and what to check
4. **The human decides on the merge**