Selection is a document
Tool choices are written decisions, scored against API stability, lock-in cost, what breaks if the tool dies, and how debuggable it is when it does.
← The K-Framework
★ Amplification · 10× ThroughputLayer 7 of 16Visual guide
PILLAR B · LAYER 01 · B.01Model & Tooling.
Choose & build the right tools.
What a CEO/CTO needs to know
Ask why each tool was chosen. If the honest answer is 'it was trending,' you have bought a migration project that has not arrived yet.
Framework lock-in inherits someone else's release schedule. Direct-to-model keeps the control flow yours.
[WHAT IT IS]
The engineer’s view, in plain language.
We do not follow framework hype. The right tool for the job is the simplest one that survives the audit. More often than not that means going directly against the model API, with no orchestration vendor and no lock-in to someone else's release schedule.
[HOW WE BUILD IT]
What “done right” looks like.
Default to direct
Most of the time the answer is the model API plus Postgres plus your existing infra, not a framework that owns your control flow.
An exit before an entry
Before adopting a tool we can describe how we would remove it. If we cannot, we do not adopt it.
[MATURITY LADDER]
Where does your build sit?
Four rungs from absent to production-grade. Level 3 is the target, and the only one that survives a real production incident.
L0
Absent
Tools are adopted on hype with no exit plan.
L1
Ad-hoc
Choices are reasonable but undocumented, and lock-in is unmeasured.
L2
Managed
Tool decisions are written but the exit cost is not tested.
L3Target
Production-grade
Every tool is a scored decision document with a known removal path; direct-to-model by default.
[VALIDATE IT YOURSELF]
How to check it’s really there.
You do not need to read the code. Ask these questions and demand these artifacts. Vague answers are the finding.
★ Ask your team
- ?Why this framework or vendor, and what breaks if it disappears?
- ?How would we remove this tool if we needed to?
- ?What does this tool give us that the model API plus our own infra does not?
★ Demand to see
- A tool-selection decision doc scoring stability, lock-in, and debuggability
- A described exit path for each load-bearing dependency
- A bias toward direct-to-model integration
● WHAT L0 LOOKS LIKE
The failure mode, in production.
Adopting an agent framework because it is trending. Six months later the framework rewrites its memory layer in a breaking change, and half the engineering capacity becomes a migration project.
Want this layer audited in your stack?
We run the K-Framework against your AI build and hand you the gap list, ranked by what it will cost you in production.