The Adoption Decision Framework: Build, Adopt, or Pass

The tool passed sec-scan. Exit code 0. No committed secrets, no critical CVEs, no suspicious network calls.

That does not mean you adopt it.

Security clearance is the minimum bar. The harder question is whether this tool earns a permanent place in your architecture — or whether building the capability yourself produces a better long-term outcome.

The Three-Question Capability Gap Test

Every adoption candidate faces three questions. All three must be answered before the decision is made.

Question 1: Can We Build 90% of This in a Week?

Not 100%. Not a perfect replica. 90% of the functionality you actually need.

If the answer is yes, build it. You will own it, understand it, and be able to modify it at will. The remaining 10% either does not matter for your use case or will emerge naturally as you iterate.

If the answer is no — the tool solves a genuinely hard problem that would take weeks or months to replicate — then the tool fills a real capability gap. Proceed to question two.

We built OpenClaw because agent orchestration is our core capability and we could build exactly what we needed. We adopted Pagefind because building a static WASM search engine from scratch would take weeks and search indexing is not our competitive advantage.

Question 2: Is This a Commodity or a Differentiator?

Commodities are solved problems that thousands of teams have implemented. Search indexing. Code linting. Analytics dashboards. Newsletter delivery. These are infrastructure that enables your product but is not your product.

Differentiators are the capabilities that make your system unique. Trading logic. Agent architecture. Memory systems. Competitive intelligence pipelines. These are the things your users or your operations depend on that no generic tool can replicate for your specific context.

Commodities are adoption candidates. Differentiators are build mandates.

Question 3: What Is the Blast Radius if It Fails?

If the tool goes down, gets deprecated, or ships a breaking change — what breaks in your system?

Low blast radius: A blog search index goes offline. Users cannot search articles for a few hours. Annoying but not catastrophic. Pagefind failing does not stop our trading systems, content pipelines, or agent operations.

Medium blast radius: An image generation provider retires a model. Cover images stop generating. Articles ship without visuals. Detectable, fixable, but visible degradation if you are not watching.

High blast radius: A code review tool starts approving bad code. A monitoring dependency goes silent during an incident. A trading data source starts returning stale prices. These failures cascade.

High blast radius + differentiator = build it yourself. High blast radius + commodity = adopt but wrap heavily with fallbacks (Lesson 147).

The Decision Matrix in Practice

Here is how real decisions mapped to the framework:

Built: OpenClaw. Agent orchestration is our differentiator. We could not build 90% in a week (it took months), but the alternative — adopting an external orchestration framework — would have surrendered control over conversation flow, memory architecture, and tool routing. Differentiator + high blast radius = build.

Built: Foresight. Trading logic is never adopted externally. Ever. The blast radius of someone else's trading decisions running on your capital is existential. Differentiator + existential blast radius = absolute build mandate.

Adopted: Pagefind. Static search indexing. We could not build a WASM-based search engine in a week. It is a commodity. The blast radius is low — search goes down, articles are still readable. Commodity + low blast radius + genuine capability gap = adopt.

Adopted: CodeRabbit. AI code review. We could build a basic review bot, but CodeRabbit's depth across multiple languages and its integration with GitHub PR workflows would take weeks to replicate. Commodity + medium blast radius + wrapped in our PR pipeline = adopt.

Adopted: Leonardo AI. Image generation. We cannot build a diffusion model. Commodity + medium blast radius + wrapped in a three-provider fallback chain (Gemini, Leonardo, OpenAI) = adopt with redundancy.

Passed: Various agent frameworks. Multiple open-source agent orchestration tools were evaluated and rejected. They filled a capability gap, but the capability was a differentiator. We built OpenClaw instead.

The Adoption Checklist

Before any tool enters the stack, it must clear every item:

1. sec-scan clean? Exit code 0 or all WARN items reviewed and cleared
2. Can we build 90% in a week? If yes, build instead
3. Commodity or differentiator? If differentiator, build instead
4. Blast radius acceptable? If high, requires wrapper + fallback chain
5. Wrapped? Calling code never touches the external API directly (Lesson 147)
6. Fallback exists? At least one alternative provider identified
7. Documented? Integration pattern, wrapper location, and failure modes recorded
8. 90-day review date set? Calendar entry for re-evaluation

If any item is not cleared, the adoption does not proceed. This is not bureaucracy. It is discipline that prevents the slow accumulation of unvetted dependencies that eventually collapses under its own weight.

The 90-Day Review Cycle

Adoption is not a one-time decision. Every adopted dependency gets a 90-day review.

At each review, re-ask the original questions:

• Is the dependency still actively maintained?
• Has sec-scan output changed? Re-run it.
• Is it still earning its place? Has an alternative emerged that is better?
• Has the blast radius changed? Has your system become more coupled to it?
• Could you rip it out in a day if you had to? (Lesson 149)

Dependencies that no longer earn their place get scheduled for removal. This is not theoretical — it is how you prevent dependency accumulation from eroding your sovereignty over time.

Lesson 146 Drill

Pick five external dependencies in your current stack. For each one, run through the three-question capability gap test:

1. Could you build 90% of what you use in a week?
2. Is it a commodity or a differentiator in your system?
3. What is the blast radius if it fails tomorrow?

Classify each as "correctly adopted," "should have built," or "needs a wrapper/fallback."

For any dependency classified as "should have built" — do not panic. Schedule it for the next 90-day review. At that review, decide whether to start building a replacement or accept the tradeoff with eyes open.

For any dependency classified as "needs a wrapper" — that is Lesson 147. Read it next.

Bottom Line

The adoption decision framework is three questions and a checklist. Can you build it? Is it your advantage? What happens when it breaks? The answers determine whether external code enters your stack or stays outside it.

Most engineers adopt by default and build by exception. That is backwards. The InDecision Framework applies here: every decision to adopt is a decision to surrender sovereignty over that capability. Make that decision consciously, with measured tradeoffs, or do not make it at all.