સંવાદાત્મક AI એજન્ટ અંદરથી કેવી રીતે કામ કરે છે

AI સંવાદાત્મક એજન્ટ અંદરથી કેવી રીતે કામ કરે છે (OpenClaw આર્કિટેક્ચર)

AI સંવાદાત્મક એજન્ટ કેવી રીતે કામ કરે છે વ્યવહારમાં, ટર્ન બાય ટર્ન? આ પોસ્ટ OpenClaw ની બ્લેક બોક્સ ખોલે છે: ગ્રાહકનો સંદેશ WhatsApp પર આવે ત્યારથી લઈને એજન્ટ જે ટેક્સ્ટ પાછો લખે છે ત્યાં સુધી. આ ટેકનિકલ હશે. જો તમે પ્રોડક્ટ આર્કિટેક્ચરના નિર્ણયો લો છો, જો તમે કોઈ સોલ્યુશન ખરીદવા જઈ રહ્યા છો અને ઊંડાણપૂર્વક મૂલ્યાંકન કરવા માંગો છો, અથવા જો તમને વાતચીતની પાછળ શું થઈ રહ્યું છે તે જાણવામાં રસ છે, તો આ વાંચવું યોગ્ય છે.

TL;DR: દરેક ટર્ન 6 તબક્કામાંથી પસાર થાય છે — ingest, કોન્ટેક્સ્ટ રિઝોલ્વ, skills પસંદગી, આગળની ક્રિયાનો નિર્ણય, guard-rails સાથે એક્ઝિક્યુશન, મેમરી પર્સિસ્ટ. આખું ચક્ર Cloudflare ની edge પર <2 સેકન્ડમાં ચાલે છે, કોઈ ફિક્સ્ડ સર્વર વિના.

---

આર્કિટેક્ચર શા માટે મહત્વપૂર્ણ છે

સંવાદાત્મક એજન્ટ જે ડેમોમાં કામ કરતો દેખાય છે પણ પ્રોડક્શનમાં તૂટી જાય છે, તેમાં સામાન્ય રીતે આ 4 સમસ્યાઓમાંથી એક હોય છે:

1. ઊંચી લેટન્સી — ગ્રાહક જવાબ માટે 8 સેકન્ડ રાહ જુએ છે, વાતચીત મરી જાય છે.
2. અનિયંત્રિત હેલ્યુસિનેશન — એજન્ટ ભાવ, સમય, પોલિસી ઉપજાવી કાઢે છે.
3. ખોવાયેલો કોન્ટેક્સ્ટ — ગ્રાહક 2 દિવસ પછી પાછો આવે છે અને એજન્ટ બધું "ભૂલી" જાય છે.
4. અનિયંત્રિત ખર્ચ — દરેક લાંબી વાતચીત પ્રોમ્પ્ટ ભરી દે છે અને તમે ટોકનમાં ભારે રકમ ચૂકવો છો.

આ ચારેય આર્કિટેક્ચરની પસંદગીઓ છે, મોડેલની મર્યાદાઓ નહીં. OpenClaw આ ચારેયને ટાળવા માટે બનાવવામાં આવ્યું છે — અને સમજવાનો રસ્તો એક ટર્નના ચક્રને જોવાનો છે.

---

એક ટર્નનું ચક્ર (6 તબક્કા)

કલ્પના કરો કે ગ્રાહકે હમણાં જ "quero marcar pra sábado de manhã" સંદેશ મોકલ્યો. "received" અને એજન્ટના જવાબ વચ્ચે શું થાય છે?

તબક્કો 1 — Ingest (edge worker, <50ms)

WhatsApp નો સંદેશ Meta ના webhook દ્વારા સીધો ભૌગોલિક રીતે સૌથી નજીકના પોઈન્ટ ઓફ પ્રેઝન્સ (PoP) પરના Cloudflare Worker પર આવે છે. બ્રાઝિલમાં, આનો અર્થ સાઓ પાઉલો અથવા રિયો છે, નેટવર્ક લેટન્સી < 20ms.

Worker ત્રણ કામ કરે છે:

1. Webhook ની સિગ્નેચર વેલિડેટ કરે છે (WABA ના સિક્રેટ સામે HMAC).
2. રિસીવરના ફોન નંબર દ્વારા ટેનન્ટ ઓળખે છે (multi-tenant to_number દ્વારા).
3. Payload ને નોર્મલાઈઝ કરે છે — ઓડિયો ટ્રાન્સક્રિપ્શનમાં બદલાય છે, ઈમેજ વર્ણનમાં બદલાય છે, લોકેશન {lat,lng} માં બદલાય છે, ટેક્સ્ટ જેમ છે તેમ રહે છે.

તબક્કો 1 ના અંતે તમારી પાસે આગળના પગલા માટે તૈયાર {tenant_id, conversation_id, user_message} ઓબ્જેક્ટ હોય છે.

તબક્કો 2 — કોન્ટેક્સ્ટ રિઝોલ્વ (D1 + KV, ~80ms)

એજન્ટને નિર્ણય લેતા પહેલા કોન્ટેક્સ્ટના 3 ભાગોની જરૂર છે:

• વાતચીતનો તાજેતરનો ઇતિહાસ (છેલ્લા N સંબંધિત ટર્ન્સ).
• ગ્રાહકની લાંબા ગાળાની મેમરી (પસંદગીઓ, ખરીદીનો ઇતિહાસ, નોંધો).
• એજન્ટની સ્થિતિ (પર્સોના, સક્ષમ કરેલી skills, નિયમો).

આ બધું D1 (Cloudflare નું વિતરિત SQLite) માંથી આવે છે. D1 પરંપરાગત Postgres/Mongo ને બદલે છે — જાળવવા માટે કોઈ ડેટાબેઝ સર્વર નહીં, worker માંથી થોડી ms માં ઍક્સેસ, tenant_id દ્વારા multi-tenant.

મુખ્ય મુદ્દો: આપણે આખી વાતચીત prompt માં લોડ કરતા નથી. OpenClaw નો Memory Manager v2 (અમારા આંતરિક દસ્તાવેજીકરણ માં વર્ણવેલ) વર્તમાન ટર્ન માટે ફક્ત સંબંધિત ટર્ન્સ પસંદ કરે છે (છેલ્લા N + ઉચ્ચ સિમેન્ટિક સુસંગતતા ધરાવતા N). આ 100+ ટર્ન્સની વાતચીતમાં પણ ટોકન ખર્ચને અનુમાનિત રાખે છે.

તબક્કો 3 — Skills ની પસંદગી (policy engine, ~20ms)

દરેક એજન્ટ પાસે ઉપલબ્ધ skills નો સમૂહ હોય છે — ફંક્શન્સ જે તે invoke કરી શકે છે. ઉદાહરણો: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"મારે શનિવારે સવારે બુક કરવું છે" સંદેશ મળતાં, policy engine ફિલ્ટર કરે છે:

• શોધાયેલ ઈરાદા (શેડ્યુલિંગ) સાથે સુસંગત Skills.
• વાતચીતના આ તબક્કા માટે મંજૂર Skills (દરેક skill હંમેશા ઉપલબ્ધ હોતી નથી).
• આ tenant એ સક્ષમ કરેલી Skills (calendar ફક્ત ત્યારે જ દેખાય છે જ્યારે tenant એ ઇન્ટિગ્રેટ કર્યું હોય).

અંતે તમારી પાસે model ને પસાર કરવા માટે skills નો એક નાનો ઉપસમૂહ હોય છે — 50 સંભવિત નહીં, ફક્ત 4 જે અહીં અર્થપૂર્ણ છે. આ model દ્વારા ખોટી skill invoke થવાની શક્યતાને ભારે ઘટાડે છે.

તબક્કો 4 — નિર્ણય (LLM call, 400-1200ms)

હવે model પ્રવેશ કરે છે. OpenClaw એક ફ્રન્ટિયર LLM (Anthropic Claude, OpenAI GPT, Google Gemini — tenant દ્વારા ગોઠવી શકાય તેવું) ને એક જ કૉલ કરે છે:

• System prompt = એજન્ટની પર્સોના + નિયમો + ઉપલબ્ધ skills.
• History = તબક્કા 2 માં પસંદ કરેલા ટર્ન્સ.
• User message = વર્તમાન ટર્નનો સંદેશ.

Model બે માંથી એક વસ્તુ સાથે જવાબ આપે છે:

• અંતિમ જવાબ (ગ્રાહક માટે સીધો ટેક્સ્ટ).
• Tool call (ચોક્કસ પેરામીટર્સ સાથે ચોક્કસ skill ચલાવવાની વિનંતી).

"મારે શનિવારે સવારે બુક કરવું છે" ઉદાહરણમાં, model સામાન્ય રીતે આ પરત કરે છે:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

તબક્કો 5 — Guard-rails સાથે અમલીકરણ (ચલ, ~100-500ms)

Skill model માં ચાલતી નથી. તે અમારા કોડમાં ચાલે છે, જે:

1. પેરામીટર્સ માન્ય કરે છે (date_range નું ફોર્મેટ સાચું છે? તે tenant ના નિયમોમાં આવે છે?).
2. પરવાનગી તપાસે છે (આ એજન્ટને આ કેલેન્ડર જોવાનો અધિકાર છે?).
3. કૉલ એક્ઝિક્યુટ કરે છે (આ કિસ્સામાં Google Calendar API).
4. સ્ટ્રક્ચર્ડ પરિણામ પરત કરે છે મોડેલને.

આ શા માટે મહત્વનું છે? કારણ કે મોડેલ ક્યારેય પરિણામ બનાવટી નથી બનાવતું. જો કેલેન્ડર [10h, 11h] પરત કરે, તો બરાબર એ જ આગળની કૉલમાં જાય છે. જો skill નિષ્ફળ થાય, તો મોડેલ જાણે છે કે તે નિષ્ફળ થયું. એજન્ટ 9 વાગ્યે સમય છે એવું "શોધી કાઢે" તેનું શૂન્ય જોખમ — જ્યારે ખરેખર નથી.

સંવેદનશીલ માહિતી (કિંમત, સમયમર્યાદા, ગ્રાહકનું નામ) સંબંધિત કિસ્સાઓ માટે, pipeline tool call ફરજિયાત કરે છે — મોડેલને પોતાના "જ્ઞાન"માંથી જવાબ આપવા દેતું નથી. આ વ્યાપારી એજન્ટ્સમાં સૌથી સામાન્ય ભ્રમણાના વર્ગને દૂર કરે છે.

સ્ટેજ 6 — પ્રતિસાદ અને પર્સિસ્ટન્સ (~50ms)

Skill નું પરિણામ હાથમાં આવ્યા પછી, મોડેલ બીજી કૉલ કરે છે — હવે ગ્રાહક માટે અંતિમ પ્રતિસાદ બનાવવા. ઉદા:

"મારી પાસે શનિવારે 10 અને 11 વાગ્યે છે. કયું પસંદ કરશો?"

સમાંતર રીતે, worker:

1. WhatsApp API દ્વારા સંદેશ પાછો મોકલે છે.
2. D1 માં સંપૂર્ણ ટર્ન (user + assistant + tool calls + સમયગાળો) પર્સિસ્ટ કરે છે.
3. જો ટર્ને નવી હકીકત ઉત્પન્ન કરી હોય (ઉદા: "ગ્રાહક શનિવાર પસંદ કરે છે") તો લાંબા ગાળાની મેમરી અપડેટ કરે છે.
4. ઓબ્ઝર્વેબિલિટી ઇવેન્ટ ઉત્સર્જિત કરે છે (લેટન્સી મેટ્રિક, ટોકન ખર્ચ, એસ્કેલેશન દર).

આ બધું સમાંતર ચાલે છે. પર્સિસ્ટન્સ સંદેશ મોકલવાને બ્લોક કરતું નથી — ગ્રાહક D1 ની રાહ જોતો નથી.

---

ભ્રમણા સામે સંરક્ષણ ક્યાં છે

પ્રોડક્શનમાં ભ્રમણા કરતો એજન્ટ ઝડપથી વિશ્વાસ ગુમાવે છે. OpenClaw પાસે સંરક્ષણની 4 રેખાઓ છે:

1. ફરજિયાત source-of-truth. હકીકતલક્ષી ડેટા (કિંમત, સમય, નામ) હંમેશા skill માંથી આવે છે, ક્યારેય એકલા મોડેલમાંથી નહીં.
2. સંવેદનશીલ ડેટામાં ડબલ ચકાસણી. એપોઇન્ટમેન્ટ પર્સિસ્ટ કરતા પહેલા ગ્રાહક સાથે પુષ્ટિ કરવામાં આવે છે. ઍક્સેસ આપતા પહેલા ચુકવણીની પુષ્ટિ કરવામાં આવે છે.
3. સ્પષ્ટ નકારાત્મક નિયમો. દરેક એજન્ટની પર્સોનામાં "ક્યારેય X, Y, Z શોધી ન કાઢો" શામેલ છે — મોડેલ પાલન કરે છે.
4. માનવ તરફ ફૉલબેક. જ્યારે કોઈ skill પ્રશ્નને આવરી ન લે, ત્યારે એજન્ટ "ચાલો હું ટીમ સાથે ચકાસી લઉં" કહે છે અને ટિકિટ ખોલે છે — અંદાજ લગાવતો નથી.

છેલ્લા 6 મહિનામાં અમે કરેલા ઓડિટ્સમાં (ખરેખર વાતચીતો મેન્યુઅલી સમીક્ષા કરવામાં આવી), હકીકતલક્ષી ભ્રમણાનો દર ટર્ન્સના 0.3% થી નીચે રહ્યો — અને લગભગ તમામ કિસ્સાઓ config ને કારણે હતા (tenant સંબંધિત skill સક્ષમ કરવાનું ભૂલી ગયો), મોડેલની ભૂલ નહીં.

---

પ્રતિ વાતચીત ખર્ચ

સારી આર્કિટેક્ચર ત્યાં સુધી અદૃશ્ય હોય છે જ્યાં સુધી તમે બિલ ન જુઓ. જોતાં કે દરેક ટર્ન 1-2 LLM કૉલ્સ + D1 લુકઅપ્સ કરે છે, પ્રતિ સંપૂર્ણ વાતચીત (10-15 ટર્ન) નો સામાન્ય ખર્ચ આ પ્રમાણે છે: