Multi-step AI agent-ը համակարգ է, որը նպատակը բաժանում է քայլերի, կանչում է արտաքին գործիքներ, պահպանում է անհրաժեշտ վիճակը և որոշում՝ շարունակե՞լ, կրկնե՞լ, թե՞ աշխատանքը փոխանցել մարդուն։ Այն սովորական chatbot չէ․ լավ նախագծված agent-ը կատարում է վերահսկելի LLM workflow՝ հստակ մուտքերով, ելքերով և թույլատրելի գործողություններով։
Իրական բիզնեսում հուսալի agent architecture-ը կառուցվում է հինգ շերտով՝ պլան, գործիքներ, հիշողություն, guardrails և մարդկային փոխանցում։ Օրինակ՝ agent-ը կարող է հարստացնել ներգնա lead-ը կամ մշակել invoice-ը, բայց վճարում ուղարկելը, CRM տվյալ վերագրելը կամ կասկածելի փաստաթուղթ հաստատելը չպետք է թողնել մեկ ազատ տեքստային պատասխանի վրա։
Եթե դուք ոչ ԱՄՆ ռեզիդենտ հիմնադիր եք և աշխատում եք ԱՄՆ ընկերությամբ, նույն agent-ը կարող է միացնել Stripe-ը, HubSpot-ը, QuickBooks-ը կամ Mercury-ից արտահանված տվյալները։ Սակայն ճիշտ մեկնարկը փոքր, չափելի workflow-ն է, ոչ թե «ինքնավար թվային աշխատակիցը»։
Multi-step AI agent-ի հինգ շերտը
| Շերտ | Դերը | Գործնական օրինակ |
|---|---|---|
| Պլան | Նպատակը բաժանում է քայլերի | Ստուգել domain-ը, գտնել ընկերությունը, գնահատել lead-ը |
| Գործիքներ | Կարդում կամ փոխում են արտաքին տվյալներ | HubSpot, Clearbit, Apollo, QuickBooks API |
| Հիշողություն | Պահպանում է ընթացիկ վիճակն ու անհրաժեշտ համատեքստը | Նախորդ քայլերի արդյունքներ, հաստատման կարգավիճակ |
| Guardrails | Սահմանափակում են սխալ կամ վտանգավոր գործողությունները | Գումարի շեմ, JSON schema, թույլատրված դաշտեր |
| Մարդկային փոխանցում | Անորոշ դեպքը ուղարկում է պատասխանատուին | Slack approval կամ հաշվապահի հերթ |
Պլանը թող լինի սահմանափակ
Բաց պլանավորումը ճկուն է, բայց դժվար է փորձարկել։ Սկզբում սահմանեք 4–8 թույլատրելի քայլ և յուրաքանչյուրի հաջողության չափանիշը։ LLM-ը կարող է ընտրել հաջորդ քայլը, սակայն չպետք է հորինի նոր գործիք կամ գործողություն։
Գործիքները նախագծեք որպես նեղ ֆունկցիաներ
update_crm-ի նման լայն գործիքի փոխարեն կիրառեք առանձին գործողություններ՝ set_company_size, add_research_note, assign_owner։ Յուրաքանչյուր կանչ պետք է ունենա typed input, timeout և idempotency key, որպեսզի կրկնակի փորձը կրկնակի գրառում կամ վճարում չստեղծի։
Հիշողություն և վիճակ՝ առանց ավելորդ տվյալների
«Հիշողությունը» մեկ բան չէ։ Տարբերակեք երեք տեսակ.
- Workflow state. Որ քայլն է ավարտվել, ինչ արդյունքով և երբ։ Պահեք PostgreSQL-ում կամ workflow engine-ում, օրինակ՝ Temporal-ում։
- Կարճաժամկետ համատեքստ. Տվյալ առաջադրանքի համար անհրաժեշտ փաստերը։ Մի փոխանցեք ամբողջ CRM պատմությունը յուրաքանչյուր prompt-ում։
- Երկարաժամկետ գիտելիք. Ընկերության կանոններ, ապրանքների կատալոգ կամ հաշվապահական քաղաքականություն՝ որոնելի փաստաթղթերում։
Պահպանեք նաև աղբյուրը, timestamp-ը և confidence-ը։ Lead-ի աշխատակիցների քանակը կամ invoice-ի bank details-ը կարող են փոխվել։ Agent-ը պետք է կարողանա ասել ոչ միայն «ինչ գիտի», այլև՝ որտեղից և երբ է ստացել տվյալը։
Լավ հիշողությունը մեծ prompt չէ․ այն փոքր, ստուգելի և թարմացվող վիճակ է։
Case study 1․ ներգնա lead-երի sales research agent
Նպատակը և հոսքը
Ենթադրենք՝ ձեր Delaware ընկերության կայքում demo request է լրացվում։ Ձեզ պետք է 5 րոպեի ընթացքում հարստացնել lead-ը, գնահատել համապատասխանությունը և տեղեկացնել վաճառողին՝ առանց CRM-ը չստուգված փաստերով լցնելու։
- Webhook-ը HubSpot-ից կամ Typeform-ից ստեղծում է առաջադրանք՝ email, անուն և company domain դաշտերով։
- Agent-ը վավերացնում է email-ը և առանձնացնում domain-ը։ Gmail կամ Proton Mail հասցեները նշվում են որպես անձնական, ոչ թե ավտոմատ մերժվում։
- Clearbit-ի, Apollo-ի կամ ընկերության կայքի միջոցով հավաքվում են ոլորտը, գտնվելու վայրը, մոտավոր չափը և ապրանքի նկարագրությունը։
- LLM-ը համադրում է տվյալները ձեր ICP կանոնների հետ՝ օրինակ՝ B2B SaaS, 10–200 աշխատակից, ԱՄՆ շուկա։
- Agent-ը վերադարձնում է structured JSON՝ fit score, փաստեր, աղբյուրներ, բացակայող տվյալներ և առաջարկվող հաջորդ քայլ։
- Միայն վավերացված դաշտերն են գրվում HubSpot-ում։ Բարձր առաջնահերթ lead-ի դեպքում Slack-ում ստեղծվում է ծանուցում։
Guardrails և փոխանցման կանոններ
- Չգրել աշխատակիցների թիվ, եթե աղբյուրները հակասում են կամ տվյալ չկա։
- Չուղարկել անհատական outreach առանց հաստատված email-ի և մարդու հաստատման։
- Lead-ը փոխանցել վաճառողին, եթե score-ը սահմանային է, domain-ը redirect է անում կամ ընկերության նույնականացումը երկիմաստ է։
- CRM update-ից առաջ ստուգել JSON schema-ն և թույլատրված field list-ը։
Առաջին տարբերակը կարելի է կառուցել 1–2 շաբաթում՝ n8n կամ Zapier orchestration-ով, OpenAI կամ Anthropic model-ով և HubSpot API-ով։ Սկսեք օրական առավելագույնը 20 lead-ից և shadow mode-ից․ agent-ը առաջարկում է փոփոխությունները, իսկ մարդը հաստատում է դրանք։
Case study 2․ invoice-processing agent
Փաստաթղթից մինչև հաշվապահական draft
Invoice workflow-ն ավելի բարձր ռիսկ ունի, որովհետև սխալ vendor-ը, գումարը կամ արժույթը կարող են ազդել հաշվապահության և վճարման վրա։ Այստեղ LLM-ը պետք է մեկնաբանի բացառությունները, ոչ թե փոխարինի թվաբանական ու կանոնային ստուգումները։
- Invoice-ը մուտք է գործում հատուկ email inbox, Google Drive կամ upload form։ Ֆայլը պահվում է immutable ID-ով։
- OCR ծառայությունը՝ օրինակ Amazon Textract կամ Google Document AI, հանում է vendor name-ը, invoice number-ը, ամսաթիվը, line items-ը, subtotal-ը, tax-ը և total-ը։
- Կոդը վերահաշվում է գումարները և ստուգում արժույթը։ LLM-ի հաշվարկին մի վստահեք։
- QuickBooks-ում որոնվում են vendor-ը և նույն invoice number-ը՝ duplicate-ը կանխելու համար։
- Agent-ը առաջարկում է category և account mapping՝ հիմնվելով հաստատված կանոնների ու նախկին օրինակների վրա։
- Ստեղծվում է draft bill, ոչ թե անմիջական վճարում։ Հաստատումը գնում է հաշվապահին կամ հիմնադրին։
Ռիսկի շեմերի օրինակ
Ձեր ներքին քաղաքականությունը կարող է պահանջել ավտոմատ draft մինչև $500, պարտադիր մեկ հաստատում՝ $500–$5,000, իսկ $5,000-ից բարձր կամ bank details-ի փոփոխությամբ invoice-ների համար՝ երկու հաստատում։ Սրանք իրավական պահանջներ չեն, այլ կարգավորելի բիզնես guardrails։
Human handoff-ը պետք է փոխանցի ամբողջ փաթեթը՝ բնօրինակ PDF, extracted fields, անհամապատասխանությունների ցանկ, confidence և առաջարկվող որոշում։ «Ստուգեք invoice-ը» հաղորդագրությունը բավարար չէ։
Հուսալիության patterns՝ retries, evals և human-in-the-loop
Retries՝ միայն ժամանակավոր սխալների համար
429 rate limit-ի կամ timeout-ի դեպքում կիրառեք exponential backoff, օրինակ՝ 2, 4 և 8 վայրկյան՝ առավելագույնը 3 փորձով։ Validation error-ը նույն input-ով կրկնելը օգուտ չունի․ այն ուղղեք կամ փոխանցեք մարդուն։ Բոլոր write գործողությունների համար օգտագործեք idempotency key։
Evals՝ մինչև production և դրանից հետո
Ստեղծեք 50–100 anonymized օրինակներից eval հավաքածու՝ ներառելով պարզ, սահմանային և սխալ մուտքեր։ Չափեք ոչ միայն պատասխանի «որակը», այլև field accuracy-ն, ճիշտ tool selection-ը, unsupported claim-երը, escalation rate-ը և մեկ առաջադրանքի արժեքը։ Model-ը կամ prompt-ը փոխելիս նույն հավաքածուն նորից գործարկեք։
Human-in-the-loop՝ ըստ ռիսկի
Մարդու հաստատումը տեղադրեք անդառնալի գործողությունից առաջ՝ email ուղարկել, CRM ownership փոխել, bill հաստատել կամ վճարում նախաձեռնել։ Ցածր ռիսկի read-only քայլերը կարող են կատարվել ավտոմատ։ Այս բաժանումը սովորաբար ավելի արդյունավետ է, քան յուրաքանչյուր քայլը ձեռքով հաստատելը։
Գործարկման checklist
- Սահմանե՞լ եք մեկ չափելի նպատակ և վերջնական ելքը։
- Յուրաքանչյուր tool ունի՞ schema, timeout և նվազագույն permissions։
- Գաղտնիքներն ու API keys-ը պահվո՞ւմ են secret manager-ում, ոչ prompt-ում։
- Գրանցվո՞ւմ են tool call-երը, latency-ն, արժեքը և սխալները։
- Կա՞ duplicate prevention և idempotency։
- Սահմանվա՞ծ են confidence, գումարի կամ ռիսկի շեմերը։
- Մարդը կարո՞ղ է մերժել, ուղղել և վերսկսել workflow-ն։
- Կա՞ kill switch և fallback՝ ձեռքով մշակման համար։
- Անցե՞լ եք shadow mode, ապա 10%, 25% և 100% փուլային rollout։
Հաճախ տրվող հարցեր
Ե՞րբ է պետք agent, ոչ թե սովորական automation
Օգտագործեք agent, երբ քայլերի հաջորդականությունը կախված է չկառուցվածքային տվյալից կամ բացառություններից։ Եթե կանոնները հաստատուն են, սովորական Zapier կամ կոդային workflow-ն ավելի պարզ ու կանխատեսելի է։
Պե՞տք է vector database
Ոչ միշտ։ PostgreSQL-ը բավարար է workflow state-ի համար։ Vector search ավելացրեք միայն այն դեպքում, երբ agent-ը պետք է որոնի մեծ փաստաթղթային բազայում ըստ իմաստի։
Կարո՞ղ է agent-ը ինքնուրույն վճարել invoice-ները
Տեխնիկապես հնարավոր լինելը լավ default չէ։ Սկսեք draft bill-ից և մարդու հաստատումից, ապա ավտոմատացրեք միայն ցածր ռիսկի, կրկնվող դեպքերը՝ հստակ սահմաններով։
Որքա՞ն արժե մեկ workflow-ն
Արժեքը կախված է model call-երից, OCR-ից, enrichment provider-ից և ծավալից։ Հաշվեք մեկ առաջադրանքի ամբողջ արժեքը՝ API fees, retries, storage և մարդկային review minutes, ապա համեմատեք ձեռքով կատարման հետ։
Երբ կարող է օգնել Founder Portal-ը
Եթե ձեր AI workflow-ն կապվում է ԱՄՆ ընկերության գործարկման, Stripe-ի, banking-ի կամ back-office ավտոմատացման հետ, Founder Portal-ը կարող է օգնել ճիշտ կառուցել այդ գործնական հիմքը՝ նախքան agent-ին production հասանելիություն տալը։