Vendor lock-in 4 layer di era agentic AI — exit strategy yang masuk akal

Era agentic AI 2024-2026 punya pattern lock-in yang lebih dalam daripada SaaS lock-in tradisional. Dulu, vendor lock-in = data terkunci di proprietary format + kontrak panjang. Sekarang, lock-in compound di empat lapis simultaneously.

Setiap engagement klien yang masuk Tier 1A (burned in-house AI builders) yang kami audit, kami petakan posisinya di 4 lapis ini. Yang gagal recovery dari "75% bucket" Forrester biasanya stuck di multiple layer secara compound.

4 lapis lock-in di stack agentic AI

Lapis 1 — Foundation model

Pilihan LLM provider (Anthropic, OpenAI, Google, Meta, lokal) yang Anda pakai. Lock-in muncul saat:

• Prompt engineering Anda tuning ke karakter model spesifik (Claude vs GPT vs Gemini punya respons pattern berbeda untuk prompt sama)
• Context window dependency — pattern Anda assume 200k+ token context, vendor lain max 32k
• Tool calling format proprietary — Anthropic tool use ≠ OpenAI function calling ≠ Gemini function declaration
• Multi-modal capability — vision / audio / document processing yang Anda pakai mungkin tidak port ke vendor lain dengan parity

Exit hatch:

• Pakai Model Context Protocol (MCP) — standard interop yang abstraksi tool calling format
• Pakai LiteLLM proxy atau OpenRouter — abstraksi provider, prompt format auto-translated
• Avoid prompt yang assume specific model behavior — keep prompt portable + test di multiple model

Lapis 2 — Orchestration framework

Framework untuk compose multi-step workflow + agent reasoning loop. Pilihan: LangChain, LlamaIndex, Anthropic SDK direct, custom Python, n8n, Temporal, Inngest, dst.

Lock-in muncul saat:

• Workflow definition di-encode dalam framework-specific syntax (LangChain LCEL, LangGraph node graph)
• Agent state persistence pakai framework's storage abstraction
• Tool calling pattern di-couple dengan framework lifecycle hook
• Memory + context management lapped dalam framework's session pattern

Exit hatch:

• Pakai n8n atau Temporal atau Inngest — durable workflow engine yang export-able JSON config
• Avoid framework yang lock-in di runtime memory (LangGraph in-memory state) — pakai eksternal state (Postgres, Redis)
• Keep agent reasoning loop simple + Python-native, bukan framework-special-syntax
• Multi-step orchestration pakai standard pattern (queue + worker + state machine), bukan framework's proprietary primitive

Lapis 3 — Runtime environment

Cloud infra yang host LLM + workflow + state. Pilihan: AWS Bedrock, Azure OpenAI, GCP Vertex, Modal, Railway, fly.io, self-host.

Lock-in muncul saat:

• IAM + role configuration coupled ke cloud-specific (AWS IAM ≠ GCP IAM ≠ Azure RBAC)
• Storage primitives coupled (S3 vs GCS vs Blob — meskipun S3-compatible interface helps)
• Networking + secrets management vendor-specific (Secrets Manager, Parameter Store, KMS)
• Pricing model coupled — AWS Bedrock per-token billing != Azure OpenAI deployment-based

Exit hatch:

• Pakai Docker Compose + standard Linux primitives — port-able antara cloud
• Postgres + S3-compatible storage — abstraksi yang multi-vendor (DigitalOcean Spaces, Cloudflare R2, AWS S3, Backblaze B2)
• Bitwarden atau HashiCorp Vault untuk secrets — bukan vendor-specific secret manager
• Pricing: pakai LiteLLM proxy untuk multi-provider routing — switch saat cost shift

Lapis 4 — Developer pattern + institutional knowledge

Layer paling sticky + paling sering di-overlook. Lock-in muncul saat:

• Tim Anda hanya familiar dengan satu provider (developer hire dengan "OpenAI experience" bertahun-tahun)
• Documentation + runbook reference pattern provider-specific
• Internal training material + onboarding flow assume stack tertentu
• Vendor-specific SDK + library dependencies di codebase Anda

Cost compound paling besar di sini. Switch foundation model gampang (config change). Switch developer mindset + institutional knowledge butuh 3-12 bulan.

Exit hatch:

• Hire developer dengan experience multi-provider, bukan single-vendor advocate
• Documentation pattern pakai abstraksi (e.g. "LLM tier 1" instead of "Claude Sonnet")
• Internal training cover MCP + provider-agnostic patterns
• Library + SDK pilih yang vendor-agnostic (LiteLLM, MCP client, Pydantic untuk schema)

Pattern recommendation per scope

Scope kecil (< 10 manday LLM workflow)

Pakai 1 provider direct (Anthropic Claude paling stable + best dev experience 2026). LiteLLM proxy optional — break-even point biasanya saat scope tumbuh.

Lock-in risk: rendah. Cost switch < 5 manday kalau perlu pivot.

Scope medium (10-50 manday)

LiteLLM proxy mandatory. Multi-model fallback config. Workflow di n8n atau Temporal. State di Postgres.

Lock-in risk: medium tapi exit-able. Cost switch 5-15 manday.

Scope besar (50+ manday)

Full 4-layer abstraction. MCP-native. LiteLLM + multi-provider config. n8n self-host atau Temporal. Postgres + Redis. Bitwarden secrets. Self-host atau BYOC.

Lock-in risk: dikontrol per layer. Cost switch per layer 5-20 manday.

Stack yang kami operasikan internal

Sebagai reference baseline (per Pillar 2 transparency footnote, bukan brand authority claim):

• Layer 1: Anthropic Claude (Sonnet, Haiku, Opus) via LiteLLM
• Layer 2: n8n self-host untuk durable workflow + Python supervisor service untuk agent orchestration
• Layer 3: DigitalOcean Singapore (sgp1) — single provider, exit feasible via Docker Compose port
• Layer 4: Internal documentation pakai abstraksi LLM-tier (1/2/3) bukan model name; tim familiar MCP

Setiap layer punya exit option documented + tested minimum 2x per tahun (kami switch antar fallback model setiap kuartal sebagai exit drill).

Honest trade-off

Multi-layer abstraksi ada cost-nya:

• Performance overhead — LiteLLM proxy add ~50-200ms latency per call (negligible untuk B2B workflow, signifikan untuk consumer real-time chat)
• Maintenance overhead — multiple library dependency yang harus di-track + updated
• Mental model overhead — developer butuh familiar dengan abstraksi layer instead of direct vendor SDK

Untuk klien dengan scope kecil + speed-to-market priority, pakai 1 provider direct OK. Optimization untuk multi-vendor switch hanya make sense di scope medium-besar atau klien yang explicit prioritize sovereign exit option.

Kapan pattern ini fit untuk Anda

• Tier 1A (burned in-house AI builders) — recovery dari engagement past yang stuck di vendor lock-in
• Klien regulated vertical yang punya audit posture mandate vendor diversification
• Klien yang invest jangka panjang (3-5 tahun) di AI capability + ingin kontrol cost trajectory
• Tim teknis yang sudah experienced + bisa absorb maintenance overhead

Kapan TIDAK fit

• Scope kecil + MVP focus — over-engineering, abstraksi belum worth-it
• Tim teknis terbatas + tidak punya bandwidth maintain multi-layer
• Klien yang prioritize speed-to-market di atas long-term flexibility

Kami sampaikan honest di konsultasi awal — pattern multi-layer abstraksi ini bukan untuk semua klien.

---

Tag internal: Pillar 4 · Sovereign · Deep dive · S1 Cross-reference: /services/ai-operating-system · /pattern · Decisions/ADR-002-openrouter-litellm-migration · Decisions/ADR-012-claude-local-mcp-architecture