Config as code

Asistenții, tools-urile, squads-urile și knowledge base-urile tale stau în git ca YAML declarativ, iar CLI-ul le reconciliază cu o organizație.

callagent init
callagent validate
callagent plan
callagent apply

Structura

callagent.yaml            mediile și variabilele lor
assistants/*.yaml
tools/*.yaml
squads/*.yaml
knowledge/*.yaml
policies/*.yaml
.callagent/state.<env>.json   id-urile remote de la ultimul apply — pune-l în gitignore

Medii (DEV/UAT/PROD)

Un singur set de fișiere de resurse descrie fiecare mediu. Diferențele stau în callagent.yaml și sunt substituite ca ${nume}:

version: 1
defaultEnvironment: dev
environments:
  dev:
    apiUrl: http://localhost:8000
    variables:
      serverUrl: http://localhost:8080/webhooks/callagent
  prod:
    apiUrl: https://api.callagent.dev
    protected: true          # `apply --auto-approve` refuză aici fără --force
    variables:
      serverUrl: https://example.com/webhooks/callagent

${env:NUME} citește în schimb o variabilă de mediu a procesului, pentru orice nu trebuie comis în git.

Numele câmpurilor

Fișierele folosesc vocabularul din @callagent/contracts — camelCase — pentru că aceea e schema față de care sunt validate. CLI-ul convertește în snake_case-ul API-ului la ieșire. Spațiile de chei care îți aparțin (metadata, variableValues, headers de HTTP, parameters de tool) sunt transmise neatinse, deci o cheie de metadata order_id rămâne order_id.

Fișierele sunt parțiale: ce nu menționează un fișier, serverul păstrează. Asta îți permite să ții system prompt-ul în git și să lași planul de analiză pe dashboard.

Cum arată un plan

Plan for Production (https://api.callagent.dev)

~ assistants.Support Line (01JQASSISTANT00000000000001)
    ~ model.temperature: 0.4 -> 0.9
    ~ firstMessage: "Hi, how can I help?" -> "Hi! How can I help today?"
    + endCallPhrases = ["goodbye"]

1 to create, 1 to update, 0 to delete, 3 unchanged

Pe câmpuri, cu valoarea reală de dinainte și de după. „Asistentul s-a schimbat" nu e un plan.

Potrivire, redenumiri și curățare

Fișierele locale se potrivesc cu înregistrările remote după, în ordine:

1. un id: explicit din fișier,
2. id-ul reținut în .callagent/state.<env>.json de ultimul apply,
3. name.

Din cauza lui (2), redenumirea unui asistent în git actualizează înregistrarea existentă, în loc să o șteargă și să creeze una nouă — ceea ce i-ar pierde istoricul de apeluri.

--prune propune ștergerea resurselor pe care le-a creat proiectul ăsta și pe care nu le mai declară. Resursele construite de cineva din dashboard nu sunt propuse niciodată pentru ștergere.

Cum îl adopți pe o organizație existentă

callagent init
callagent login
callagent export      # descarcă tot ca fișiere
callagent plan        # raportează: No changes

În CI

- run: callagent validate                 # iese cu 2 la un fișier greșit
- run: callagent plan --detailed-exitcode # iese cu 2 când configurația a deviat
- run: callagent apply --auto-approve --force
  env:
    CALLAGENT_API_KEY: ${{ secrets.CALLAGENT_API_KEY }}

apply continuă peste eșecurile individuale și raportează exact ce s-a aplicat și ce nu, deci o rerulare termină treaba. Aplicat de două ori, a doua oară nu schimbă nimic.

Ce nu se sincronizează încă

policies/ e validat local și nu e trimis niciodată: control plane-ul nu are încă un endpoint /api/v1/policies. plan și apply o spun, în loc să se prefacă.

Nici conținutul documentelor de knowledge nu se încarcă prin CLI. callagent apply creează și actualizează knowledge base-ul în sine; documentele se adaugă prin API sau din dashboard.