The problem

Every team building with LLMs converges on the same easy 80%: call the model, get code or a decision back, ship it. What breaks systems in production is the other 20% — knowing what a given user’s software is actually running and why, proving a change was correct when there isn’t one canonical version anymore, measuring whether an AI-driven change actually helped the metrics that matter, and coordinating intent across a fleet of systems that no longer share a single commit. Enterprises hit this exact wall the moment they move past a chatbot bolted onto existing software into agents that read, write, or personalize against live systems of record — and most generative AI pilots die there, not at the generation step.

The approach

This isn’t a shipped app — it’s a maintained body of engineering knowledge I keep building by deliberately ingesting and dissecting talks and writeups from people actually running AI-native systems in production (AI Engineer conference sessions, practitioner writeups on enterprise ontologies), then extracting each one down to a single falsifiable claim tied back to its exact source timestamp or article. Right now it holds fifteen of these distilled ideas, each with its own provenance link back to the talk or article it came from, so nothing is a paraphrase floating free of its source.

The ideas cluster into a few concrete, reusable positions: the right architecture for per-user adaptive software is “one stem plus bounded, isolated divergences” rather than millions of forked codebases — a bad variant can’t corrupt the stem or bleed into another user’s session, and the developer still declares what’s off-limits (auth, payments, whatever). Agent frameworks (LangChain, Google ADK, Strands, Agno, and the rest) are structurally identical under the hood — connect to tools, instantiate an agent, run a loop — so picking one is a developer-experience decision, not a performance one, and you can prove it by inspecting the dependency graph a framework builds instead of trusting its docs. Production AI-native systems should mature in reverse of legacy code: start everything in the LLM’s context to learn what’s worth building, then migrate anything with exploitable structure — hierarchies, schemas, exact counts — back into deterministic code, because token-by-token scanning degrades badly at scale. And enterprise AI has to survive “the memo, not the demo” — a room of skeptical reviewers with real money on the line, not a five-minute fluent walkthrough.

The point of keeping this as a working project rather than a one-off reading list is that each new idea gets checked against the others — reference architecture claims, framework claims, and reliability claims all sit in the same place so contradictions or reinforcements surface over time.

What I learned

The throughline that keeps recurring across independent sources is that the hard engineering surface in adaptive software has four concrete parts, not one vague “reliability” problem: lineage/provenance (a bug report now describes a program instance that exists for exactly one user — that’s a graph query, not a version number), correctness at scale (testing has to reason about a stem and every one of its potentially millions of divergences at once), desirability measurement (a correct change isn’t automatically a good one — you have to track whether it moved the metric that actually mattered for that product), and coordination without a shared commit (propagate intent, “merge outcome, not code,” rather than assume everyone converges on one canonical changeset). Naming these four separately, instead of lumping them under “make the agent more reliable,” is what makes the problem tractable — each one has a different fix, and conflating them is why most teams’ first attempt at agentic reliability doesn’t hold up under real load.

Where this could go

The stem-plus-bounded-divergences model and the four-part observability surface aren’t personal-project abstractions — they’re the exact shape of the problem any org faces once it lets AI agents personalize or modify software that’s actually live: a sales CRM that adapts per rep, a support system that routes gray-zone tickets to an agent tier sitting above existing rule engines and ML scores, a fraud system where most traffic stays on the deterministic path and only the ambiguous residual goes to the expensive agentic layer. The forward-deployed-engineering pattern in the notes — layer agents on top of a client’s existing system of record instead of requiring migration off it — is the same lesson at the sales-motion level: nobody’s ripping out a $5M NetSuite deployment for your agent pitch, so the architecture has to assume coexistence, not replacement. Where I’d take this next is turning the fifteen-idea backlog into an actual internal standard — a checklist a team can run a new agentic feature against before it ships (does it have provenance, does it have a desirability metric, does it have a gray-zone escalation path) rather than leaving it as reading notes.