diff --git a/public/banners/how-i-vetted-20-vps-providers-with-parallel-subagents.png b/public/banners/how-i-vetted-20-vps-providers-with-parallel-subagents.png
new file mode 100644
index 0000000..f5a5643
Binary files /dev/null and b/public/banners/how-i-vetted-20-vps-providers-with-parallel-subagents.png differ
diff --git a/public/og/how-i-vetted-20-vps-providers-with-parallel-subagents.png b/public/og/how-i-vetted-20-vps-providers-with-parallel-subagents.png
new file mode 100644
index 0000000..8bed130
Binary files /dev/null and b/public/og/how-i-vetted-20-vps-providers-with-parallel-subagents.png differ
diff --git a/scripts/banner-gen/generate.mjs b/scripts/banner-gen/generate.mjs
index 00487bb..924f68f 100644
--- a/scripts/banner-gen/generate.mjs
+++ b/scripts/banner-gen/generate.mjs
@@ -189,6 +189,25 @@ const BANNERS = {
{ n: '5', label: 'verdict ✓' },
],
},
+
+ 'how-i-vetted-20-vps-providers-with-parallel-subagents': {
+ titlebar: '~/vendor-due-diligence — fan-out',
+ lines: [
+ { t: 'prompt', text: '$' }, { t: 'cmd', text: 'delegate → 3 subagents, 20 providers' },
+ { t: 'dim', text: 'batch A: 5 · batch B: 6 · batch C: 9 (parallel)' },
+ { t: 'info', text: 'each → WHOIS · AUP · privacy · pricing · reviews' },
+ { t: 'prompt', text: '$' }, { t: 'cmd', text: 'merge → one scorecard' },
+ { t: 'hl', text: 'aup flags: "TOR nodes" · domain-age mismatch · metered cap' },
+ { t: 'prompt', text: '' }, { t: 'ok', text: '→ ~20 providers audited in 3h ✓' },
+ ],
+ flow: [
+ { n: '1', label: 'checklist' },
+ { n: '2', label: '3 subagents' },
+ { n: '3', label: 'parallel fetch' },
+ { n: '4', label: 'scorecard' },
+ { n: '5', label: 'verdict ✓' },
+ ],
+ },
};
const DEFAULT_BANNER = {
diff --git a/scripts/og-gen/generate.mjs b/scripts/og-gen/generate.mjs
index 4673197..4daa022 100644
--- a/scripts/og-gen/generate.mjs
+++ b/scripts/og-gen/generate.mjs
@@ -70,10 +70,15 @@ const TERMINALS = {
$strip id · replace() suffix→ updated ✓
`,
'how-to-verify-a-hosting-provider-before-you-buy': `
- $curl -s rdap.org/domain/vps.tld | jq .events
- registration: 2026-05 · \"trusted since 2012\"
- $AUP grep tor · reviews · retention→ verdict ✓
`,
-};
+ $curl -s rdap.org/domain/vps.tld | jq .events
+ registration: 2026-05 · "trusted since 2012"
+ $AUP grep tor · reviews · retention→ verdict ✓
`,
+
+ 'how-i-vetted-20-vps-providers-with-parallel-subagents': `
+ $fan-out → 3 subagents × 20 providers
+ whois · AUP · reviews · retention — in parallel
+ $merge scorecard · rank · audit trail→ verdict ✓
`,
+ };
const DEFAULT_TERMINAL = `
$engineering · devops · self-hosting
diff --git a/src/content/posts/how-i-vetted-20-vps-providers-with-parallel-subagents.md b/src/content/posts/how-i-vetted-20-vps-providers-with-parallel-subagents.md
new file mode 100644
index 0000000..52c157e
--- /dev/null
+++ b/src/content/posts/how-i-vetted-20-vps-providers-with-parallel-subagents.md
@@ -0,0 +1,163 @@
+---
+title: "How I Vetted 20 VPS Providers in Three Hours with Parallel Subagents"
+description: "A case study in orchestrating parallel AI subagents to run due diligence on 20 hosting providers — WHOIS, AUP, and reputation checks — collapsing a multi-hour research task into a structured, verifiable vendor scorecard."
+pubDate: 2026-09-09
+category: case-studies
+tags: [ai-orchestration, subagents, due-diligence, hosting, devops]
+ogImage: /og/how-i-vetted-20-vps-providers-with-parallel-subagents.png
+banner: /banners/how-i-vetted-20-vps-providers-with-parallel-subagents.png
+---
+
+## Why it matters
+
+Choosing a hosting provider is a bet you place with a credit card and a DNS
+change. Get it wrong and "guaranteed uptime" becomes a suspension email at 2 AM,
+or "privacy-friendly" becomes a log-retention clause you never read.
+
+The problem isn't a lack of information — it's that the information is scattered
+across a dozen pages per provider (WHOIS records, acceptable-use policies,
+privacy policies, pricing pages, and third-party review sites), and checking them
+manually is slow, boring, and error-prone. One provider is five tabs. Twenty
+providers is a hundred tabs and an afternoon you don't get back.
+
+This is the story of how I collapsed that afternoon into about three hours — not
+by working faster, but by orchestrating a small team of AI subagents to run the
+boring part in parallel, and scoring everything against one checklist.
+
+## The problem: verifying claims I couldn't take on faith
+
+I needed to shortlist providers for a project with hard requirements: specific
+jurisdictions, payment methods, and traffic terms. None of those are written
+honestly on a homepage. They're written honestly in the boring documents — the
+WHOIS record that shows a domain is four months old, the AUP that quietly bans
+the exact service you wanted to run, the privacy policy that admits to log
+retention.
+
+The hard part is that verifying one provider means reading five documents that
+disagree with each other. The marketing says "since 2012"; the WHOIS says "this
+April." The features page says "all traffic allowed"; the AUP says "Tor relays
+prohibited." One provider is a fact-checking exercise. Twenty is a research
+project.
+
+## What I tried first: one agent, one big loop
+
+My first instinct was the obvious one — a single assistant that works through the
+list, provider by provider, fetching each document, taking notes, moving on.
+
+It worked. It was also the wrong tool for the shape of the job. The work is
+*embarrassingly parallel*: provider #7's WHOIS lookup has nothing to do with
+provider #3's privacy policy. Running them one after another meant the total time
+was the sum of every fetch, and — more importantly — the context window filled
+with half-finished notes from providers I'd already moved past. By provider
+eight or nine, early findings were getting crowded out by later ones.
+
+The lesson: a task that's a flat loop over independent items isn't a reasoning
+problem, it's a fan-out problem. One long context is the wrong container for it.
+
+## The fix: fan out with parallel subagents, then score once
+
+The structure that worked was three layers:
+
+**1. A checklist that doesn't care which provider it's pointed at.** Before
+spawning anything, I wrote down exactly what "verified" means per provider:
+
+- domain registration date vs. the "since" claim
+- acceptable-use policy, searched for the specific service I cared about
+- privacy policy, read for the retention clause
+- third-party reputation (Trustpilot trend, not average; community mentions)
+- traffic terms ("unmetered" vs. a metered cap)
+
+That checklist was the contract. Every subagent got the same one, plus a list of
+providers to run it against.
+
+**2. Parallel subagents, one per batch of providers.** I split the pool into
+clusters and handed each cluster to its own subagent. Each one worked in
+isolation, with its own context and its own set of fetches, and returned a
+structured fact sheet per provider — not a paragraph, but fields I could drop
+straight into a scorecard.
+
+The key here is that the subagents don't know about each other. That's the
+point: nothing from provider #1 has to share context space with provider #14.
+Each returns a self-contained result.
+
+**3. A single scoring pass, done by me, not delegated.** The subagents produced
+findings; I did the judgment. The moment you let a subagent both *gather* the
+facts and *rank* the providers, you lose the audit trail — you get a verdict
+without the evidence behind it. Keeping scoring central means I can always say
+*why* something ranked where it did, and point at the exact WHOIS record or AUP
+line that drove it.
+
+This mirrors a pattern I'd use for any code review or refactor: parallelize the
+mechanical collection, centralize the decisions.
+
+### What the orchestration actually looked like
+
+Roughly, per batch:
+
+```text
+subagent → "here's the checklist, here are your 5 providers"
+ → per provider: fetch WHOIS, AUP, privacy policy, pricing, reviews
+ → return { domain_age, aup_flags[], retention, reputations, traffic }
+me → merge into one scorecard, apply the checklist, rank, write up
+```
+
+Three subagents ran side by side. The whole pass — twenty providers, five
+documents each, one hundred-ish fetches — landed in the time it would have taken
+me to do two or three providers carefully by hand.
+
+## What the verification actually caught
+
+The scorecard surfaced real problems that a homepage never would have:
+
+- **A provider whose "trusted since 2012" claim was younger than the domain.**
+ WHOIS said the domain was registered that same year — a four-figure "years in
+ business" claim on a domain months old. That's either a re-branded shell or a
+ lie, and either way it downgraded every other claim on the page in my eyes.
+
+- **Two providers whose AUP banned the exact service I wanted to run.** One
+ listed "TOR nodes" and "anonymizing services" in its prohibited-activity
+ clause; another banned "reverse proxies" and "tunnels." Both still advertised
+ the opposite on their features pages. Ten minutes of `Ctrl-F` on the AUP is all
+ it took to rule them out — but only once I *knew to check the AUP* instead of
+ the features page.
+
+- **A provider that looked cheap until I read the traffic terms.** "Unlimited" on
+ a plan with a metered 1 TB cap is marketing. For a relay that both receives and
+ forwards traffic, the real cost doubles — the "cheap" option wasn't.
+
+The pattern across all of them: the disqualifying information was never hidden.
+It was *public*, sitting in a document the provider is legally required to
+publish. The skill isn't secret access — it's knowing which document to read and
+checking it against the marketing.
+
+## What I'd do differently
+
+The subagent hand-off worked, but it was blunt. Next time I'd give each subagent
+the *exact* fields to return up front — a strict output schema — rather than a
+prose summary I then have to re-parse. Structured output means the scorecard is
+built by the time the last subagent returns, with no re-reading.
+
+I'd also pin the "is this claim independently verifiable?" test earlier. Most of
+the red flags weren't a provider lying outright; they were a claim I couldn't
+check against any public record. Treat "unverifiable" as its own signal, and the
+shortlist shrinks fast.
+
+## The result
+
+~20 providers audited across ~100 document fetches, three subagents running in
+parallel, in the time a careful manual pass would have spent on two providers.
+Every ranking in the final scorecard traces back to a specific public record —
+a WHOIS date, an AUP line, a retention clause — not a vibe.
+
+---
+
+## Want this for your business?
+
+Choosing a vendor is the same shape of problem whether it's a VPS, an API
+gateway, or a payroll provider: verify the claims you're relying on *before* you
+sign, against public records that can't be edited by marketing. If you've got a
+shortlist of vendors or tools and you want a structured, evidence-backed
+evaluation before you commit — I can run the due-diligence pass and hand you a
+scorecard, not a hunch.
+
+[WhatsApp me](https://wa.me/60127972969) or [email me](mailto:me@hoelee.com?subject=Vendor%20due-diligence%20evaluation) at hoelee.com — I help businesses pick the right infrastructure and build the automation around it.
\ No newline at end of file
diff --git a/src/content/posts/zh/how-i-vetted-20-vps-providers-with-parallel-subagents.md b/src/content/posts/zh/how-i-vetted-20-vps-providers-with-parallel-subagents.md
new file mode 100644
index 0000000..3368133
--- /dev/null
+++ b/src/content/posts/zh/how-i-vetted-20-vps-providers-with-parallel-subagents.md
@@ -0,0 +1,135 @@
+---
+title: "如何用并行子代理在三小时内核查 20 家 VPS 服务商"
+description: "一个关于编排并行 AI 子代理对 20 家主机服务商做尽职调查的案例研究——WHOIS、AUP 和口碑核查——把数小时的研究任务压缩成一份结构化、可追溯的供应商评分卡。"
+pubDate: 2026-09-09
+category: case-studies
+tags: [ai-orchestration, subagents, due-diligence, hosting, devops]
+ogImage: /og/how-i-vetted-20-vps-providers-with-parallel-subagents.png
+banner: /banners/how-i-vetted-20-vps-providers-with-parallel-subagents.png
+---
+
+## 为什么这很重要
+
+选主机服务商，本质是用一张信用卡和一次 DNS 变更来下注。选错了，「保证在线率」
+会变成凌晨两点的封停邮件，「注重隐私」会变成一条你从没读过的日志留存条款。
+
+问题不是信息不够，而是信息散落在每家服务商的十几个页面里（WHOIS 记录、可接受使用
+政策、隐私政策、价格页、第三方评测站），手工核查又慢又枯燥又容易出错。一家服务商
+就是五个标签页，二十家就是一百个标签页和一下午搭进去的时间。
+
+这个故事讲的是我怎么把那一整个下午压到大约三小时——不是靠更快地干活，而是靠编排
+一支 AI 子代理小队并行跑完枯燥的部分，再用同一张清单给所有结果打分。
+
+## 问题：我不能靠信仰去核实的那些声明
+
+我要为一个有硬性要求的项目筛选服务商：具体的司法辖区、付款方式、流量条款。这些
+没有一样是首页上诚实地写出来的。它们诚实地写在那些无聊的文档里——WHOIS 记录显示
+域名才四个月、AUP 静悄悄地禁掉你正想跑的服务、隐私政策承认自己保留日志。
+
+难就难在，核实一家服务商意味着读五份互相矛盾的文档。营销说「自 2012 年起」，
+WHOIS 说「今年四月才注册」。特性页说「允许所有流量」，AUP 说「禁止 Tor 中继」。
+一家服务商就是一次事实核查，二十家就是一个研究项目。
+
+## 第一次尝试：一个 agent，一个大循环
+
+我最先想到的当然是显而易见的那个——单个助手从头到尾挨个处理这份名单，逐家抓取
+文档、记笔记、往下走。
+
+它能跑。但它对这份工作的形状来说是错的工具。这活儿**天然可并行**：7 号服务商的
+WHOIS 查询和 3 号服务商的隐私政策毫无关系。串行跑意味着总耗时是每次抓取之和，而且
+——更重要的是——上下文窗口会被我已经翻过去的那几家的半成品笔记塞满。到第八九家
+的时候，早期的发现就被后面的挤掉了。
+
+教训是：一个对独立条目做扁平循环的任务，不是推理问题，而是扇出（fan-out）问题。
+一个长长的上下文是装它的错误容器。
+
+## 修复：用并行子代理扇出，然后统一打分
+
+真正奏效的结构是三层：
+
+**1. 一张不在乎指向谁的清单。** 在派发任何东西之前，我先写下对每家服务商而言
+「已核实」具体意味着什么：
+
+- 域名注册日期 对比 那个「since」声明
+- 可接受使用政策（AUP），搜我关心的具体服务
+- 隐私政策，读留存条款
+- 第三方口碑（Trustpilot 看趋势，不看均值；社区提及）
+- 流量条款（「防计量」还是一个计量上限）
+
+这张清单就是契约。每个子代理都拿到同一份，外加一份要套用的服务商名单。
+
+**2. 并行子代理，每个负责一批服务商。** 我把名单拆成几簇，每簇交给一个子代理。
+每个子代理在隔离环境里工作，有自己的上下文、自己的一套抓取，最后为每家服务商
+返回一份结构化的事实清单——不是一段话，而是能直接丢进评分卡的字段。
+
+关键是子代理彼此不知道对方。这正是要点：1 号服务商的任何内容都不必和 14 号服务商
+共享上下文空间，各自返回自洽的结果。
+
+**3. 一次打分，由我来做，不派发。** 子代理产出发现，判断由我来下。一旦你让子代理
+既*收集*事实又*排序*服务商，你就丢了审计链——只会得到一个没有背后证据支撑的结论。
+把打分集中在自己手里，意味着我随时能说出*为什么*某个东西排到某个位置，并指出是哪条
+WHOIS 记录或哪行 AUP 驱动的。
+
+这和我做任何代码审查或重构时用的是一个模式：并行化机械的收集，集中化决策。
+
+### 编排实际长什么样
+
+大致上，每一批：
+
+```text
+子代理 → 「这是清单，这是你那 5 家服务商」
+ → 逐家：抓 WHOIS、AUP、隐私政策、价格、评测
+ → 返回 { 域名年龄, AUP红旗[], 留存条款, 口碑, 流量 }
+我 → 合并进一张评分卡，套用清单，排序，写结论
+```
+
+三个子代理并行跑。整轮——二十家服务商、每家五份文档、大约一百次抓取——在手工
+仔细做两三家服务商的时间里就完成了。
+
+## 核查到底抓到了什么
+
+评分卡暴露了首页永远不会告诉你的真问题：
+
+- **一家声称「自 2012 年起值得信赖」的服务商，域名比这晚得多。** WHOIS 显示域名是
+ 同一年的某个月才注册的——一个「从业多年」的四位数声明，配一个才几个月的域名。
+ 这要么是换了马甲的壳，要么就是撒谎，无论哪种，它页面上所有其他声明在我眼里都要
+ 降级。
+
+- **两家的 AUP 禁掉了我正想跑的那个服务。** 一家在禁止活动条款里列了「TOR 节点」和
+ 「匿名化服务」；另一家禁了「反向代理」和「隧道」。两家的特性页却还宣传着相反的话。
+ 在 AUP 上花十分钟 `Ctrl-F` 就排除了它们——但前提是*我知道该去查 AUP*，而不是
+ 特性页。
+
+- **一家原本看着很便宜的服务商，读了流量条款后不是了。** 一个带 1 TB 计量上限的
+ 计划上写「无限」，只是营销。对于既要接收又要转发的节点，真实成本翻倍——「便宜」
+ 的那个选项并不便宜。
+
+它们所有的共同点是：致命信息从来都没藏起来。它是*公开*的，躺在服务商法律上有义务
+发布的文档里。这个技能不是秘密渠道，而是知道该读哪份文档，并拿它去对照营销话术。
+
+## 我会怎么做不一样
+
+子代理的交接能用，但太粗糙。下次我会提前给每个子代理*精确的返回字段*——一份严格的
+输出 schema——而不是一段我事后还得重新解析的散文。结构化输出意味着最后一个子代理
+返回时评分卡就已经建好了，不用再读一遍。
+
+我也会更早钉死「这个声明能否独立验证？」这个测试。大多数红旗并不是服务商公然撒谎，
+而是一条我无法对照任何公开记录去核实的声明。把「无法验证」本身当成一种信号，名单
+很快就能缩下来。
+
+## 结果
+
+大约 20 家服务商、大约 100 次文档抓取，三个子代理并行，耗时相当于手工仔细做两家
+服务商。最终评分卡里的每一项排名都能追溯到一条具体的公开记录——一个 WHOIS 日期、
+一行 AUP 条款、一条留存条款——而不是一种感觉。
+
+---
+
+## 想为你的企业做这件事吗？
+
+无论是 VPS、API 网关还是薪酬服务商，选供应商都是同一种问题：在签约*之前*，把你真正
+依赖的那些声明对照无法被营销篡改的公开记录核实一遍。如果你手里有一份候选供应商或
+工具的短名单，想在投入之前拿到一份结构化、有证据支撑的评估——我可以跑这轮尽职调查，
+然后交给你一张评分卡，而不是一个猜测。
+
+[WhatsApp 联系我](https://wa.me/60127972969) 或 [发邮件](mailto:me@hoelee.com?subject=Vendor%20due-diligence%20evaluation) 到 hoelee.com——我帮企业选对基础设施，并搭建配套的自动化。
\ No newline at end of file