एजेंट लूप आर्किटेक्चर

Everyone's asking "WTF is a loop?" Here's the question nobody's asking: what runs the loop?

हर कोई पूछ रहा है "लूप क्या होता है?" लेकिन कोई यह नहीं पूछ रहा: लूप को चलाता क्या है?

The AI discourse has converged on loops as a core primitive of agentic systems. Matt Van Horn (@mvanhorn) traced the lineage of agent loops from ReAct to tool-use to orchestration loops to loops supervising loops. Addy Osmani (@addyosmani) broke down the building blocks inside loops: automations, worktrees, skills, connectors, sub-agents. Van Horn landed on durability, arguing that loops which can't survive a restart aren't loops. Osmani's key thread was orchestration: design the system that prompts the agent instead of you.

AI चर्चा में लूप को एजेंटिक सिस्टम का मूल तत्व मान लिया गया है। Matt Van Horn (@mvanhorn) ने एजेंट लूप की वंशावली को ReAct से लेकर टूल-उपयोग, ऑर्केस्ट्रेशन लूप और लूप द्वारा लूप की निगरानी तक ट्रेस किया। Addy Osmani (@addyosmani) ने लूप के अंदर के बिल्डिंग ब्लॉक्स को विस्तार से समझाया: ऑटोमेशन, वर्कट्री, स्किल्स, कनेक्टर, सब-एजेंट। Van Horn ने durability (टिकाऊपन) पर जोर दिया, यह तर्क देते हुए कि जो लूप रीस्टार्ट के बाद भी जीवित नहीं रह सकते, वे लूप नहीं हैं। Osmani का मुख्य सूत्र orchestration (ऑर्केस्ट्रेशन) था: एक ऐसी प्रणाली डिज़ाइन करना जो आपके बजाय एजेंट को प्रॉम्प्ट करे।

I want to take their points further. Durability isn't just a property of the loop. It's the entire execution layer underneath it. The important fact is that durable orchestration is fundamental to building your agent loop architecture. Let's break down that architecture.

मैं उनकी बातों को आगे ले जाना चाहता हूँ। टिकाऊपन सिर्फ लूप का गुण नहीं है। यह उसके नीचे पूरी एक्ज़ीक्यूशन लेयर है। महत्वपूर्ण तथ्य यह है कि टिकाऊ ऑर्केस्ट्रेशन आपकी एजेंट लूप आर्किटेक्चर के निर्माण के लिए मौलिक है। आइए उस आर्किटेक्चर को समझते हैं।

Where loops break

लूप कहाँ टूटते हैं

The /loop and /goal patterns handle single-agent, single-session work well. An agent loops until a task is done. That covers a lot of ground. But the next stage (Stage 5 in Van Horn's framing) is where it falls apart:

/loop और /goal पैटर्न सिंगल-एजेंट, सिंगल-सेशन के काम को अच्छी तरह से संभालते हैं। एक एजेंट तब तक लूप करता है जब तक कार्य पूरा न हो जाए। यह काफी हद तक काम करता है। लेकिन अगला चरण (Van Horn की फ्रेमिंग में स्टेज 5) वह जगह है जहाँ यह बिखर जाता है:

• Loops supervising other loops
• लूप दूसरे लूप की निगरानी कर रहे हैं
• Loops running on schedules, not just triggered by a human
• लूप शेड्यूल पर चल रहे हैं, न कि सिर्फ इंसान द्वारा ट्रिगर किए गए
• Loops that survive process restarts, deploys, and crashes
• लूप जो प्रोसेस रीस्टार्ट, डिप्लॉय और क्रैश से बच जाते हैं
• Loops that spawn sub-agents and wait for results (sometimes hours later)
• लूप जो सब-एजेंट बनाते हैं और परिणामों की प्रतीक्षा करते हैं (कभी-कभी घंटों बाद)
• Loops that need to be observable after the fact
• लूप जिन्हें बाद में देखने योग्य होना चाहिए

That's not a prompting problem. That's an infrastructure problem.

यह प्रॉम्प्टिंग की समस्या नहीं है। यह इंफ्रास्ट्रक्चर की समस्या है।

Van Horn cites @runes_leo: "The costliest thing in AI coding is no longer writing code, it's managing the agent loop." A while True in a terminal doesn't give you any of this. Neither does a long-running process on a VM or sandbox.

Van Horn @runes_leo का हवाला देते हैं: "AI कोडिंग में सबसे महंगी चीज़ अब कोड लिखना नहीं है, बल्कि एजेंट लूप को मैनेज करना है।" टर्मिनल में while True आपको यह सब नहीं देता। न ही VM या सैंडबॉक्स पर लंबे समय तक चलने वाली प्रक्रिया।

Think about what happens when you run an agent loop on a server. The process will die or restarts. A deploy, an OOM, a spot instance reclamation. The loop restarts. But what was it doing? Which step was it on? Did it already send that Slack message? Did it already invoke the sub-agent?

सोचिए कि जब आप एक सर्वर पर एजेंट लूप चलाते हैं तो क्या होता है। प्रक्रिया मर जाएगी या रीस्टार्ट हो जाएगी। एक डिप्लॉय, एक OOM, एक स्पॉट इंस्टेंस रिक्लेमेशन। लूप रीस्टार्ट होता है। लेकिन यह क्या कर रहा था? यह किस स्टेप पर था? क्या यह पहले ही वह Slack मैसेज भेज चुका था? क्या यह पहले ही सब-एजेंट को इनवोक कर चुका था?

You don't know. It starts over. Re-fetches data it already had. Re-calls the LLM for decisions it already made. Sends a duplicate notification. Spawns a duplicate sub-agent. You wake up to three identical Slack messages and a confused team.

आपको पता नहीं है। यह फिर से शुरू होता है। उस डेटा को फिर से लाता है जो उसके पास पहले से था। उन निर्णयों के लिए LLM को फिर से कॉल करता है जो वह पहले ही ले चुका था। एक डुप्लिकेट नोटिफिकेशन भेजता है। एक डुप्लिकेट सब-एजेंट बनाता है। आप तीन एक जैसे Slack मैसेज और एक भ्रमित टीम के साथ जागते हैं।

The fix isn't "better error handling" — it's an execution model where each step is checkpointed, each decision is persisted, and recovery means resuming from the last successful step.

समाधान "बेहतर एरर हैंडलिंग" नहीं है — यह एक एक्ज़ीक्यूशन मॉडल है जहाँ प्रत्येक चरण चेकपॉइंट किया जाता है, प्रत्येक निर्णय संग्रहीत किया जाता है, और रिकवरी का मतलब अंतिम सफल चरण से फिर से शुरू करना है।

The agent loop architecture in three layers

एजेंट लूप आर्किटेक्चर तीन परतों में

Three layers. Each one maps to a concrete primitive.

तीन परतें। प्रत्येक एक ठोस प्रिमिटिव से मैप होती है।

Layer 1: The Loop

परत 1: लूप

A loop is a cron plus a decision-maker. It runs on a schedule (or a trigger), evaluates state, and decides what to do next.

लूप एक क्रॉन प्लस एक निर्णय-निर्माता है। यह एक शेड्यूल (या ट्रिगर) पर चलता है, स्थिति का मूल्यांकन करता है, और तय करता है कि आगे क्या करना है।

This is Van Horn's definition made concrete: what cron never had is the decision in the middle. The agent decides, not you. The cron is the heartbeat. The LLM is the decision-maker. Steps are the durable execution that checkpoint progress.

यह Van Horn की परिभाषा को ठोस बनाता है: क्रॉन में कभी भी बीच में निर्णय लेने की क्षमता नहीं थी। एजेंट निर्णय लेता है, आप नहीं। क्रॉन दिल की धड़कन है। LLM निर्णय-निर्माता है। स्टेप्स टिकाऊ एक्ज़ीक्यूशन हैं जो प्रगति को चेकपॉइंट करते हैं।

1export const infraHealthCheck = inngest.createFunction(
2  { id: "infra-health-check" },
3  { cron: "*/30 * * * *" }, // Every 30 minutes
4  async ({ step }) => {
5    const metrics = await step.run("fetch-service-metrics", async () => {
6      return await fetchServiceMetrics(); // error rates, latency, memory, CPU
7    });
8
9    const assessment = await step.run("assess-health", async () => {
10      return await callLLM({
11        prompt: `Given these service metrics, classify overall system health
12                 as "normal", "degraded", or "critical". Explain your reasoning.
13                 Metrics: ${JSON.stringify(metrics)}`,
14      });
15    });
16
17    if (assessment.status === "degraded" || assessment.status === "critical") {
18      await step.invoke("triage-incident", {
19        function: incidentTriage,
20        data: { metrics, assessment, services: assessment.affectedServices },
21      });
22    }
23  }
24);

Every Monday at 9am, the loop fires. It fetches data, asks the LLM whether a report is warranted, and invokes a skill if yes. If the process restarts between steps, the already-completed steps don't re-execute. That's the loop. Not the LLM, the loop around the LLM.

हर सोमवार सुबह 9 बजे, लूप फायर होता है। यह डेटा लाता है, LLM से पूछता है कि क्या रिपोर्ट उचित है, और यदि हाँ तो एक स्किल को इनवोक करता है। यदि स्टेप्स के बीच प्रक्रिया रीस्टार्ट होती है, तो पहले से पूर्ण किए गए स्टेप्स फिर से नहीं चलते। यही लूप है। LLM नहीं, बल्कि LLM के चारों ओर का लूप।

Layer 2: The Skill

परत 2: स्किल

In this context, a skill is not a prompt. It's a durable workflow. Multi-step, retryable, composable, independently deployable.

इस संदर्भ में, स्किल एक प्रॉम्प्ट नहीं है। यह एक टिकाऊ वर्कफ़्लो है। मल्टी-स्टेप, रिट्राय करने योग्य, कंपोज़ेबल, स्वतंत्र रूप से डिप्लॉय करने योग्य।

Van Horn: "The loop is plumbing. The asset is the skill it calls." This is the part that compounds. Each new skill the system learns makes every loop more capable.

Van Horn: "लूप प्लंबिंग है। परिसंपत्ति वह स्किल है जिसे वह कॉल करता है।" यह वह हिस्सा है जो संयोजित होता है। सिस्टम द्वारा सीखा गया प्रत्येक नया स्किल हर लूप को अधिक सक्षम बनाता है।

1export const incidentTriage = inngest.createFunction(
2  { id: "incident-triage", retries: 3 },
3  { event: "infra.incident.triage" },
4  async ({ event, step }) => {
5    const details = await step.run("fetch-detailed-metrics", async () => {
6      return await fetchDetailedMetrics({ services: event.data.services });
7    });
8
9    const deploys = await step.run("fetch-deploy-history", async () => {
10      return await fetchRecentDeploys({ since: hoursAgo(2) });
11    });
12
13    const analysis = await step.run("correlate-incident", async () => {
14      return await callLLM({
15        prompt: `Correlate these service metrics with recent deploys.
16                 Identify the likely root cause and severity.
17                 Metrics: ${JSON.stringify(details)}
18                 Recent deploys: ${JSON.stringify(deploys)}`,
19      });
20    });
21
22    await step.run("post-triage-summary", async () => {
23      await slack.postMessage({
24        channel: "#incidents",
25        text: formatTriageSummary({
26          analysis,
27          affectedServices: event.data.services,
28          recommendedActions: analysis.recommendations,
29        }),
30      });
31    });
32
33    return analysis;
34  }
35);

This skill fetches, classifies, and routes. It's a unit of work with built-in fault tolerance. The skill can be an AI workflow with an LLM in the middle or deterministic code.

यह स्किल फ़ेच करता है, वर्गीकृत करता है, और रूट करता है। यह बिल्ट-इन फॉल्ट टॉलरेंस के साथ काम की एक इकाई है। स्किल बीच में LLM वाला AI वर्कफ़्लो या डिटरमिनिस्टिक कोड हो सकता है।

Layer 3: The Orchestrator

परत 3: ऑर्केस्ट्रेटर

The orchestrator is the engine that runs everything: schedules crons, executes steps, manages retries, enforces concurrency limits, stores run history, and hot-deploys new functions/workflows without disrupting running ones.

ऑर्केस्ट्रेटर वह इंजन है जो सब कुछ चलाता है: क्रॉन शेड्यूल करता है, स्टेप्स को एक्ज़ीक्यूट करता है, रिट्राइज़ को मैनेज करता है, कंकरेंसी सीमाएँ लागू करता है, रन हिस्ट्री स्टोर करता है, और चल रहे कार्यों को बाधित किए बिना नए फंक्शन/वर्कफ़्लो को हॉट-डिप्लॉय करता है।

This is the layer nobody talks about because it's supposed to be invisible. But it's foundational.

यह वह परत है जिसके बारे में कोई बात नहीं करता क्योंकि यह अदृश्य होने वाली है। लेकिन यह मौलिक है।

Most people think about agents as "LLM + tools." The agent loop architecture re-frames this as agents are "loops + skills + orchestration." The LMM + tools are inside the loops. LLMs and tools can be swapped or tweaked while the architecture remains. The orchestration enables the architecture.

अधिकांश लोग एजेंटों को "LLM + टूल्स" के रूप में सोचते हैं। एजेंट लूप आर्किटेक्चर इसे फिर से इस रूप में तैयार करता है कि एजेंट "लूप + स्किल्स + ऑर्केस्ट्रेशन" हैं। LLM + टूल्स लूप के अंदर हैं। LLM और टूल्स को बदला या ट्वीक किया जा सकता है जबकि आर्किटेक्चर बना रहता है। ऑर्केस्ट्रेशन आर्किटेक्चर को सक्षम बनाता है।

What happens when things break

जब चीज़ें टूटती हैं तो क्या होता है

The happy path is easy. But this is software running in production, do things every really go according to plan?

हैप्पी पाथ आसान है। लेकिन यह प्रोडक्शन में चलने वाला सॉफ्टवेयर है, क्या चीज़ें वास्तव में हमेशा योजना के अनुसार होती हैं?

Your incident triage skill fires and the metrics API times out. The read had to go to disk and the in-memory cache didn't have the data. The step calling this API now retries and hits the API again. The data is now partially cached and the API completes. The skill continues with the next step like nothing ever happened.

आपका इंसिडेंट ट्राइएज स्किल फायर होता है और मेट्रिक्स API टाइम आउट हो जाता है। रीड को डिस्क पर जाना पड़ता है और इन-मेमोरी कैश में डेटा नहीं था। इस API को कॉल करने वाला स्टेप अब रिट्राय करता है और फिर से API को हिट करता है। डेटा अब आंशिक रूप से कैश हो गया है और API पूरा हो जाता है। स्किल अगले स्टेप के साथ जारी रहता है जैसे कुछ हुआ ही न हो।

Sometimes, it may not be as simple as that. What if an API key expires, or your hosting provider is down for 30 minutes. All of your retries are exhausted. Now what happens? You have to also handle failures.

कभी-कभी, यह उतना सरल नहीं हो सकता है। क्या होगा अगर API की चाबी समाप्त हो जाए, या आपका होस्टिंग प्रदाता 30 मिनट के लिए डाउन हो जाए। आपके सभी रिट्राइज़ समाप्त हो जाते हैं। अब क्या होता है? आपको विफलताओं को भी संभालना होगा।

1export const incidentTriage = inngest.createFunction(
2  {
3    id: "incident-triage",
4    retries: 3,
5    onFailure: async ({ error, event, step }) => {
6      // The function failed after exhausting retries.
7      // We still have the original event data. Nothing is lost.
8      await step.run("notify-failure", async () => {
9        await slack.postMessage({
10          channel: "#agent-ops",
11          text: `⚠️ Incident triage failed: ${error.message}. ` +
12                `Will retry on next health check cycle. ` +
13                `Affected services: ${event.data.services.join(", ")}`,
14        });
15      });
16    },
17  },
18  { event: "infra.incident.triage" },
19  async ({ event, step }) => {
20    /* the same logic as the skill above */
21  }
22);

The \onFailure\ handler fires after all retries are exhausted. It posts to an ops channel so someone knows. The event is preserved, nothing is lost. The next scheduled run picks up where the failed one couldn't.

\onFailure\ हैंडलर सभी रिट्राइज़ समाप्त होने के बाद फायर होता है। यह एक ऑप्स चैनल पर पोस्ट करता है ताकि किसी को पता चले। इवेंट सुरक्षित रहता है, कुछ भी नहीं खोता है। अगला शेड्यूल्ड रन वहाँ से शुरू होता है जहाँ असफल रन नहीं हो सका।

Durable orchestration must give you step-level retries for transient errors and failure handling hooks for non-recoverable errors. Without this, things break (as they do), and you find out hours or days later.

टिकाऊ ऑर्केस्ट्रेशन को आपको क्षणिक त्रुटियों के लिए स्टेप-लेवल रिट्राइज़ और गैर-पुनर्प्राप्त करने योग्य त्रुटियों के लिए विफलता हैंडलिंग हुक देने चाहिए। इसके बिना, चीज़ें टूटती हैं (जैसा कि वे करती हैं), और आपको घंटों या दिनों बाद पता चलता है।

Transient errors are also expensive. If your skill or agent retries from the beginning, you're calling LLMs multiple times and burning tokens unnecessarily. The LLM call can be checkpointed. Now multiply this by 10, or 30, agents across your system. That's expensive.

क्षणिक त्रुटियाँ भी महंगी हैं। यदि आपका स्किल या एजेंट शुरुआत से रिट्राय करता है, तो आप LLM को कई बार कॉल कर रहे हैं और अनावश्यक रूप से टोकन जला रहे हैं। LLM कॉल को चेकपॉइंट किया जा सकता है। अब इसे अपने सिस्टम में 10 या 30 एजेंटों से गुणा करें। यह महंगा है।

Step-level checkpointing isn't just a correctness feature. It's a money saver.

स्टेप-लेवल चेकपॉइंटिंग सिर्फ एक शुद्धता सुविधा नहीं है। यह पैसे बचाने वाली चीज़ है।

The agent that builds its own skills

एजेंट जो अपनी खुद की स्किल्स बनाता है

This is where it gets more interesting. The system is not static, it is designed to evolve and extend itself.

यह वह जगह है जहाँ यह और अधिक दिलचस्प हो जाता है। सिस्टम स्थिर नहीं है, इसे विकसित होने और स्वयं का विस्तार करने के लिए डिज़ाइन किया गया है।

The agent doesn't just run inside loops — it authors new loops and registers them with the orchestration engine. Each deployed function is a durable skill that runs independently, triggerable from a loop or agent or running on a schedule, with its own retry logic. Skills compound.

एजेंट सिर्फ लूप के अंदर नहीं चलता — यह नए लूप बनाता है और उन्हें ऑर्केस्ट्रेशन इंजन के साथ पंजीकृत करता है। प्रत्येक डिप्लॉय किया गया फंक्शन एक टिकाऊ स्किल है जो स्वतंत्र रूप से चलता है, लूप या एजेंट से ट्रिगर किया जा सकता है या शेड्यूल पर चल सकता है, अपने स्वयं के रिट्राय लॉजिक के साथ। स्किल्स संयोजित होते हैं।

It's an orchestration-aware agent.

यह एक ऑर्केस्ट्रेशन-अवेयर एजेंट है।

Here's how it works. An AI agent has access to the orchestration SDK as a tool. It can write new functions, register them with the engine, and they start running immediately. The agent process hot-reloads new functions without restarting or disrupting in-flight runs.

यहाँ बताया गया है कि यह कैसे काम करता है। एक AI एजेंट के पास एक टूल के रूप में ऑर्केस्ट्रेशन SDK तक पहुंच है। यह नए फंक्शन लिख सकता है, उन्हें इंजन के साथ पंजीकृत कर सकता है, और वे तुरंत चलने लगते हैं। एजेंट प्रक्रिया चल रहे रन को रीस्टार्ट या बाधित किए बिना नए फंक्शन को हॉट-रिलोड करती है।

Walk through a concrete example:

एक ठोस उदाहरण देखें:

1. A human expresses a need. Engineer says: "Our services keep having latency spikes overnight and nobody notices until morning." This is the trigger. The agent doesn't need to infer a vague pattern from ambient data. It has clear instructions.

1. एक इंसान ज़रूरत बताता है। इंजीनियर कहता है: "हमारी सेवाओं में रात भर लेटेंसी स्पाइक्स होती रहती हैं और सुबह तक किसी को पता नहीं चलता।" यह ट्रिगर है। एजेंट को परिवेशी डेटा से एक अस्पष्ट पैटर्न का अनुमान लगाने की आवश्यकता नहीं है। इसके पास स्पष्ट निर्देश हैं।

2. Agent writes a skill. Two multi-step functions: a health check loop that runs every 30 minutes, pulling error rates, latency, and resource usage, with the LLM classifying system health as normal, degraded, or critical. And an incident triage skill that fetches detailed metrics and recent deploy history, correlates root causes with an LLM, and posts a triage summary to Slack with recommended actions. Error handling: if the metrics API is down, back off and retry. If the LLM fails, fall back to rule-based severity classification.

2. एजेंट एक स्किल लिखता है। दो मल्टी-स्टेप फंक्शन: एक हेल्थ चेक लूप जो हर 30 मिनट में चलता है, एरर रेट, लेटेंसी और रिसोर्स उपयोग खींचता है, LLM के साथ सिस्टम स्वास्थ्य को सामान्य, खराब या गंभीर के रूप में वर्गीकृत करता है। और एक इंसिडेंट ट्राइएज स्किल जो विस्तृत मेट्रिक्स और हाल के डिप्लॉय हिस्ट्री को लाता है, LLM के साथ मूल कारणों को सहसंबंधित करता है, और अनुशंसित कार्यों के साथ Slack पर एक ट्राइएज सारांश पोस्ट करता है। एरर हैंडलिंग: यदि मेट्रिक्स API डाउन है, तो बैक ऑफ और रिट्राय करें। यदि LLM विफल होता है, तो नियम-आधारित गंभीरता वर्गीकरण पर वापस जाएँ।

3. Agent deploys the skill. The agent writes the function code that's picked up by a sidecar process. The new functions are registered automatically. They're live immediately, with no deploy pipeline, no PR.

3. एजेंट स्किल को डिप्लॉय करता है। एजेंट फंक्शन कोड लिखता है जिसे एक साइडकार प्रक्रिया द्वारा उठाया जाता है। नए फंक्शन स्वचालित रूप से पंजीकृत होते हैं। वे तुरंत लाइव होते हैं, बिना किसी डिप्लॉय पाइपलाइन, बिना PR के।

4. Skill runs autonomously. Every 30 minutes, the engine triggers the health check. If something's wrong, it invokes the triage skill. No human in the loop. Fully durable.

4. स्किल स्वायत्त रूप से चलता है। हर 30 मिनट में, इंजन हेल्थ चेक को ट्रिगर करता है। अगर कुछ गलत है, तो यह ट्राइएज स्किल को इनवोक करता है। लूप में कोई इंसान नहीं। पूरी तरह से टिकाऊ।

5. Agent iterates on signal. This is the part people gloss over, so let me be specific about what "iterates" means. The agent doesn't magically notice patterns. It has a separate review loop: a cron-triggered function that runs weekly, reads the run history from the orchestrator, and evaluates performance:

5. एजेंट सिग्नल पर पुनरावृत्ति करता है। यह वह हिस्सा है जिसे लोग नज़रअंदाज कर देते हैं, तो मुझे विशिष्ट होने दें कि "पुनरावृत्ति" का क्या मतलब है। एजेंट जादुई रूप से पैटर्न नहीं देखता है। इसका एक अलग समीक्षा लूप है: एक क्रॉन-ट्रिगर किया गया फंक्शन जो साप्ताहिक चलता है, ऑर्केस्ट्रेटर से रन हिस्ट्री पढ़ता है, और प्रदर्शन का मूल्यांकन करता है:

1export const reviewSkillPerformance = inngest.createFunction(
2  { id: "review-skill-performance" },
3  { cron: "0 10 * * 5" }, // Every Friday at 10am
4  async ({ step }) => {
5    const runs = await step.run("fetch-run-history", async () => {
6      return await getInngestRuns({
7        functionId: "incident-triage",
8        since: daysAgo(7),
9      });
10    });
11
12    const analysis = await step.run("analyze-performance", async () => {
13      const successRate = runs.filter(r => r.status === "completed").length / runs.length;
14      const avgDuration = average(runs.map(r => r.duration));
15      const incidents = await fetchIncidentOutcomes(); // Did incidents correlate with actual outages?
16
17      return await callLLM({
18        prompt: `Review this skill's performance over the past week.
19                 Success rate: ${successRate}
20                 Avg duration: ${avgDuration}ms
21                 Incidents correlated with real outages: ${incidents.confirmed}/${incidents.total}
22                 False positives: ${incidents.falsePositives}
23                 Team acted on alerts: ${incidents.actedOn}/${incidents.total}
24
25                 Should we adjust thresholds or classification? What specific changes?`,
26      });
27    });
28
29    if (analysis.shouldModify) {
30      await step.invoke("update-skill", {
31        function: coreAgent,
32        data: { prompt: `Update the incident-triage skills based on the following proposed changes: ${analysis.proposedChanges}` },
33      });
34    }
35  }
36);

The "review" is a function. It reads run history, checks whether incidents correlated with actual outages, and feeds that signal to the LLM. If the health check keeps flagging a service as degraded but the team ignores it because the thresholds are too sensitive, the review loop catches it, and the skill gets updated to adjust the classification. Not magic. A cron job with an LLM in the decision seat.

"समीक्षा" एक फंक्शन है। यह रन हिस्ट्री पढ़ता है, जाँचता है कि क्या घटनाएँ वास्तविक आउटेज से संबंधित थीं, और उस सिग्नल को LLM को फीड करता है। यदि हेल्थ चेक किसी सेवा को खराब के रूप में फ़्लैग करता रहता है लेकिन टीम इसे अनदेखा करती है क्योंकि थ्रेशोल्ड बहुत संवेदनशील हैं, तो समीक्षा लूप इसे पकड़ लेता है, और वर्गीकरण को समायोजित करने के लिए स्किल अपडेट हो जाता है। जादू नहीं। निर्णय सीट पर LLM के साथ एक क्रॉन जॉब।

What about validation? The agent writing code is only as good as the guardrails around it. The code can be type checked. The agent can invoke the function itself to test it as it's able to interact with the orchestration engine itself. While it's not bullet proof, you are giving the core agent the ability to debug the skills it writes natively within the system it operates. The review loop catches issues that aren't caught with the initial debugging.

मान्यता के बारे में क्या? कोड लिखने वाला एजेंट उतना ही अच्छा है जितने कि उसके आसपास के गार्डरेल। कोड को टाइप चेक किया जा सकता है। एजेंट स्वयं फंक्शन को इनवोक कर सकता है इसका परीक्षण करने के लिए क्योंकि यह स्वयं ऑर्केस्ट्रेशन इंजन के साथ बातचीत करने में सक्षम है। हालांकि यह बुलेटप्रूफ नहीं है, आप कोर एजेंट को उस सिस्टम के भीतर मूल रूप से लिखी गई स्किल्स को डीबग करने की क्षमता दे रहे हैं जिसमें वह संचालित होता है। समीक्षा लूप उन मुद्दों को पकड़ता है जो प्रारंभिक डीबगिंग के साथ नहीं पकड़े जाते हैं।

Taking this a degree further, the agent can use onFailure hooks to trigger itself to evaluate a given failure itself. It's a feedback loop that keeps improving.

इसे एक कदम और आगे ले जाते हुए, एजेंट किसी दी गई विफलता का स्वयं मूल्यांकन करने के लिए खुद को ट्रिगर करने के लिए onFailure हुक का उपयोग कर सकता है। यह एक फीडबैक लूप है जो लगातार सुधार करता रहता है।

What about conflicts? Flow controls, specifically, concurrency controls or singletons handle the simple case (concurrency: \{ limit: 1, key: "[event.data.service" }]) meaning only one incident triage runs at a time per service. But the deeper question is: what if two health checks both detect issues in the same service simultaneously? The orchestrator queues them. Second triage waits until the first completes. No duplicate alerts, no race conditions. This isn't theoretical. It's the same concurrency primitive you'd use in any job queue.

विरोधों के बारे में क्या? फ़्लो कंट्रोल, विशेष रूप से, कंकरेंसी कंट्रोल या सिंगलटन सरल मामले को संभालते हैं (कंकरेंसी: \{ limit: 1, key: "[event.data.service" }]) जिसका अर्थ है कि प्रति सेवा एक बार में केवल एक इंसिडेंट ट्राइएज चलता है। लेकिन गहरा सवाल यह है: यदि दो हेल्थ चेक एक साथ एक ही सेवा में समस्याओं का पता लगाते हैं तो क्या होगा? ऑर्केस्ट्रेटर उन्हें कतारबद्ध करता है। दूसरा ट्राइएज पहले के पूरा होने तक प्रतीक्षा करता है। कोई डुप्लिकेट अलर्ट नहीं, कोई रेस कंडीशन नहीं। यह सैद्धांतिक नहीं है। यह वही कंकरेंसी प्रिमिटिव है जिसका उपयोग आप किसी भी जॉब क्यू में करेंगे।

The agent isn't just executing tasks. It's building infrastructure for itself. Each skill persists beyond the conversation that created it. Kill the agent process and restart it. The skills keep running. Swap the underlying model. The skills keep running. The agent is ephemeral — its output is durable.

एजेंट सिर्फ कार्यों को निष्पादित नहीं कर रहा है। यह अपने लिए बुनियादी ढाँचा बना रहा है। प्रत्येक स्किल उस बातचीत से परे बना रहता है जिसने इसे बनाया। एजेंट प्रक्रिया को मारें और इसे पुनः आरंभ करें। स्किल्स चलते रहते हैं। अंतर्निहित मॉडल को बदलें। स्किल्स चलते रहते हैं। एजेंट क्षणिक है — इसका आउटपुट टिकाऊ है।

Agent loop architecture system overview

एजेंट लूप आर्किटेक्चर सिस्टम अवलोकन

The developer's view

डेवलपर का दृष्टिकोण

This matters because if the developer can't see what the agent deployed, debug what broke, and audit what ran at 3am, the whole architecture is a major liability.

यह मायने रखता है क्योंकि यदि डेवलपर यह नहीं देख सकता कि एजेंट ने क्या डिप्लॉय किया, क्या टूटा उसे डीबग नहीं कर सकता, और रात 3 बजे क्या चला उसका ऑडिट नहीं कर सकता, तो पूरी आर्किटेक्चर एक बड़ी देयता है।

The orchestration engine stores every run, every step, every input, every output, every retry. A skill the agent deployed last Tuesday that failed at 4am? You can see exactly which step failed, what the input was, what error it threw, and how many times it retried before giving up. Full traces down to the step level are the output of the orchestration engine itself.

ऑर्केस्ट्रेशन इंजन हर रन, हर स्टेप, हर इनपुट, हर आउटपुट, हर रिट्राय को स्टोर करता है। पिछले मंगलवार को एजेंट द्वारा डिप्लॉय किया गया एक स्किल जो सुबह 4 बजे विफल हुआ? आप ठीक से देख सकते हैं कि कौन सा स्टेप विफल हुआ, इनपुट क्या था, उसने कौन सी एरर फेंकी, और हार मानने से पहले उसने कितनी बार रिट्राय किया। स्टेप स्तर तक पूर्ण ट्रेसेज़ स्वयं ऑर्केस्ट्रेशन इंजन का आउटपुट हैं।

This isn't a dashboard bolted on after the fact. It's inherent to durable execution. Every step.run() is a checkpoint. Every checkpoint is observable. When the thing that wrote the code isn't a human, observability isn't a nice-to-have — it's the trust layer.

यह बाद में जोड़ा गया डैशबोर्ड नहीं है। यह टिकाऊ एक्ज़ीक्यूशन में निहित है। प्रत्येक step.run() एक चेकपॉइंट है। प्रत्येक चेकपॉइंट अवलोकन योग्य है। जब कोड लिखने वाली चीज़ इंसान नहीं है, तो अवलोकन क्षमता एक अच्छी-से-होने वाली चीज़ नहीं है — यह विश्वास परत है।

Day-to-day, the developer's workflow looks like this: check the runs dashboard in the morning. See which skills ran overnight, which succeeded, which failed. If a skill the agent wrote is misbehaving, you can read the code directly, edit it, delete it, or tell the agent to fix it. The agent authored it, but you own it. The agent and its skills are still a garden that you should tend to.

दिन-प्रतिदिन, डेवलपर का वर्कफ़्लो इस तरह दिखता है: सुबह रन डैशबोर्ड चेक करें। देखें कि रात भर कौन से स्किल चले, कौन से सफल हुए, कौन से विफल हुए। यदि एजेंट द्वारा लिखा गया कोई स्किल गलत व्यवहार कर रहा है, तो आप सीधे कोड पढ़ सकते हैं, उसे संपादित कर सकते हैं, हटा सकते हैं, या एजेंट को इसे ठीक करने के लिए कह सकते हैं। एजेंट ने इसे लिखा है, लेकिन आप इसके मालिक हैं। एजेंट और उसकी स्किल्स अभी भी एक बगीचा है जिसकी आपको देखभाल करनी चाहिए।

Why durability is foundational

टिकाऊपन क्यों मौलिक है

Van Horn: "These things have to survive a restart."

Van Horn: "इन चीज़ों को एक रीस्टार्ट से बचना होगा।"

Here's what durability means in practice:

व्यवहार में टिकाऊपन का यही अर्थ है:

"Just run it in a container" gets you uptime. It doesn't get you correctness. A container that restarts after a crash brings the process back, but every in-flight loop starts over. Every step re-executes. Every LLM call is re-made. The loop looks like it's running, but it's running blind.

"बस इसे एक कंटेनर में चलाएँ" आपको अपटाइम देता है। यह आपको शुद्धता नहीं देता है। एक कंटेनर जो क्रैश के बाद रीस्टार्ट होता है, प्रक्रिया वापस लाता है, लेकिन हर इन-फ़्लाइट लूप फिर से शुरू होता है। हर कदम फिर से निष्पादित होता है। हर LLM कॉल फिर से की जाती है। लूप चलता हुआ दिखता है, लेकिन यह आँख बंद करके चल रहा है।

How this compares to existing tools

यह मौजूदा टूल्स से कैसे तुलना करता है

Some tools may offer you a "pretty" turnkey solution to this type of system or you might choose to cobble together some lower level tools and create your own system. Neither choice is wrong, but the right architecture layer should allow you, and your agent, to evolve over time. Flexible, dynamic, durable.

कुछ उपकरण आपको इस प्रकार के सिस्टम का "सुंदर" टर्नकी समाधान दे सकते हैं या आप कुछ निचले स्तर के उपकरणों को एक साथ जोड़कर अपना स्वयं का सिस्टम बनाना चुन सकते हैं। कोई भी विकल्प गलत नहीं है, लेकिन सही आर्किटेक्चर परत को आपको, और आपके एजेंट को, समय के साथ विकसित होने की अनुमति देनी चाहिए। लचीला, गतिशील, टिकाऊ।

Durable execution primitives that fit nicely for an agent, that and agent can easily write, and the observability and APIs to observe and enable the agent itself to be orchestration aware.

टिकाऊ एक्ज़ीक्यूशन प्रिमिटिव जो एक एजेंट के लिए अच्छी तरह से फिट होते हैं, जिसे एजेंट आसानी से लिख सकता है, और एजेंट को स्वयं ऑर्केस्ट्रेशन-अवेयर होने का निरीक्षण करने और सक्षम करने के लिए अवलोकन क्षमता और API।

A working example

एक कार्यशील उदाहरण

We're testing these patterns internally at Inngest and you can see a concept of this in the "utah" project repo here: https://github.com/inngest/utah: It's an agent harness built on top of Inngest's durable orchestration that also is orchestration-aware.

हम Inngest में आंतरिक रूप से इन पैटर्न का परीक्षण कर रहे हैं और आप इसकी एक अवधारणा "utah" प्रोजेक्ट रेपो में यहाँ देख सकते हैं: https://github.com/inngest/utah: यह Inngest के टिकाऊ ऑर्केस्ट्रेशन के शीर्ष पर बनाया गया एक एजेंट हार्नेस है जो ऑर्केस्ट्रेशन-अवेयर भी है।

The system has a sidecar process that enables the main agent to write and edit Inngest functions in it's own workspace, extending itself with "skills" (in the context of this article). Soon, we're planning to provide an entire system with starter loops as examples, but the ideas there can demonstrate the ideas in this article a bit more clearly.

सिस्टम में एक साइडकार प्रक्रिया है जो मुख्य एजेंट को अपने स्वयं के वर्कस्पेस में Inngest फंक्शन लिखने और संपादित करने में सक्षम बनाती है, "स्किल्स" (इस लेख के संदर्भ में) के साथ स्वयं का विस्तार करता है। जल्द ही, हम स्टार्टर लूप के उदाहरणों के साथ एक संपूर्ण सिस्टम प्रदान करने की योजना बना रहे हैं, लेकिन वहाँ के विचार इस लेख के विचारों को थोड़ा और स्पष्ट रूप से प्रदर्शित कर सकते हैं।

The compounding loop

संयोजित होने वाला लूप

Satya Nadella's recent post named something the industry has been feeling: the moat isn't the model — it's the loop.

Satya Nadella की हालिया पोस्ट ने उस चीज़ का नाम रखा जो उद्योग महसूस कर रहा है: खाई मॉडल नहीं है — यह लूप है।

His framing: there are two types of capital. Human capital, the knowledge and judgment your team built over years. And what he calls token capital, the AI workflows, decision patterns, and learned skills a company builds on top of foundation models.

उनकी फ्रेमिंग: दो प्रकार की पूंजी होती है। मानव पूंजी, वह ज्ञान और निर्णय जो आपकी टीम ने वर्षों में बनाया है। और जिसे वे टोकन पूंजी कहते हैं, AI वर्कफ़्लो, निर्णय पैटर्न, और सीखी गई स्किल्स जो एक कंपनी फाउंडेशन मॉडल के शीर्ष पर बनाती है।

The thesis: these compound together. Every improved workflow generates better signal. Better signal produces sharper AI behavior. Sharper behavior frees up human attention for higher-judgment work. A hill climbing machine.

थीसिस: ये एक साथ संयोजित होते हैं। प्रत्येक बेहतर वर्कफ़्लो बेहतर सिग्नल उत्पन्न करता है। बेहतर सिग्नल तेज AI व्यवहार उत्पन्न करता है। तेज व्यवहार उच्च-निर्णय वाले काम के लिए मानवीय ध्यान मुक्त करता है। एक पहाड़ी चढ़ने वाली मशीन।

This is what the agent loop architecture enables concretely:

यह वही है जो एजेंट लूप आर्किटेक्चर ठोस रूप से सक्षम बनाता है:

• Every durable skill the agent deploys is institutional knowledge encoded as executable infrastructure. It persists. It runs whether or not a human is watching.
• एजेंट द्वारा डिप्लॉय किया गया प्रत्येक टिकाऊ स्किल संस्थागत ज्ञान है जो निष्पादन योग्य बुनियादी ढाँचे के रूप में एन्कोड किया गया है। यह बना रहता है। यह चलता है चाहे कोई इंसान देख रहा हो या नहीं।
• A cron-triggered review loop that evaluates skill performance and iterates. That's the hill climbing machine made real. Not a flywheel diagram in a deck. A function with a cron trigger.
• एक क्रॉन-ट्रिगर किया गया समीक्षा लूप जो स्किल प्रदर्शन का मूल्यांकन करता है और पुनरावृत्ति करता है। यह वास्तविक बनी पहाड़ी चढ़ने वाली मशीन है। डेक में फ्लाईव्हील आरेख नहीं। क्रॉन ट्रिगर वाला एक फंक्शन।
• If your skills die on process restart, the compounding resets to zero. Durability is what makes the investment persist.
• यदि आपकी स्किल्स प्रक्रिया रीस्टार्ट पर मर जाती हैं, तो संयोजन शून्य पर रीसेट हो जाता है। टिकाऊपन ही निवेश को बनाए रखता है।

Nadella's key point: "A company should be able to switch out a 'generalist' model without losing the 'company veteran' expertise built into their learning system." That's the skill library pattern. Durable functions don't care which LLM calls them.

Nadella का मुख्य बिंदु: "एक कंपनी को अपने लर्निंग सिस्टम में निर्मित 'कंपनी वेटरन' विशेषज्ञता को खोए बिना एक 'जनरलिस्ट' मॉडल को बदलने में सक्षम होना चाहिए।" यह स्किल लाइब्रेरी पैटर्न है। टिकाऊ फंक्शन इस बात की परवाह नहीं करते कि उन्हें कौन सा LLM कॉल करता है।

Build accordingly

तदनुसार निर्माण करें

The conversation has been about what agents do: loops, tools, reasoning, context engineering. The next conversation is about what runs the agents.

बातचीत इस बारे में रही है कि एजेंट क्या करते हैं: लूप, टूल्स, रीज़निंग, कॉन्टेक्स्ट इंजीनियरिंग। अगली बातचीत इस बारे में है कि एजेंटों को क्या चलाता है।

Three layers: loop, skill, orchestrator. The loop is the unit of work. The skill is the asset. The orchestration engine is what makes both durable. The sidecar pattern is the model: an agent writes its own durable skills, deploys them, reviews how they perform, and iterates. Not a thought experiment. It's a working model.

तीन परतें: लूप, स्किल, ऑर्केस्ट्रेटर। लूप काम की इकाई है। स्किल परिसंपत्ति है। ऑर्केस्ट्रेशन इंजन वह है जो दोनों को टिकाऊ बनाता है। साइडकार पैटर्न मॉडल है: एक एजेंट अपनी स्वयं की टिकाऊ स्किल्स लिखता है, उन्हें डिप्लॉय करता है, समीक्षा करता है कि वे कैसे प्रदर्शन करते हैं, और पुनरावृत्ति करता है। कोई विचार प्रयोग नहीं। यह एक कार्यशील मॉडल है।

We built Inngest to be the orchestration engine for this: step.run(), step.invoke(), cron triggers, event-driven control flow, concurrency controls, and full step-level observability. But the architecture pattern is bigger than any single tool. If you're building agent loops in production, define the three layers.

हमने Inngest को इसके लिए ऑर्केस्ट्रेशन इंजन बनाया है: step.run(), step.invoke(), क्रॉन ट्रिगर, इवेंट-ड्रिवन कंट्रोल फ़्लो, कंकरेंसी कंट्रोल, और पूर्ण स्टेप-लेवल अवलोकन क्षमता। लेकिन आर्किटेक्चर पैटर्न किसी एक टूल से बड़ा है। यदि आप प्रोडक्शन में एजेंट लूप बना रहे हैं, तो तीन परतों को परिभाषित करें।

The primitives exist today. Build accordingly.

प्रिमिटिव आज मौजूद हैं। तदनुसार निर्माण करें।