ორი კვირის წინ აგენტი, რომელსაც ორმოცდახუთი წამის განმავლობაში ვუშვებდი, ჩამოვარდა, რადგან downstream HTTP-მოთხოვნამ timeout მისცა. ორქესტრატორმა ჩუმად retry გააკეთა თავიდან, და მეორე გაშვებამ ნახევარი იმისა, რაც პირველმა გაშვებამ უკვე გააკეთა, hallucinate-ით გამოიგონა — მათ შორის, prod-ბაზაში ჩაწერილი მწკრივი, რომელიც შემდეგ ხელით უნდა გადაგვემოწმებინა eval-trace-თან, რომელიც დავკარგეთ. გასწორება — სამი ხაზი კოდი checkpoint-helper-ში, რომელიც პირველივე დღეს უნდა დამეწერა. გაკვეთილი — ის, რომ ორი წელი აგენტებზე როგორც prompt-ინჟინერი ვფიქრობდი, ხოლო ათი წელი — როგორც distributed-systems-ინჟინერი, და distributed-systems-ინჟინერი ამ ხნის განმავლობაში ჩუმად ბუტბუტებდა უკანა მერხებიდან.
ეს არის მეხუთე პოსტი იმ რკალში, რომელსაც ვწერ. Context engineering იყო runtime-დისციპლინა — როგორ აწყობ მოდელის შემავალ მონაცემებს ყოველ ნაბიჯზე. Spec-driven development — design-time ფილოსოფია: შენი კოდის ბაზა არ არის კოდი, არამედ სპეცები. Evals — ვერიფიკაციის ფენა: თუ AI-feature-ს evals-ის გარეშე გაუშვებ პროდუქშენში, შენ პროდუქტი არ გაქვს — დემო გყავს მომხმარებლებთან. OpenSpec — ოპერაციული სისტემა, რომელიც სამივეს უშვებს brownfield-გუნდზე ჩამოშლის გარეშე. თითოეული ეს პოსტი ნაგულისხმევად ვარაუდობდა აგენტს, რომელიც დავალებას ბოლომდე ასრულებს. პროდუქშენში აგენტები ბოლომდე არ მიდიან. ისინი ცვივიან tool-call-ის შუა. ისინი ჭამენ context window-ს long-horizon დავალების შუაში. მათ retry-ს უწევს ორქესტრატორი, რომელმაც არ იცის, რომელი side-effect უკვე დაჯდა. ისინი ჩერდებიან human-in-the-loop checkpoint-ზე, რომელსაც ადამიანი სამი დღით ივიწყებს.
Durable execution არის სუბსტრატი დანარჩენი ოთხი დისციპლინის ქვეშ. ეს არის მეხუთე, და მის გარეშე რკალი ყოველთვის არასრული იყო.
აქ არის ის, რის შემჩნევასაც ვთხოვდი ნებისმიერ senior .NET-ინჟინერს, რომელიც ამ პოსტს კითხულობს, სანამ ის სერიოზულად დაიწყება: თქვენ უკვე გესმით durable execution. თქვენ ეს უკვე გაკეთებული გაქვთ — csharp-to-claude-agents-path-ის ტერიტორიაზე, სანამ LLM პროდუქტი გახდებოდა. ყოველი MassTransit-saga, რომელიც დაწერეთ, იყო durable execution. ყოველი MediatR-pipeline compensation handler-ით — durable execution. ყოველი Hangfire-job idempotency key-ით — durable execution. ყოველი NServiceBus-კონტრაქტი, რომელშიც OnceOnly და AtLeastOnce ერთმანეთისგან გამოყოფილი იყო — durable execution. პატერნი იდენტურია. შეიცვალა მხოლოდ ერთი: მონაწილე გახდა არადეტერმინისტული და წვავს ტოკენებს. ეს არ არის ახალი პრობლემა — ეს არის ახალი შეზღუდვები ძველ პრობლემაზე, და ძველ პრობლემას აქვს დამუშავებული პატერნები.
რას ნიშნავს “durable” აგენტისთვის, კონკრეტულად
Durable execution არის შესრულება, რომლის პროგრესი იცოცხლებს იმ პროცესის სიკვდილს, რომელიც მას უშვებდა. მოვკალი კონტეინერი, restart მივეცი ორქესტრატორს, შევცვალე მოდელი, გაითიშა ქსელი — workflow აგრძელებს ბოლო commit-ებული checkpoint-იდან, არ ადუბლირებს side-effect-ებს, არ ცვლის მათ რიგს, და მიდის ზუსტად იმ შედეგამდე, რომელშიც მიდიოდა, თუ არაფერი არ ჩამოვარდებოდა.
ორი რამე ანგრევს ამ იდეის გულუბრყვილოდ მორგებას აგენტურ loop-ზე, რომელიც მისთვის არ იყო შექმნილი. პირველი: აგენტები სტოქასტიკურია — იმავე prompt-ის გამეორება იმავე ტემპერატურაზე იმავე მოდელზე ხშირად აძლევს სხვა tool-call-ს, ანუ “უბრალოდ retry-ი დავიწყოთ თავიდან” გარანტირებულად აძლევს სხვა side-effect-ებს მეორე გაშვებაზე. მეორე: აგენტები ძვირადღირებულია ტოკენებში — ორმოცი ათასი ტოკენიანი ისტორიის replay ყოველ resume-ზე ბიუჯეტის საკითხია, არა საინჟინრო, და ფინდირექტორი ადრე თუ გვიან ამას შენიშნავს. Durable execution აგენტებისთვის არის loop-ის ისე დიზაინის დისციპლინა, რომ არც ერთი ამ ორი რამიდან არ გავარდეს პროდუქშენში.
ლექსიკა იდება ერთი-ერთთან workflow-engine-კონცეფციებზე, რომლებიც .NET-ინჟინერს უკვე ესმის:
| Workflow / saga კონცეფცია | აგენტის ექვივალენტი | რა ღირს გამოტოვება |
|---|---|---|
| Idempotent activity | Idempotent tool call | ორმაგი გადახდები, რიგების დუბლიკატები DB-ში, ის reconcile-pager, რომელიც ორი კვირის წინ მქონდა გახსნილი |
| დეტერმინიზმი + replay | გეგმის checkpoint + replay ბოლო commit-ებული ნაბიჯიდან | ტოკენები, რომელთა გამართლება შეუძლებელია; reasoning-trace-ები, რომლებიც ყოველ retry-ზე ახალი აგენტივით გამოიყურება |
| Saga compensation handler | Tool-call rollback (refund, delete, retract) | ნახევრად გამოყენებული ცვლილებები; ხელით ხელახალი დალაგება ops-ში; downstream-სისტემებთან ნდობის დაკარგვა |
| Workflow-as-state-machine | გეგმა-როგორც-state-machine, აგენტი — მონაწილე | ორქესტრატორმა არ იცის, სად არის აგენტი გეგმაში; ვერც აღადგენს, ვერც აკვირდება |
OnceOnly სემანტიკა | Dedupe tool_use_id-ით activity-ის საზღვარზე | Tool-ები retry-ზე ორჯერ ისვრიან; race condition-ები; eventual-consistency-ის სიურპრიზები |
| Human-in-the-loop checkpoint | Approval, როგორც durable wait | Workflow ჩერდება; ადამიანი ივიწყებს; გაშვება იღუპება; იკარგება სამი დღის დაგროვილი state |
თუ ეს ცხრილი წაიკითხეთ და ვერაფერი ახალი დაინახეთ — სწორედ ეს არის პოინტი. Anthropic Agent SDK უკვე უშვებს durable run primitive-ს, რომელიც სწორედ ამ ფორმას აშიშვლებს: dedupe tool_use_id-ით, checkpoint ყოველ plan-step-ზე, resumable conversation state vendor-side retry-ების გავლით. Inngest Agent Kit, Temporal-ის AI-გაფართოებები, Restate-ის agent-runtime, Cloudflare Workflows, AWS Step Functions — ყველა მივიდა დაახლოებით ერთსა და იმავე პრიმიტივამდე ბოლო თორმეტი თვის განმავლობაში. კონვერგენცია სწრაფად მოხდა, რადგან საფუძველში მდებარე პატერნი უკვე იყო სტანდარტი AI-ის გარეთ. ვენდორები ეწევიან იმას, რასაც saga-orchestration-თემი 2010-იანების დასაწყისიდან აკეთებს.
არა-durable აგენტების ოთხი failure mode
ყოველი აგენტი, რომელიც durable execution-ისთვის არ არის შექმნილი, პროდუქშენში ოთხი გზიდან ერთით კვდება. თითოეულზე ნაიარევი მაქვს.
1. Crash tool-call-ის შუა. აგენტი იძახებს tool-ს, რომელიც ათ წამში ბრუნდება. მეექვსე წამზე კონტეინერი იცვლება, ფუნქცია timeout-ში ვარდება, ან თვითონ model API აბრუნებს 502-ს ზევით blip-ის გამო. Tool-ის side-effect დაჯდა თუ არა? თუ მიმღებ მხარეზე არ არის dedupe-table tool_use_id-ით, გაგება შეუძლებელია. Retry — ორმაგი გადახდა. არ retry — ჩუმად კარგავ მუშაობას. ამ ფენაზე სწორი პასუხი არ არსებობს — სწორი პასუხი იყო tool-ის idempotent-ად შექმნა დიზაინის ეტაპზე. თუ მთელი პოსტიდან ერთი წესის გამოტანა გინდა: ყოველი tool, რომელიც state-ს ცვლის აგენტის კონტექსტს გარეთ, ვალდებულია მიიღოს idempotency key, და მიმღები სისტემა ვალდებულია შეამოწმოს იგი ცვლილების გამოყენებამდე.
2. ამოწურული context window გაშვების შუა. აგენტი ორმოცდახუთ ნაბიჯში long-horizon-დავალების შიგნით. System prompt — ორი ათასი ტოკენი; დაგროვილი tool-call-ების ისტორია — ორმოცი ათასი. შემდეგ planning-ნაბიჯს რვა ათასი ტოკენი სჭირდება reasoning-ისთვის. მოდელი აბრუნებს refusal-ს, წაკვეთილ გეგმას, ან — რაც უარესია — დარწმუნებულ გეგმას კონტექსტზე, რომელიც მოდელმა ჩუმად შეაჯამა არასწორ ფენაზე. ეს არის ის, რასაც Context Engineering უწოდებს “working set-იდან გასვლას” — სწორედ აქ ჩერდება უმეტესობა პროდუქშენ-აგენტი. გასწორება runtime-ფენაშია: ისტორიის აგრესიული შეკუმშვა მკაფიო checkpoint-საზღვრებზე, შეკუმშული summary-ით ჩაწერილი durable storage-ში, რათა გაგრძელებულმა გაშვებამ იგივე summary-დან rehydrate გაიკეთოს, არა raw ისტორიიდან replay.
3. Retry storm არა-idempotent tool-ებზე. აგენტი შუაში ვარდება. ორქესტრატორი retry-ს უწევს. Retry ხვდება tool-ში, რომელიც წინა გაშვებამ უკვე გამოიძახა. Tool არ არის idempotent. მეორე გაშვება ბადებს მესამე side-effect-ს. იქამდე, რომ ეს შენიშნოთ, გაქვთ სამი Stripe-charge, ორი Slack-შეტყობინება, და ერთი პროდუქშენ-DB-რიგი სამი ეგზემპლარით. Retry-მექანიზმმა გააუარესა, არ გააუმჯობესა — აგენტი არ აღდგა, ორქესტრატორმა მხოლოდ ზიანი გაამრავლა. ეს არის ის failure mode, რომელმაც saga-orchestration-თემს ასწავლა idempotency key-ების კონტრაქტში ჩაშენება, არა შემდეგ მიწებება.
4. ჩაკიდებული human-in-the-loop pause. აგენტი მივიდა approval-checkpoint-ამდე. Ping Slack-ში. ადამიანი სადილზე, თვითმფრინავში, ან — ყველაზე ხშირად — გახსნა შეტყობინება, გადაწყვიტა მოგვიანებით ეპასუხა, და დაივიწყა. აგენტის პროცესი აგრძელებს ბრუნვას, ელოდება სინქრონულ პასუხს, წვავს რესურსებს, ღია ქსელის socket-ს ინარჩუნებს. ან უარესი: აგენტის პროცესი გადის, სანამ ელოდება, ადამიანი დაადასტურებს სამი საათის შემდეგ, და პასუხი ფრინდება Slack-thread-ში, რომელსაც ვერავინ კითხულობს. პატერნი არა-LLM saga-ტერიტორიაში არის human-in-the-loop pause-ის durable wait-ად მოდელირება: workflow იძინებს, resume-სიგნალი — durable callback, და workflow-ს არ ანაღვლებს — resume სამ წამში მოვა თუ სამ დღეში. იგივე პატერნი პირდაპირ გადადის.
თითოეული ეს არის runtime-სუბსტრატის failure mode, არა მოდელის. ნებისმიერ ამ ერთ-ერთზე უფრო ჭკვიანი მოდელის სროლა არც ერთს არ ასწორებს.
ხუთი წესი, რომელიც durable-აგენტების გადატანიდან გამოვიტანე
ეს წესები ნებისმიერი ახალი repo-ს project.md-ში ჩავწერდი, რომელიც აგენტებს უშვებს 2026-ში. ისინი არ არიან ორიგინალური — ეს არის ის, რასაც workflow-engineering-თემი უკვე ათ წელია ამბობს, აგენტურ ლექსიკონზე გადათარგმნილი.
წესი 1: idempotent tool-ები ნაგულისხმევად
ყოველი tool, რომელიც state-ს ცვლის აგენტის ლოკალურ კონტექსტს გარეთ, იღებს idempotency key-ს როგორც first-class პარამეტრს, და მიმღები სისტემა ამოწმებს მას ცვლილების გამოყენებამდე. უმარტივეს იმპლემენტაციაში key — tool_use_id Anthropic/OpenAI tool-call-სქემიდან; tool-ებისთვის, რომლებიც რამდენიმე მოძრაობას მოიცავს ან სხვა tool-ებს ერთიანდება — stable hash plan-step ID-დან. გამონაკლისები არ არის. რეალიზაციის ფასი — ერთი დამატებითი პარამეტრი ყოველ tool-ზე; გამოტოვების ფასი — ის პროდუქშენ-reconcile, რომლითაც ეს პოსტი დაიწყო.
რატომ არ განიხილება ეს. Tool-ები, რომლებიც დღეს “read-only”-ად გამოიყურება, ხვალ retro-fit-ულდება caching-ით ან telemetry-ით, რის შემდეგაც ისინი ხდებიან side-effecting იმ ფორმით, რომელსაც აგენტური loop ვერ ხედავს. გახადეთ მთელი tool-ის ზედაპირი idempotent კონტრაქტის დონეზე — და აღარასოდეს მოგიწევთ გადახედვა, რომელი tool-ები “არიან თუ არ არიან”; ყველანი არიან.
წესი 2: checkpoint ყოველი გარე ჩაწერის შემდეგ
აგენტის გეგმა იყოფა ნაბიჯებად. ყოველი ნაბიჯის შემდეგ, რომელიც გარე side-effect-ს აწარმოებს — ჩაწერა DB-ში, API-ის გამოძახება მესამე მხარეზე, შეტყობინება queue-ში — ორქესტრატორი commit-ს უწევს durable-checkpoint-ს. Checkpoint შეიცავს: step ID, შესრულებულ tool-call-ს, დაბრუნებულ შედეგს, და აგენტის working context-ის hash-ს ამ მომენტში. Resume-ზე ორქესტრატორი გეგმის replay-ს უწევს ბოლო commit-ებული checkpoint-იდან, არა თავიდან.
Checkpoint-ის საცავი არ უნდა იყოს რთული. Postgres-table-ი უნიკალური შეზღუდვით (workflow_id, step_id)-ზე საკმარისია. Cloudflare Workflows API ამას აშიშვლებს როგორც step.do(). Anthropic Agent SDK — როგორც callback checkpoint. Temporal — როგორც activity history. აირჩიეთ ერთი და დაასტანდარტეთ მთელ კოდის ბაზაში.
წესი 3: არასოდეს გააგრძელოთ მოძველებულ გეგმაში
ყველაზე რთული bug durable-აგენტებში — resume-into-staleness. აგენტი ჩამოვარდა მეშვიდე ნაბიჯზე თორმეტნაბიჯიანი გეგმიდან. გეგმა იყო გენერირებული კონტექსტიდან, რომელიც შეიცავდა მონაცემებს — ვთქვათ, ინვენტარის snapshot-ს — რომელიც იმ მომენტში ახალი იყო. სამი საათის შემდეგ workflow განახლდება. ინვენტარის snapshot ახლა არასწორია, მაგრამ გეგმამ ეს არ იცის, და აგენტი დარწმუნებით მიდის მერვე ნაბიჯიდან შეცვლილი სამყაროს წინააღმდეგ.
წესი ასეთია: გეგმის ნებისმიერ ელემენტს, რომელიც გარე state-ზე არის დამოკიდებული, აქვს freshness-ბიუჯეტი, და ბიუჯეტის გადაცილების შემთხვევაში resume triggers-ი ხდება re-plan-ი ბოლო კარგი checkpoint-იდან, არა ბრმა გაგრძელება. Freshness-ბიუჯეტი არის გეგმის ნაწილი, არა runtime-კონფიგის. აგენტი წყვეტს, რა არის ახალი; ორქესტრატორი ამას ახორციელებს.
წესი 4: ბიუჯეტი დააწესეთ ტოკენებზე resume-ზე, არა მხოლოდ დასაწყისზე
გაგრძელებული აგენტი მემკვიდრეობით იღებს context window-ს, რომელიც ორიგინალურმა გაშვებამ გაზარდა. თუ აგრესიულად არ შეკუმშავთ checkpoint-საზღვრებზე, ყოველი resume უფრო ძვირია, ვიდრე წინა, და workflow, რომელიც ოთხჯერ ხელახლა გადატრიალდა retry-ით, მეხუთე ცდაზე უფრო მეტი ტოკენი შეიძლება დაჯდეს, ვიდრე პირველი ოთხი ერთად. ეს არის ის failure mode, რომელიც “კარგად მორგებულ eval-suite”-ს “ფინანსების ticket”-ად აქცევს.
დისციპლინა — საუბრის ისტორიის შეკუმშვა ყოველ durable-checkpoint-ზე: raw მოძრაობების ჩაკეცვა სტრუქტურირებულ summary-ში, რომელიც checkpoint-ის payload-ში ცხოვრობს, და rehydrate summary-დან resume-ზე, არა raw მოძრაობებიდან. Claude API ამას მარტივს ხდის prompt caching-ით: checkpoint-ის summary ხდება cache-ადი პრეფიქსი, და მხოლოდ ახალი working-მოძრაობები ცხოვრობენ cache-ის გარეთ. ღირებულების 80%-იანი ბერკეტი, რომელზეც csharp-to-claude-agents-path-ში დავწერე, არის ზუსტად ეს ბერკეტი; გუნდების უმეტესობა უბრალოდ არ ხმარობს მას გაგრძელებულ გაშვებებზე, მხოლოდ ახლებზე.
წესი 5: workflow — სიმართლის წყარო, აგენტი — მონაწილე
ეს არის წესი, რომელიც saga-orchestration-თემმა თხუთმეტი წლის წინ აითვისა, და LLM-ეკოსისტემა ჯერ ისევ ეწევა. Workflow არ არის “ის, რასაც აგენტი უშვებს”; workflow არის კონტრაქტი, ხოლო აგენტი — მისი მონაწილე. აგენტი შეიძლება ჩანაცვლდეს სხვა მოდელით, სხვა ვენდორით, ან დეტერმინისტული ფუნქციით, და workflow განაგრძობს მუშაობას. State ცხოვრობს workflow-ში; აგენტს არ აქვს თავისი durable state.
თუ თქვენ თავი დაიჭირეთ ფიქრში “რა იცის აგენტმა მეშვიდე ნაბიჯზე” ან “რა ახსოვს აგენტს მესამედან” — უკვე წააგეთ. აგენტმა იცის ის, რასაც workflow ეუბნება მეშვიდე ნაბიჯზე, წერტილი. აგენტს ახსოვს ის, რაც დევს checkpoint-ის payload-ში მესამე ნაბიჯზე, წერტილი. აგენტის “მეხსიერება” — ეს არის workflow-ის state, რომელიც prompt-ში მატერიალიზდება ყოველ ნაბიჯზე. სწორედ ეს არის მთელი მენტალური მოდელი.
სად ეს ჯერ ისევ იშლება
გულახდილი ნაწილი. Durable execution წყვეტს ოთხი პროდუქშენ-failure-mode-დან სამს სუფთად. მეოთხე — და რამდენიმე მის გვერდით — დარჩა ღია პრობლემებად, რომლებზეც სუფთა პასუხები არ მაქვს. თუ შემდეგი ოთხი აბზაცის წაკითხვის შემდეგ პასუხები გაქვთ — დაწერეთ პოსტი და გამომიგზავნეთ ბმული; ჩავსვამ.
გრძელვადიანი human-in-the-loop — UX-პრობლემაა, რომელიც ინფრასტრუქტურულად არის გადაცმული. Durable wait-ები წყვეტენ workflow-მხარის სისწორეს: workflow იძინებს, resume-სიგნალი მოდის, workflow აგრძელებს. მაგრამ ადამიანის მხარე გადაუჭრელია. სამი დღის შემდეგ pause-ში ადამიანმა დაივიწყა კონტექსტი, რომელმაც approval-კითხვა აზრიანი გახადა. კონტექსტის ხელახალი წარდგენა resume-ზე — ეს არის generation-პრობლემა, არა retrieval-პრობლემა: ადამიანისთვის workflow ხელახლა უნდა ავხსნათ, არა უბრალოდ ვაჩვენოთ, სად შევჩერდით. 2026-ში არ მინახავს, ვინმეს ეს კარგად რომ ამოეხსნა; ყველაზე ახლოს — resume-შეტყობინების ცალკე generation-pass-ად მოაზრება, რომელიც why-this-matters-კონტექსტს ხელახლა ასინთეზებს.
Cross-vendor მოდელის swap გაშვების შუა თეორიულად შესაძლებელია, პრაქტიკულად მტკივნეული. კონტექსტი შეიძლება შეიკუმშოს, persist-დეს, და rehydrate-დეს სხვა მოდელის წინააღმდეგ resume-ზე — Opus-დან Sonnet-ზე cost-მიზეზებით, Claude-დან GPT-ზე capability-მიზეზებით. პრაქტიკაში prompt-ფორმატების, tool-call-სქემის დიალექტების, და model-specific behavioral quirks-ის სხვაობა ნიშნავს, რომ გაგრძელებული გაშვება სხვაგვარად იქცევა, მაშინაც კი, თუ კონტექსტი “იგივეა”. ინფრასტრუქტურა შეიძლება swap-ი გააკეთოს მოდელის. აგენტმა შეიძლება swap-ი ვერ გადაიტანოს. დღეს mid-run vendor swap-ს code smell-ად ვუყურებ, არა feature-ად.
Retry-სემანტიკა LLM-as-judge-ისთვის არ არის idempotent. Evals LLM-judge-ფენაზე არ არიან დეტერმინისტული კონსტრუქციით. თუ durable workflow retry-ს უწევს judge-ნაბიჯს, მეორე გადაწყვეტილებამ შეიძლება არ დაემთხვეს პირველს. გულახდილი პასუხი — ან snapshot-ის გაკეთება judgment-ის checkpoint-ის payload-ში (მაშინ retry replay-ს უწევს cached judgment-ს, არა მოდელს), ან commit “judge-ი ერთხელ ვკითხეთ”-ის დონეზე, ყველა failure-mode-ის შედეგით. დღეს პირველს ვაკეთებ და ბედნიერი არ ვარ ამით.
თვით durable-execution-ინფრასტრუქტურის ფასი. ყოველი checkpoint — ჩაწერა. ყოველი resume — წაკითხვა. ყოველი retry-ული workflow იხდის storage-სა და read-ს ორჯერ. პროდუქშენ-აგენტების უმეტესობისთვის overhead ერთნიშნა პროცენტის ფარგლებშია, მაგრამ high-fanout multi-agent-სისტემებისთვის მათემატიკა უფრო რთულია. არ მინახავს სუფთა განხილვა “როდის ხდება durable execution იმდენად ძვირი, რომ აღარ ღირდეს”; ჩემი ევრისტიკაა — ნებისმიერი workflow გარე side-effect-ით checkpoint-ის ღირსია, ხოლო workflow, რომელიც მხოლოდ ტექსტს ქმნის side-effect-ის გარეშე, ალბათ არა.
კარიერული კუთხე: durable-agent engineer — შემდეგი დასახელებული როლი
პატერნი მთელ რკალში ერთია. Context engineering დასახელებული როლი გახდა; eval engineer ხდება. Spec author — შემდეგი როლი, რომელზეც ბრენდი ფსონს დებს. Durable-agent engineer — ეს არის როლი მის შემდეგ, და მას აქვს ყველაზე ღრმა moat senior .NET-ფონისთვის.
Junior (ნული-ორი წელი სკოლის შემდეგ). ისწავლეთ ხელსაწყოები. Claude Agent SDK და Anthropic SDK უშვებენ durable-run-პრიმიტივებს ზედაპირზე; მათი docs-ის წაკითხვა — ყველაზე იაფი გზაა შესვლის. თუ .NET-ის ან distributed-systems-ფონი არ გაქვთ — გაიარეთ RAG and Agents, იქ დაფარულია agent-loop-საფუძვლები, რომელთა გარეშე durable execution როგორც კონცეფცია ვერ აიგება. ააწყვეთ ერთი პატარა durable-აგენტი end-to-end (workflow + idempotent tool + checkpoint store + resume) — და გექნებათ portfolio-მაგალითი, რომელიც 2026-ში თითქმის არც ერთ junior-ს ფაქტობრივად არ აქვს.
Mid (სამი-შვიდი წელი). დაიკავეთ სუბსტრატი. აირჩიეთ ორქესტრატორი, რომელზეც თქვენი გუნდი დასტანდარტდება — Temporal, Inngest, Restate, Cloudflare Workflows, ან Agent SDK-ის native runtime — და დაიკავეთ ის მთელ კოდის ბაზაში. დაწერეთ კონვენციები: რომელი idempotency-key-ის ფორმა, რომელი checkpoint-ის payload-სქემა, რომელი retry-პოლიტიკა. Mid-level-ინჟინერი, რომელიც ჩუმად წერს გუნდის durable-execution-სექციას AGENTS.md-ში, თვრამეტი თვის შემდეგ შეუცვლელი ხდება. თუ ფონი — .NET, AI-Powered .NET Development — ეს არის ადგილი, სადაც agent-loop / saga-orchestration / ASP.NET-Core-ინტეგრაცია ერთ ხაზად იწყობა; ეს არის ბუნებრივი ნაბიჯი სტანდარტული backend-პროგრამის შემდეგ.
Senior და staff (რვა წელი და მეტი). Durable execution არქიტექტურულ საკითხად აღიქვით, არა ბიბლიოთეკის არჩევნად. საინტერესო კითხვები ამ დონეზე: როგორ ერგებიან durable-აგენტები არსებულ message-broker-კონტრაქტებთან? როგორ ვცვალოთ brownfield-კოდის ბაზა აგენტებით “agent loop ბრუნავს in-process”-დან “agent loop არის workflow”-ზე? როგორ დავადგინოთ token-ბიუჯეტი, რომელიც retry-ებს გადაიტანს? როგორ ურთიერთობს durable-execution-ფენა evals-ფენასთან, როცა judgment თვითონ — workflow-ნაბიჯია? ეს არის ის კითხვები, რომლებზე ნებისმიერ senior .NET-ინჟინერს, რომელიც AI-ინჟინერიაში გადადის, აქვს prior art; გაცნობიერება, რომ prior art გადადის, არის high-leverage-ნაბიჯი. კურსები Spec-Driven Development და OpenSpec Mastery აძლევენ მეთოდოლოგიურ ჩარჩოს, რომ ეს გადაწყვეტილებები გუნდის წინაშე დასაცავი იყოს.
რკალის დახურვა
რკალი ყოველთვის იყო ხუთი დისციპლინისგან, არა ოთხისგან. Context engineering — როგორ ავაგროვო შემავალები. Spec-driven development — როგორ გამოვხატო ზრახვა. Evals — როგორ დავამტკიცო, რომ გამოსავალი ის არის, რომელიც გვინდოდა. OpenSpec — ოპერაციული სისტემა, რომელიც სამივეს უშვებს ცოცხალ გუნდზე. Durable execution — სუბსტრატი, რომელიც ცოცხალს ინარჩუნებს ამ ყველაფერს სამშაბათ შუადღეს, როცა ქსელი blip-ი ხდება, მოდელი 502-ს აბრუნებს tool-call-ის შუა, და ადამიანი სახლში მიდის checkpoint-ის დადასტურებამდე.
ყოველ senior .NET-ინჟინერს, რომელიც ამ პოსტს კითხულობს, ეს პატერნი უკვე გადატანილი აქვს. დარჩა მისი დასახელება — და agent loop-ში პირველივე დღეს ჩაშენება, არა პირველი პროდუქშენ-ინციდენტის შემდეგ მიწებება. წესების ახალ აგენტურ კოდის ბაზაში ჩაწერის ფასი — ერთი დღე. მათი retro-fit-ის ფასი პირველი reconcile-pager-ის შემდეგ — ერთი კვირა დასუფთავება და სისტემებთან ნდობის ნელი აღდგენა, რომლებშიც წერ.
სუბსტრატი — durable. აგენტი — მონაწილე. Workflow — სიმართლე. Spec, context, evals, OpenSpec, და durable execution — ეს არის ხუთი დისციპლინისგან შემდგარი რკალი. ყველაფერი დანარჩენი — ინტერფეისი მის ზემოთ.
