Daybook, 11 July 2026

Six hours today on one session — walking the whole stack of an AI-native enterprise system. The kind built for enterprise-scale human–AI collaboration, where people can stand up their own agents and build their own data products, instead of queuing behind a team.

It was deliberately open-ended, more than a demo — data foundations, agentic foundations, the application layer, and the P&L: how the pieces actually fit, and what each one is for. More of an architecture argument than a walkthrough.

Open the deck ↗

How this actually gets made. The whole pipeline now runs through Claude Code as the hub — Excalidraw (via MCP) for the diagrams and Marp for the deck, so the thinking, the drawing, and the slides all live in one place instead of three. Around it, Granola and TwinMind capture the raw thoughts and references, which I then fuse together and argue against — more of a Socratic dialogue than note-taking. The point isn't speed. It's to catch the blind spots I'd otherwise walk straight past.

Tabular foundation models — a detour that clarified something. I wanted to go deeper here, and I hit a useful snag: Google's recent tabular-FM release isn't backed by a paper. So the better entry point is Prior-Data Fitted Networks (TabPFN) — and the architectures turn out to differ in kind, not degree. PFN leans hard on amortized Bayesian inference, rather than the usual supervised-training story. That's the thread worth pulling. Today went entirely to engineering architecture, so this moves to Sunday.

Where AI-native actually pays. This is the reflection that nagged me all day. For engineering-heavy enterprises — shipping, logistics, anyone serving millions of customers — there's surprisingly little utility in building “AI-native apps.” Customer care is one genuine use case, and then it thins out fast. But the scope for decision-centric work is enormous, and largely untouched. That gap is exactly why I'm writing a white paper on decision engineering.

An honest caveat I want on the record: “decision engineering” isn't a term the founders of decision analysis endorse. So I'm holding it as working context, not a claim, and I'll see whether it earns its keep. What I mean by it: sitting on top of AI engineering, seeing the whole picture, and building whatever's needed so that people and enterprises can actually decide and plan better — FP&A, supply-chain and demand planning, customer 360. That's the one thread I intend to keep maintaining, no matter what else moves.

Hunting for the right research problem. I want problems that emerge from the work, rather than from a call for papers. One small experiment I'm starting — deliberately quick, not a whole research program:

Traces. What if you had parallel data on how a human solves a problem and how an AI solves the same one — the traces of the conversations themselves? At Informatica I was pulling out how engineers actually solve problems from their conversations, and asking how to turn that into runbooks and skills for agents.

The obvious move — dump every trace into a big LLM and ask for insights — is, I think, a dumb idea. There are too many conversations, each with too many turns; the structure is the whole point, and that approach just throws it away. The alternative I like: a small model trained only for trace analysis. Far more economical, and once it generalizes, it could serve a lot of use cases.

Sunday, two things: (1) deep-dive tabular foundation models, starting from TabPFN and amortized inference; (2) experiments on agent reasoning and long-horizon tasks. And the thread quietly tying them together — as a data scientist, how do I actually look at traces?

Settled · 11 Jul 2026