AI Frameworks Without Lock-In
AI Frameworks Without Lock-In
Key jargon
| Term | Plain-language meaning |
|---|---|
| Framework | Reusable abstractions and components for building an application. S1 |
| Vendor lock-in | The cost or difficulty of changing a provider or technology. S1 |
| Port | An application-owned interface describing what a component must do. S1 |
| Adapter | Provider-specific code implementing a port. S1 |
Key concepts
- Keep domain logic and evaluation datasets outside framework-specific objects. S1
- Framework replacement becomes manageable when provider code is confined to adapters and behavior is protected by contract tests. S1
Concept map
flowchart LR
A["Define application-owned ports"] --> B["Implement framework adapters"]
B --> C["Run shared contract tests"]
C --> D["Replace without changing domain logic"]Diagram semantics verified against S1 and S2 on 2026-09-02.
Frameworks can provide model adapters, prompt templates, retrieval, tool wiring, graphs, checkpoints, tracing, and integrations. They also add abstraction, rapid version churn, hidden defaults, and provider-specific leakage. S1
Stable seams
- Application task schema. S1
- Model adapter interface. S1
- Tool schemas and authorization gateway. S1
- Retrieval interface and document identifiers. S1
- Run-state/checkpoint schema. S1
- Trace and evaluation record. S1
Keep these under your control. Wrap framework objects at boundaries and test the wrapper. S1
Selection questions
Can the team debug a raw request? Export state? Pin versions? Replace the model or vector store? Test each node? Understand retries? Enforce authorization outside the model?
Exercise
Implement one conceptual two-step workflow in plain pseudocode and then map it to a framework. Identify which framework features save work and which create coupling.
Staleness warning
Framework APIs change quickly. Use current official documentation and locked dependencies; do not teach old sample code as architecture truth. S1