Samenwerken met AI

Zelfstandig en blijvend samenwerken

Inhoud

Zodra een AI-tool gekoppeld is (Een AI-tool koppelen), kun je de samenwerking structureel maken: met de meegeleverde worker-skill werkt je agent je gegevensmap zelfstandig af – op verzoek of doorlopend op de achtergrond, zodat jullie bijna in realtime samenwerken.

Eén gedeelde takenbasis voor jou en je agents

TandemLoop is allebei: je persoonlijke systeem om je leven en je projecten te beheren – en een gedeelde takenbasis waarop je met de meest uiteenlopende AI-agents samenwerkt. Omdat alles als eenvoudige bestanden in de gegevensmap staat, is die gegevensmap de gedeelde waarheid: jij plant en beslist, een of meer agents lezen dezelfde stand, doen voorstellen en voeren toegewezen werk uit. Geen enkele agent is vast ingebouwd, geen enkele is exclusief – je kunt tools wisselen of combineren, en ze werken allemaal verder aan dezelfde gegevens.

De worker-skill

De worker-skill is een compacte instructie die je aan je AI-tool geeft. Ze beschrijft een terugkerende werkcyclus:

  • eerst je reacties op zijn teruggaven ophalen en verwerken,
  • beschikbare taken die aan hem zijn toegewezen (assigned_to: ai) zoeken en op prioriteit afwerken,
  • open voorstellen (als ingeschakeld) controleren op nieuwe feedback van jou en ze herzien,
  • resultaten ter controle teruggeven of met een vraag aan jou teruggeven.

Ze houdt zich strikt aan de werkafspraken uit AGENTS.md: zonder voorstellen maakt ze nieuwe items aan en wijzigt ze bestaande items direct – terug te zien in het logboek van je taken – maar verwijdert ze alleen op jouw opdracht en voltooit of schrapt ze je taken niet op eigen houtje; met voorstellen dient ze alles wat de structuur raakt in als voorstel – jij houdt de controle.

Terug van de agent

Geef je taken aan de agent, dan krijg je ze ook terug: heeft hij iets voorbereid, dan geeft hij de taak ter controle terug; heeft hij een beslissing, informatie of aanlevering nodig, dan stelt hij een vraag. Elke teruggave bevat een notitie van de agent – wat hij heeft gedaan, waar het resultaat staat en wat jij moet doen, of zijn vraag.

Waar je teruggaven ziet:

  • In de navigatiekolom staat onder de Inbox Terug van de agent met het aantal openstaande teruggaven, daaronder – zodra die er zijn – apart Ter controle, Vraag en Bij de agent. Op de iPhone is het de tab Terug.
  • Overal waar de taak verschijnt – in projecten, weergaven, bord, tabel, kalender – heeft ze een eigen symbool: een tekstballon met een vinkje (ter controle) of met een vraagteken (vraag). Een klik erop toont de notitie opgemaakt met klikbare links, samen met de reacties.
  • In de details van de taak staat de teruggave helemaal bovenaan.

Zo reageer je – direct in de lijst, in het venster bij het symbool, in de details of in het contextmenu:

Reactie Effect
Accepteer (bij Ter controle) De taak is voltooid; vastgelegd blijft dat de agent haar heeft uitgevoerd en jij het resultaat hebt geaccepteerd
Laat verbeteren (bij Ter controle) Met een korte opmerking terug naar de agent
Antwoord (bij Vraag) Je antwoord gaat naar de agent, de taak ligt weer bij hem
Neem zelf over De taak wordt aan jou toegewezen
Schrap taak De taak wordt geschrapt

Elke reactie kun je via de melding onderaan met Herstel terugdraaien. Elke reactie komt samen met opmerking of antwoord in het logboek van de taak; zo blijft het heen en weer navolgbaar – wie wanneer wat heeft gezegd. Bij de volgende ronde herkent de agent je reactie ondubbelzinnig en pakt hij eerst verbeteringen en antwoorden op. In weergaven kun je filteren op de status Ter controle of Vraag, op @is_handback en op je reactie; in het bord verschijnen beide als eigen kolommen naast Actief.

Bij de agent: De agent draait buiten TandemLoop – de app kan hem niet starten. Tot hij je verbetering of antwoord oppakt, staat de taak in Terug van de agent onder Bij de agent, met de tijd sinds je reactie en het moment waarop de agent voor het laatst heeft gewerkt (dat legt hij bij elke ronde vast in _config/agent.yaml). Start dan je agent of geef hem via Kopieer briefing de juiste zin. Zodra hij de taak oppakt, verdwijnt die daar en krijg je een melding. Draait je agent regelmatig, bijvoorbeeld volgens een schema, dan hoef je niets te doen.

Hoe de agent teruggeeft, staat in AGENTS.md. Daar is het bestandsformaat beschreven (status: needs-review of needs-input en de notitie als logboekitem). Een agent kan dat zonder hulpmiddelen schrijven en lezen – ook als de app gesloten is.

Installatie: tekst kopiëren, aan de agent geven

Je installeert de skill door de tekst ervan aan je tool te geven – geen download, geen configuratiebestand.

  1. Richt de tool op de gegevensmap (zie Een AI-tool koppelen).
  2. Kopieer de skilltekst – volledig uit het gedeelte De skilltekst om te kopiëren aan het einde van dit hoofdstuk.
  3. Geef hem aan de tool. Plak de tekst in je AI-tool. De eerste regel van de tekst draagt de tool op er een herbruikbare skill met de naam tandem-worker van te maken – je hoeft dus verder niets uit te leggen.
  4. Roep hem aan. Daarna start je een ronde met /tandem-worker (of de overeenkomstige aanroep van je tool).

De instructie zit in de tekst. Omdat de opdracht “maak hier een skill van” al bovenaan de gekopieerde tekst staat, is het genoeg om hem één keer volledig te plakken. Tools met een eigen skillsysteem (bijvoorbeeld Claude Code/Cowork, OpenClaw, Hermes Agent) bewaren hem dan permanent.

Doorlopend gebruik: bijna in realtime meedraaien

In plaats van elke ronde met de hand te starten, kun je de skill herhaald laten uitvoeren. Hoe korter het interval, hoe meer de samenwerking als realtime voelt: je maakt een taak aan of schrijft feedback in een voorstel, en kort daarna reageert je agent. Hoe dat precies gaat, hangt af van het tool:

Tool Doorlopend gebruik (voorbeeld)
Claude Code / Cowork loop-commando met interval, bijvoorbeeld /loop 10m /tandem-worker
Codex CLI zelfstandige run via de /goal-modus of een --full-auto-run die de skill herhaalt
OpenClaw geplande cronjob die de skill met een interval start
Hermes Agent draait sowieso doorlopend (24/7) – laat de skill in zijn planning uitvoeren
Algemeen een cronregel of klein script dat je tool periodiek met /tandem-worker aanroept

De precieze syntaxis en beschikbaarheid van deze loop-mechanismen horen bij het betreffende tool, niet bij TandemLoop – kijk bij twijfel in de documentatie van dat tool.

Laat niet meerdere agents tegelijk schrijven. Als meerdere rondes of meerdere agents tegelijk dezelfde gegevensmap bewerken – vooral als die via de cloud wordt gesynchroniseerd –, kunnen conflictkopieën of dubbele bewerkingen ontstaan. Laat op elk moment maar één agent schrijven en kies het interval niet korter dan een gemiddelde ronde duurt. Zie ook De gegevensmap en het bestandsformaat.

Verschillende agents koppelen

De weg is voor elk agentisch tool dezelfde: toegang tot de gegevensmap geven, op AGENTS.md wijzen, de worker-skill overdragen. Twee voorbeelden naast de tools uit het vorige hoofdstuk:

  • OpenClaw – een opensource persoonlijke agent die lokale bestanden leest en schrijft, een eigen skillsysteem heeft en taken via cron op vaste tijden uitvoert. Je richt hem op je gegevensmap en geeft hem de worker-skill.
  • Hermes Agent – een opensource agent die doorlopend draait, met lokale bestandstoegang en een eigen skillconcept. Hij kan de gegevensmap de klok rond bijhouden.

Omdat ze allemaal dezelfde gegevensmap en dezelfde werkafspraken (AGENTS.md) gebruiken, kun je agents mengen of wisselen – zolang er telkens maar één tegelijk schrijft, blijft jullie gedeelde takenbasis consistent.

De skilltekst om te kopiëren

Kopieer de volgende tekst volledig en geef hem aan je AI-tool. (Identiek aan het meegeleverde sjabloonbestand 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**