Agenți AI Autonomi. Fluxuri B2B executate asincron.

Blocaje pe care le eliminăm

• Scripturi fragile și cron-uri rigide

  Automatizările clasice crapă la primul CSS selector schimbat sau response shape modificat. Cron-urile rulează pe orar fix, nu pe semnal — și nu știu să se adapteze. Agenții se calibrează dinamic: când schema unui API se schimbă, agentul detectează și își ajustează strategia, nu pică în loop de retry-uri.

• Echipe IT/Ops sufocate de triaj

  Timpul scurs pe task-uri L1 e timpul în care echipa de inginerie nu construiește. Resetări de parolă, normalizare log-uri, citire de runbook pentru a răspunde la același tichet de 50 de ori — astea sunt sarcinile pe care agentul le preia. Operatorii rămân pe excepții reale, nu pe coada de cereri repetitive.

• Risc de eroare umană la data entry

  Mutarea manuală a datelor din 4 Excel-uri într-un SQL sau CRM produce inconsistențe care costă zile de reconciliere. Tipo-uri în SKU, formate de dată amestecate, câmpuri obligatorii lipsă. Agentul nu obosește și nu greșește la copy-paste — dar lasă audit trail pe fiecare scriere.

Arhitectura. Stack-ul. Compromisurile.

• Tool registry & permisiuni

  Agentul nu are acces la stack, are acces la o listă de unelte declarate: fiecare cu schemă de input, scope de credențiale și marcaj citire/scriere. Uneltele de scriere trec obligatoriu prin aprobare umană. Ce nu e în registry nu poate fi apelat, deci suprafața de risc e o listă pe care o poți citi într-un minut, nu un prompt în care speri.

  • MCP
  • OpenAPI
  • RBAC

• Execuție & stare

  Un run e o secvență de pași persistați, nu un apel lung care moare la timeout. Fiecare pas e idempotent și își scrie rezultatul înainte de următorul, deci un worker căzut reia din ultimul pas confirmat, fără să retrimită emailul deja trimis. Retry exponențial pe erori tranzitorii, oprire imediată pe erori de validare.

  • Queue workers
  • Retry exponențial
  • Pași idempotenți

• Observabilitate & evaluare

  Fiecare run lasă un trace complet: prompt, unelte apelate cu argumente, rezultate, decizia finală. Peste el rulează un set de cazuri de evaluare cu răspuns așteptat, executat la fiecare schimbare de prompt sau de model — așa vezi regresia înainte de deploy. Fără evaluare, un agent nu se degradează vizibil; se degradează în tăcere.

  • Tracing per run
  • Seturi de evaluare
  • Alerting

Cum lucrez

1. 01

   Orchestrare & Tool Calling

   Stack Python — LangChain, CrewAI sau MCP, ales după complexitate. Definim explicit ce unelte are agentul: API-uri interne autentificate, interogări SQL strict read-only (sau write cu approval), webhooks pentru evenimente externe. Nimic nu se execută fără declarare în tool registry — zero surprise calls.

2. 02

   Prompt Engineering & Validare

   Nu lăsăm modelul să „ghicească" pașii. System prompts construite ca state machines — fiecare rută posibilă pre-validată cu test cases reale. Output-ul agentului trece printr-un schema validator (JSON schema / Zod) înainte să ajungă la layer-ul de execuție. Drift-ul de comportament e detectat la prima rulare, nu în producție peste 3 săptămâni.

3. 03

   React Dashboard & Human-in-the-Loop

   Pentru orice acțiune mutantă (DELETE, UPDATE sensitive, email trimis în nume oficial), agentul se oprește, pregătește draft-ul cu payload complet și solicită aprobare via dashboard SPA în React. Operatorul vede ce s-ar întâmpla, audit trail-ul, sursele consultate — și decide cu un click. Approve / Reject / Edit, fără să copieze comenzi în terminal.

Întrebări frecvente

• Poate agentul să șteargă sau să strice date din greșeală?+

  Imposibil prin design. Toate acțiunile mutante (write, DELETE, UPDATE) sunt blocate de Human-in-the-Loop — agentul pregătește draft-ul, dashboard-ul afișează diff-ul, omul apasă Approve. Plus RBAC strict la nivel de tool — agentul nu are credențiale care depășesc scope-ul agreat. Zero override automat.
• Prin ce diferă de un simplu ChatGPT?+

  ChatGPT e o interfață de chat. Un agent autonom BaseTech folosește tool use pentru a executa cod, a apela API-uri și a naviga asincron prin stack-ul tău corporativ — toate sub un protocol pe care îl scriem și îl validăm noi. Chat-ul răspunde la prompt. Agentul livrează rezultatul.
• Ce se întâmplă când agentul întâlnește o excepție necunoscută?+

  Fail-safe: agentul nu improvizează. Loggează cazul în Sentry sau alerting-ul tău, atașează contextul complet (input, tool calls făcute, output parțial, stack trace) și escaladează la operator uman cu prioritate marcată. Tăcerea agentului e zgomot pentru sistem — nimic nu se pierde.
• Cum controlați costul de tokeni?+

  Prin rutare pe model, nu prin speranță. Pașii mecanici — clasificare, extragere, validare — merg pe modelul mic; doar pasul care cere raționament merge pe cel mare. Contextul e tăiat la ce e relevant, rezultatele repetate sunt cache-uite, iar fiecare run își înregistrează costul, deci vezi ce task consumă bugetul. Există și limită dură per run, ca un loop să nu se transforme în factură.
• Ce se întâmplă când apare un model mai bun?+

  Modelul e configurație, nu arhitectură. Orchestrarea, uneltele și validarea de output rămân aceleași, iar schimbarea providerului e o variabilă de mediu plus o rulare a setului de evaluare pentru comparație. Așa poți trece pe un model nou pentru că măsori că e mai bun pe cazurile tale, nu pentru că scrie asta în anunțul de lansare.