## Agent

0. A conversation listát megvágjuk, hogy beleférjen a chat-LLM hívásba (maxTokens)

1. Egy elő LLM kérdésben beköthetjük a Routine-okat (a routinok afféle felülírók, megelőzik az utolsó üzenetet, de közben meg kell oldjuk valahogy, hogy az üzenet is feldolgozásra kerüljön, és a routine is érvényesüljön ha kell (van, hogy csak hozzá kell adjunk valamit a parancshoz))
  - mik alapján keresünk routine-okat:
    - session doing/goal/intent alapú micro routine-ok (vektor keresés; mindig amikor...)
    - egyéb micro routine-ok (vektor keresés; mindig amikor...)
    - idő alapú triggering
    - ???

2. Egy nagy LLM kérdésben megkérdezzük, hogy az utolsó user message teljesítéséhez... 
  - milyen operation-ök kellenek
    - itt felsoroljuk az elérhető operation-öket
    - Ez lehet több is. 
    - A: NONE | (operation-with-intent or get-operation-group-with-intent) list
  - kell-e a kódbázisban keresni
    - itt felsoroljuk az elérhető projekt-eket
    - ha igen, mire kell vektorkeressünk
    - A: NONE | vektor search keywords
  - kell-e a dokumentumok között keresni keresni
    - itt felsoroljuk az elérhető dokumentumokat/dokumentum tárakat (attól függően, hogy ne legyen túl sok opció)
    - ha igen, mire kell vektorkeressünk
    - A: NONE | vektor search keywords
  - kell-e a DB context-ben keresni
    - ha igen, mire kell vektorkeressünk
    - A: NONE | vektor search keywords
  - kell-e valamilyen specifikus context adat
    - itt felsoroljuk az elérhető specifikus context adatokat
    - ezek olyan speciális adatok amik fixek, és direkt method-okkal adjuk meg őket, 
      - pontos dátum-idő
      - user neve/nickneve/amin szólítsa a bot
      - user data
      - user settings
      - ... TODO: add more special context data keys
    - A: NONE | special context data key
  Mindegyik input lehet NONE, ami azt jelzi, hogy nincs rá szükség

3. Ha kell, bármilyen info, akkor először azokat gyűjtjük össze
  - a talált info-kat beletesszük a beszélgetésbe mint assistant message-ek
    (ezek valójában nem kerülnek elküldésre, a következő üzenet érkezésekkor nem fognak rendelkezésre állni, de elmentjük a db-be az egész conversation listát)

4. Ha kell, akkor lekérjük a kért operation-group-okat és abból újabb LLM kérdéssel összeszedjük a szükséges operation-öket
  - az operation-group-okat különféle módon szerezhetjük be
    - Group-olt operation-ök listázása
    - MCP Server-ről kérés
    - ... TODO: is there any more operation-group sources?

4. Ha kell, akkor végrehajtjuk a kért operation-öket
  - a végrehajtás eredményéről röviden beszámolunk/értesítjük a user-t, hogy mit sikerült és nem sikerült csinálni
    (nem csak a jelenlegi conversation listába tesszük be, hanem tényleg el is küldjük a user-nek egy message-et)

5. Egy újabb LLM kérdéssel kiszedjük az új context-et aminek be kell kerülnie a DB context-be
  - ha kell akkor a mentendő context-et kell visszaadja, ha nem akkor a NONE

6. Megválaszoljuk a user üzenetét

7. A végeredményt elmentjük a DB-be
  - minden llm kérdés-választ, 
  - és a result-okkal feltáplált conversation listát
  - a vektor keresések eredményeit
  - (not yet): ha nem messaging platformon vagyunk (discord/slack/teams), akkor chat session-ökbe mentjük az adatokat
    - ebben az esetben külön kell válogatni azokat a message-eket amiket elküldtünk a user-nek (conversation) attól amik az operation-ök végrehajtása során keletkeznek (logs)


## Operation-ök
  - az operation-ök lista kérésekor hangsúlyozzuk az LLM-nek, hogy mindig próbáljuk a leg apróbb lépésekből összeállítani a listát
  - minden operation úgy működik mint egy MCP Server kérés, adott egy input schema 
  - az input-ot a conversation alapján állítjuk össze, úgy hogy az operation intent kerül bele a conversation-be mielőtt egy LLM hívással megpróbáljuk összeállítani az inputot
    - az input-ok összeállításakor felhívjuk az LLM figyelmét, hogy a mentendő módosítandó adatokat csak akkor manipulálja, ha azt a user kérte, egyébként használjuk a user szava járását
  - az operation-ok mindig string-et kell visszaadjanak ami szintén a conversation-be kerül bele (ha obj-et kapunk vissza, akkor azt egyszerűen string-gé alakítjuk)
  - egyes operation-ök több lépéses operation-routine-okként hajtandóak végre (az LLM csak egy operation-t választ ki, de ha az egy operation-routine, akkor azokat hajtjuk végre sorban)

## Routine-ok

### Időalapú és Triggered routine-ok
  - olyan routine-ok amiket egy adott időpontban/idő után/időközönként hajtunk végre
  - ezek lehetnek olyan routine-ok is amiket nem egy felhasználói üzenet indít, hanem egy időpont, és ez után automatikusan üzenetet küld egy beállított default csatornára
  - lehetnek webhook trigger alapúak is
  - ezek lehetnek továbbá complex rutine-ok amik feladat folyamatokat indukálnak
    pl.: 
      - minden reggel nézd át az email-eket és az üzeneteket és amire tudsz válaszolj, amire pedig nem, azt beszéljük át
      - minden reggel gyűjtsd össze az aktuális top prio feladatokat és segíts megtervezni a napomat
      - ha új task kerül a rendszerbe, tervezd meg a megvalósítást (de mindenképpen egyeztess róla a PO-val)
      - az új task resolution plan-eket mindig validáltatssuk le a PO-val
      - mindig amikor új PR kerül fel az xy repo-ba akkor review-zz
  


### Micro routine-ok
  - olyan routine-ok amiket módosítanak a user input-on, 
    pl: mindig amikor kódokat generálunk, akkor figyeljünk oda, a hosszú sorok mindig törve legyenek (ilyenkor ezt mindig hozzáfűzzük a user message-hez)
  - a micro routine-okat a DB-be mentjük, a kulcs adatokat vektorizálva
  Adatok:
    - goal: mindig amikor...

### Egyéb
  - meg kell keresnünk azt a pontot és értelmezést, hogy hogyan tudunk segíteni a user-nek a gondolatai megfogalmazásában
    (talán a "2. Egy nagy LLM kérdés"-be bele vehetnénk, hogy ha a user bizonytalannak tűnik, vagy nem összeszedettnek akkor javaslunk egy összeszedettebb inputot, amit ha elfogad, akkor úgy kezeljük mintha a user küldte volna)






PROMPT
 Az NTS-be szeretnénk implementálni egy Operation Handler Agent-öt, ami ugye az NTS package-be fog bekerülni egy saját modulba, és ezt a modult fogjuk használni a projektek implementálásakor úgy, hogy az IO-Control-ba handleMessage-be kötjük be. 

Úgy kéne beépíteni ezt az Agent-öt, ahogy most is be van építve. Szóval ez az Agent modul, ez magában lesz. Megcsinál mindent, amit leírtunk ebbe a dokumentumban, specifikációba.  Azt már a projekt implementálásnál kell majd megadni, hogy a socket.io-ból behívjuk az agent-öt.



ezt a CCAP-ba az agent-2 module-ba fejlesztjük le mint POC/prototípus (not like agent module)









// TODO: we need to create a solution to create a maxed LLM call with 50-50% of the logs and the conversation
// the logs will go to the userPrompt, after the conversation, but we will need to cut them equally beside the system and control prompt (last user prompt)
// for the part that is before (both in log and conversation) we will need to be merged to a summary that is added as first (oldest element)