Fatih Arslan, „How I manage my agents” (2026-09-11)¶

Szerző: Fatih Arslan — Cursor-nál dolgozik, korábban Kubernetes operator-okat írt Forrás: https://arslan.io/2026/09/11/how-i-manage-my-agents/ Megjelenés: 2026. szeptember 11. Hossz: ~2265 szó angolul → ez a magyar összefoglaló 1820 szó Típus: vendor blog (Ghost CMS) — agent-orkesztációs workflow

Összegzés¶

A cikk középpontjában egy konkrét, működőképes „fleet of coding agents” workflow áll: dedikált git-repo plans/ mappával (drafts → next → open → done → discarded állapotgépezet), hosszú életű coordinátor agent-ek (amelyek nem írnak kódot, csak dispatchelnek és figyelnek), és a notes.md + handoff mechanizmus, ami bármely koordinátor összeomlása esetén 1 turn alatti újjászületést tesz lehetővé.
A nyolc fő skill (plan-init, plan-add, plan-write, plan-dispatch, plan-status, plan-sync, plan-retro, plan-spec) a Cursor Projects (2026. augusztusi bejelentés) köré épül: a coordinator a Project Context-ből dolgozik (notes.md, docs/, internal/, User Context), és a worker agent-ek dispatcher hívásra indulnak.
A gyakorlati kulcslépés a handoff: ha egy coordinator elromlik (Arslan 460 üzenet után akadt el bug-ban), a notes.md-ből az új koordinátor 1 turn alatt rebuild-eli az állapotot. Ez a „Kubernetes runs on feedback loops” filozófia — a cikk alcíme.
A lényeg nem a technológia, hanem a mappa-szerkezet + a git, mint state-store + a notes.md, mint handoff-dokumentum. Arslan hangsúlyozza: a skill fájlokat szándékosan nem teszi közzé, mert csak a saját 3 havi commit/PR/issue history-re szabva működnek jól, az olvasó feladata, hogy a saját history-jéből generálja a saját skilljeit.
A cikk kapcsolódik a mi saját rendszerünkhöz (Hermes + plan skill + skill-rendszer + git-repo) több ponton: a plans/ mappa-állapotgépezet kiegészíti a lineáris session-flow-t, a notes.md handoff a SOUL.md + USER.md + MEMORY.md cross-session persistence mintát erősíti, a coordinator koncepció a delegate_task worker-mintával rokon.

Bevezetés, a workflow genezise¶

Arslan a posztot egy önreflexív megjegyzéssel indítja: „There are probably hundreds of posts like this” — de hozzáteszi, hogy az elmúlt hónapokban hatalmas sikere volt ezzel a konkrét workflow-val, két különböző cégnél. A lényeg: minden agent-munka egy markdown fájl, ember által olvasható, és megosztható munkatársakkal vagy más agent-ekkel. A fájlok dedikált git-repo-ban élnek, ami egyben state-store-ként is működik (az agent-ek ismerik a git-et, és history jár ingyen).

A workflow idővel fejlődött: kezdetben random agent-ek kezelték a terveket, de Arslan áttért a long-running agent-ekre, amelyeket coordinator-oknak hív. Ezek a coordinator-ok olvasnak és írnak a repo-ba, ők az „orchestra conductor” a worker agent-ek számára.

A nyolc skill és a `plans/` mappa-állapotgépezet¶

A kiindulópont a /plan-init skill, ezt egyszer hívjuk a plans-repo-ban, és soha többé. Létrehoz egy mappa-struktúrát és egy README.md indexet:

plans/
  README.md
  drafts/
  next/
  open/
  done/
  discarded/

A nyolc skill a mappa-szerkezetre épül:

/plan-add, nyers ötletek mentése Slack-üzenetből vagy alkalmi gondolatból a drafts/ mappába. A cél: „free up your thoughts”, azaz ne felejtsd el az ötletet, amíg friss. A draft nem igényel döntést, csak az ötletet és egy area-prefixet (hub-, storage-, stb.).
/plan-write, magasabb reasoning modellel (Arslan „higher reasoning model”-t használ) a draft-ból konkrét tervet ír: ok, design döntések, parancsok amik bizonyítják a megoldást. Az eredmény a next/ mappába kerül.
/plan-dispatch, a terv diszpécselése egy worker agent-nek. A terv már minden szükséges döntést tartalmaz, tehát a worker nem kérdez vissza. A worker a tervet a next/-ből open/-ba mozgatja, majd dolgozik.
/plan-sync. PR merge-ek ellenőrzése a worker output-ja ellen. Ha a merge kész, a terv done/-ba kerül. Ha valami hiányzik, visszakérdez.
/plan-status, dashboard riport: mi vár merge-re, mi blokkolt, melyik draft írható most.
/plan-retro, periodikus (vagy session végi) visszatekintés, ami a history-ből frissíti a skill-eket.
/plan-spec, a plan-spec a mappa-struktúrát és a terv-fájl formátumot írja le, és a többi skill először ezt olvassa.
/plan-init, a fenti struktúrát létrehozó egyszeri setup skill.

A kulcs-design: a drafts/ → next/ → open/ → done/ mappa-szerkezet állapotgépezetként működik, és a git history ingyen adja a visszatekintést. Egy terv nem lesz done/-beli, amíg a PR valóban merge-elt. Egy terv nem kerül a discarded/-ba csak azért, mert Arslan meggondolta magát, ez is tudás, és a git megőrzi.

Coordinator-ok, a hosszú életű agent-ek¶

A coordinator koncepció a Cursor 2026. augusztusi Projects bejelentéséhez kötődik. Egy Project három dolgot ad a coordinator-nak, amit egy átlagos worker agent nem kap meg:

Diszpécselési képesség, új chat session-öket indíthat a cloud-ban, a lokális gépen, vagy egy távoli gépen (akár a user iPhone-járól is). Az alapértelmezett egy friss Cloud Agent, ami a Project Context-et is megkapja.
Project Context, saját fájl-rendszer a Project-en belül:
notes.md, a Project „README.md”-je, de dinamikus, és csak a coordinator írja
docs/ és /media mappa, emberi olvasásra
internal/ mappa, agent scratch fájlok, az ember nem nyitja meg
User Context (globális), preferences.md (olyan, mint az AGENTS.md, de nem jut el a worker-ekhez), és egy skills/ mappa, ahova a saját skilljeinket szinkronizálhatjuk
Subscriptions, a coordinator figyelhet PR-eket, Slack-csatornákat, vagy időzített hívásokat. Arslan minden PR-re feliratkozik, amit a worker-ek nyitnak, és amikor a CI lefut vagy reviewer comment-et ír, a coordinator felébred, visszaküldi a worker-t javítani, majd merge után leiratkozik.

A coordinator-ok nem írnak kódot, csak dispatchelnek. Ez a szétválasztás a kulcs: a worker izolált és gyors, a coordinator tartja az állapotot és a kapcsolatot a külvilággal.

Handoff, a notes.md mint állapot-rebuild forrás¶

A handoff a coordinator-ok legfontosabb tulajdonsága. Arslan konkrét példát hoz: a Projects beta tesztje során egy platform bug 460 üzenet után hibába loop-olta a coordinator-át. Arslan kért egy handoff-ot, indított egy friss Project-et, és az új coordinator 1 turn alatt rebuild-elte az állapotot a repo-ból.

Ennek az az alapja, hogy minden state-változás a git-be commitolódik ugyanabban a turnben, amikor keletkezik:

docs/
  billing/coordinator-notes.md
  storage/coordinator-notes.md
  fleet/coordinator-notes.md
  hub/coordinator-notes.md

Minden Project azonos struktúrát használ (Goal, PRs, Open, Next, Drafts, Done, Links, Research), tehát az új coordinator azonnal tudja, hol tart. A coordinator-ok nem tudnak egymásnak üzenetet küldeni, és nem olvashatják egymás Context-jét (csak a globális User Context-et), ez szándékos izoláció. Ha egy coordinator át akar adni valamit egy másiknak, a git-be írja.

A Recap és a kiinduló prompt¶

A cikk utolsó szakasza egy konkrét promptot ad, amit az olvasó futtathat a saját agent-jén:

Read https://arslan.io/2026/09/11/how-i-manage-my-agents/ in full. Then look at how I actually work
before you write anything: go through my last three months of commits and pull requests, the issues or
tickets I opened and closed, and, if you can reach them, the chat channels where I ask for work and
report on it.

Write down what repeats: how I phrase a task, what I check before I call something done, which
mistakes I correct more than once, and where my work waits on other people. From that, create the
plan skills from the post (plan-init, plan-add, plan-write, plan-dispatch, plan-status, plan-sync,
plan-retro), plus a plan-spec skill that holds the folder layout and the plan file format the
others read first, as skill files in my Cursor skills folder, written for my habits and not for
the author's: my folder names, my commit and PR format, the checks I run, the people and systems
my plans depend on.

Keep each skill under two pages, in plain English, and name the exact commands it runs. Where my
history shows I do something differently from the post, follow my history. When you are done, walk
one made-up plan through the whole loop so I can see them work together, then stop. Commit nothing
until I have read it.

Arslan hangsúlyozza: a skill fájlokat szándékosan nem publikálja. Az ő promptja az olvasó saját history-jére szabja a generált skill-eket, ami működik nála, nem biztos, hogy másnál is működik. A kulcsszó: „Commit nothing until I have read it.” A user review-ja kötelező, mielőtt bármi bekerül a rendszerbe.

A cikk kulcs-tanulságai¶

A mappa-állapotgépezet fontosabb, mint a technológia. A drafts/ → next/ → open/ → done/ struktúra önmagában értékes, és bármely más workflow-ra alkalmazható.
A git, mint state-store, ingyen ad history-t. Ez a Kubernetes-operátor-mentalitás: a rendszer állapota a git-ben van, nem egy adatbázisban.
A coordinator-worker szétválasztás csökkenti a komplexitást. A worker izolált és gyors, a coordinator tartja az állapotot. Egyik sem csinálja a másik dolgát.
A notes.md a legkritikusabb fájl. Ez a handoff alapja, és ha elveszik, az egész rendszer összeomlik.
A skill fájlok nem transzferábilisek. A saját history-ből kell generálni őket, ez nem lustaság, hanem szükségszerűség.

Forrás¶

Cikk: Fatih Arslan, „How I manage my agents” (2026. szeptember 11.)
URL: https://arslan.io/2026/09/11/how-i-manage-my-agents/
Hossz: ~2265 szó angolul (képek és a „Related posts” widget nélkül)
Szerző: Fatih Arslan (Cursor, korábban Kubernetes operator-ok)
Egyéb cikkek a szerzőtől: „Kubernetes runs on feedback loops”, „I was wrong about AI Coding”, „My Homelab Setup”

Kapcsolódó külső források¶

Cursor Projects bejelentés, https://cursor.com/blog/projects, a koordinátor-koncepció alapja
Cursor Cloud Agents, https://cursor.com/cloud, a worker agent-ek, amiket a coordinator dispatchel
„I was wrong about AI Coding” — https://arslan.io — Arslan korábbi önreflexív posztja az AI coding elfogadásáról

Kapcsolódó belső források¶

a meglévő plan skill (single-file .hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md), ami a recipe 5. lépésének felel meg
az article-pipeline validált recept (2026-08-21, Sean Goedecke)
a Substack/Medium cikk-feldolgozás mintája (user-agent spoofing + <article> regex)
a 8-lépéses podcast-pipeline (8. lépés: SOHA ne hívd a deploy-wiki.sh-t a pipeline-ból)

Hogyan kapcsolódik ez a saját rendszerünkhöz¶

plans/ mappa-állapotgépezet ↔ lineáris session-flow, a mostani rendszerben a session lineáris (kapott feladat → végrehajtás → frissítés), és a hosszabb távú gondolatok a MEMORY.md-ben gyűlnek (ami 2172/2200 char tele van). A drafts/ → next/ → done/ mappa-szerkezet egy állapotgépezetes kiegészítés, ami a lineáris session-öket nem zavarja, de a hosszabb távú ötleteknek strukturált helyet ad.
notes.md handoff ↔ SOUL.md + USER.md + MEMORY.md, a mi cross-session persistence-ünk implicit (új session olvas SOUL + USER + MEMORY). Arslan rendszere explicit és tesztelt: a handoff a notes.md-ből 1 turn alatt rebuild-eli az állapotot. A frissen bevezetett (2026-09-17) ugyanezt a koncepciót adaptálja a saját rendszerünkre.
Coordinator-worker szétválasztás ↔ delegate_task worker-minta, a delegate_task toolunk már most is tud izolált worker-eket spawnolni (a delegate_task leírása szerint). A coordinator-koncepció egy hosszú életű, git-state-tartó változata ennek. A különbség: a mi worker-eink frissen indulnak, a coordinator-ok hosszú életűek, ez nagyobb bizalmi ugrás, amit érdemes megvitatni, mielőtt bevezetnénk.
Skill fájlok a skills/ mappában ↔ skill-rendszer, a mi rendszerünk 65+ skill-je a git-repo-ban van (2026-09-07 óta). Arslan tanácsa, hogy a skill fájlokat a saját history-ből generáljuk, nem másoljuk, ez a mi esetünkben a self-improvement-discipline skill (SOUL.md + USER.md + MEMORY.md szerkesztés) és a skill-library-maintenance skill (batch lintelés) mintát követi.
preferences.md (User Context) ↔ USER.md + MEMORY.md. Arslan preferences.md-je csak a coordinator-nak szól, a worker-ek nem látják. A mi USER.md-nk és MEMORY.md-nk a modellnek is átadódik (rendszerüzenet-injection). Egy külön preferences.md a rendszerüzenet-szintű operátori viselkedést formálná anélkül, hogy a modell válaszait közvetlenül befolyásolná, ez egy jövőbeli lépés, amit érdemes megvitatni.
/plan-retro ↔ self-improvement-discipline, a mi self-improvement-discipline skillünk a SOUL.md és USER.md módosításait critique + boundary check + robustness gate-en keresztül engedi. Ez részben átfedésben van Arslan /plan-retro-jával, de a mi skillünk manuális review-val működik, nem automatikus history-elemzéssel. A kettő kiegészíti egymást.