# Stripe ने सैकड़ों Agents चलाकर localhost क्यों छोड़ा — रात भर खुद करके देखा, तो समझ आया

> Author: Tony Lee
> Published: 2026-03-03
> URL: https://tonylee.im/hi/blog/why-stripe-abandoned-localhost-for-agent-fleet/
> Reading time: 5 minutes
> Language: hi
> Tags: ai, ai-agent, devops, infrastructure, stripe, developer-productivity

## Description

12 घंटे के hackathon में सिर्फ agents से product बनाने की कोशिश की, तो समझ आया कि Stripe Minions और Ramp Inspect ने cloud isolation क्यों चुना।

## Content

कल रात एक hackathon का एक ही rule था — रात 8 बजे spec और harness setup करो, सुबह 8 बजे तक keyboard से हाथ हटा लो। पूरे 12 घंटे सिर्फ agents के भरोसे product बनाना था।

इस experiment ने मुझे समझा दिया कि Stripe ने [Minions platform](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents) launch करते हुए और Ramp ने [अपना background agent Inspect](https://builders.ramp.com/post/why-we-built-our-background-agent) बनाने के बाद "localhost खत्म हो गया" क्यों कहा। 12 घंटे में यह बात खुद महसूस हो गई।

## एक ही machine पर parallel agents चलाओ, तो झगड़ा शुरू हो जाता है

जब कई agents एक ही machine पर चलते हैं, तो state गड़बड़ा जाती है। Secrets टकराते हैं, ports conflict करते हैं, और जैसे ही machine sleep mode में जाती है — पूरा 12 घंटे का loop बर्बाद।

जब Stripe और Ramp ने अपना agent architecture share किया, तो दोनों में एक common pattern था — हर agent को अलग VM और development container देना।

Stripe के Minions "devbox" नाम के isolated environment में चलते हैं। Machine type वही है जो engineers इस्तेमाल करते हैं, लेकिन production resources और internet से पूरी तरह cut off। 10 seconds में spin up होता है, और git worktree overhead के बिना parallel tasks चला सकता है।

Ramp का Inspect, Modal Sandbox पर बना है। हर session के पास अपना independent full-stack environment है — Postgres, Redis, Temporal, RabbitMQ सब कुछ। Sessions के बीच कोई contention नहीं, और filesystem snapshots की वजह से startup लगभग instant होता है।

Coding agents को आपके laptop और आपका ध्यान चाहिए — background agents को कुछ नहीं। रात भर चलाते वक्त एक बार machine sleep हुई और पूरा loop रुक गया। Cloud VM में ऐसा नहीं होता।

## Tasks एक-एक करके देते रहे, तो सिर्फ आसान features मिले

Hackathon का सबसे दर्दनाक moment यही था। Sequential execution से agents चलाओ तो simple CRUD आ जाता है। दिक्कत तब शुरू होती है जब dependencies आती हैं। पहले बना module बाद में चल रहे agent ने overwrite कर दिया या conflict हो गया — यह बार-बार हुआ।

यहीं पर agent fleet और agent swarm का फर्क समझना जरूरी है।

**Agent fleet** — एक ही change को कई repositories पर एक साथ apply करने का pattern है। Stripe हर हफ्ते 1,000 से ज्यादा PRs merge कर पाता है इसी structure की वजह से। एक ही migration, एक ही lint fix को सैकड़ों services पर एक साथ push करना।

**Agent swarm** — अलग-अलग parts अलग agents को देकर एक result में converge करने का pattern। Frontend, backend, tests — तीनों अलग agents संभालते हैं, और PR level पर merge होता है।

Sequential नहीं, बल्कि parallel execution के बाद PR level merge का structure हो — तभी complex product बनता है। खुद करके देखा तो parallel + merge review combination की quality, sequential से कहीं बेहतर निकली।

## Rate limits और agents के बीच communication — यह prompt से नहीं, infrastructure से हल होता है

12 घंटे के loop में rate limits से बचना नामुमकिन था। ऊपर से यह भी चाहिए था कि एक agent का commit दूसरा agent review करे, और spec में ambiguous parts को automatically re-evaluate करे।

एक बात बिल्कुल सही है — "system prompt में 'file मत delete करना' लिखना request है, control नहीं।"

Stripe ने इस problem को execution layer पर solve किया। Minions में production resources और internet access structurally blocked है — बिना permission check के भी safe execution होता है। 400 से ज्यादा MCP tools को "Toolshed" नाम के internal server पर host किया गया है, और हर agent के लिए accessible tools का set curate किया जाता है।

Ramp ने GitHub OAuth के जरिए ensure किया कि हर PR एक real user account से बने — app ID से नहीं, personal account से। इससे review के बिना code merge होना structurally रुक जाता है।

Permission scope को execution layer पर lock करना, audit logs रखना, और failure radius limit करना — यह सब न हो तो security team कभी autonomous agents को approve नहीं करेगी।

## Individual तेज हो जाए, organization नहीं होती — यह trap है

इसे "false summit" कह सकते हैं। Coding agents लाओ तो PRs तो ढेर हो जाते हैं, लेकिन cycle time वही रहता है। Reviews pile up होते हैं, CI break होता है, merge conflicts जमते जाते हैं।

Hackathon में भी यही हुआ — agents ने code तेजी से बना दिया, लेकिन उस output को merge करने और validate करने की bottleneck में सारा time चला गया।

Stripe इस bottleneck को automation से तोड़ता है। Minions एक hybrid orchestration use करता है जो agent loop और deterministic code operations को interleave करता है। Linting, testing, git operations हमेशा complete हों यह ensure करता है, साथ ही agent की creativity भी बनाए रखता है। CI tests को maximum 2 retries तक limit किया है ताकि infinite loop में न फंसे।

Ramp के लिए success metric है — merged PRs की संख्या। Inspect के बनाए 50% से ज्यादा PRs actually merge हो रहे हैं, और Inspect खुद 80% से ज्यादा Inspect से ही लिखा गया है।

Background agents को PR review, CI failure analysis, और merge conflict resolution इंसान से पहले handle करना होगा — तभी organization की speed बढ़ती है। "In the loop" (खुद operate करना) से "on the loop" (सिर्फ result check करना) — यही असली shift है।

## असली जंग बनाने की speed नहीं, merge करने का structure है

Agents को तेजी से बनाना — यह problem तो solve हो चुकी है। Stripe हर हफ्ते 1,000 से ज्यादा PRs बना रहा है, Ramp के आधे से ज्यादा PRs agents के हैं।

असली challenge है — agents के output को safely merge करने का system design करना। Isolated execution environment, parallel-then-merge structure, infrastructure-level governance, और automated validation — यह चार चीजें न हों तो agent सिर्फ एक fast toy है।

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/hi/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.