Daybook, 17 July 2026

Found the blind spot. While evaluating the agents, I figured out one of the places it was failing and actually causing issues in the warehouse (Superset). The thing is, instead of using the physical tables, it was reusing the existing logical / semantic models — which was making an impact on other people's dashboards and pipelines. So I put some guardrails and policies in place — a kind of controlled use, basically data-access control, so an agent can't blast through someone else's work.

Ontology as the substrate for planning agents. As I was prototyping agents for operations planning, I was reading on o9 Solutions and neuro-symbolic AI — and other companies are pitching the same idea. Underneath it, it's really about having an ontology and knowledge graph in place, so the agents get the correct context — and not just context, but the interconnectedness. Take planning operations for a site: it's got this recursive, ontological structure — time, material, a taxonomy, and each part has its own policy and who-should-work-on-what. If it's just a flat relational table, getting things out and feeding it to the agent is an issue. But if you frame an ontology on top of the existing data, it becomes much easier for the agent to retrieve exactly what it needs, on demand, for planning or execution.

The idea that formed — antifragility, by design, for the whole system. This got me into Taleb's Antifragile — how you gain from disorder, where an impact should actually leave the system better, not just intact. It sounds adjacent to what self-improvement should be. But here's the trap: for an agentic system, the “disorder” is basically just an error — it'll correct it and adapt over time. So we have to think about antifragility from a different level. Agents don't sit alone — they sit inside an existing ecosystem, with engineering elements and planning elements around them. And if the agent causes an issue, or a deteriorating decision, that can trigger some really bad second-order effects downstream. So antifragility isn't about the agentic system alone — it's about the holistic system, where the agents and all the other elements interact — and it has to be there by design. As I was thinking on these terms, three things kept interacting: antifragility (Taleb, black swans, shocks); neuro-symbolic systems; and my own thing from control systems — that any controller you design should have the ability to adjust, withstand, or fall back when an unprecedented disturbance comes from the environment, so the overall system stays safe. And then, almost on cue, I landed on a paper — “AI Safety Must Embrace an Antifragile Perspective” (ICML 2025) — which argues exactly that: safety should expand its safe operating regime by metabolizing rare and adversarial events, not just bounce back. An interesting read, and a thread I want to take further.

A note on how that paper turned up — because it's becoming my method. I didn't start from the paper. Before this, I was brainstorming antifragility myself — I never even knew there was a position paper on it. The thought didn't get kindled from the paper; it started on its own, and then, as I discussed it further, I ended up landing on it. And I've come to trust that order. If you always keep formulating the problem — or even the solution — in an open-ended, first-principles way, you eventually end up finding the supporting material. Number one, you're not biased early. Number two, as it goes on, you can validate it too. Start from the paper and you inherit its frame; start from your own formulation and the literature becomes validation, not a leash — and sometimes you end up somewhere genuinely new, because you weren't just following. It's the same reason tutorials and playbooks feel flat to me these days — even if it takes more time, I'd rather have a Socratic back-and-forth, keep throwing the assumptions, think interdisciplinary, and only then check whether that perspective already exists. Branch, then merge.

The honest bit — I'm still not running the experiments. The foundation-model work on time-series / relational / tabular data keeps slipping. And it's not that I'm not getting the time — it's that I'm not allocating it. Which pushed me into a harder question.

What real agency actually means. In a company where the leadership (reasonably) cares about how soon you bring something to production, the path of least resistance is “just build the one agent I've been asked for at this stage” — and that never really gives you space for agency. Agency should start from questions instead: how can I do this differently, how can I build leverage for myself — while still delivering. That trade-off, between delivering and experimenting, is exactly what gives you the room to frame a problem differently, try a different evaluation strategy or harness trick, and surface a research question worth pursuing. But wanting isn't agency — you have to make a way to it. A real question, or a small proof of concept that gains some traction, so “oh, this seems interesting” turns into “I'm actually doing it, and here's the evidence.” Foundation models on enterprise data are the easy version, because I'm already inside an enterprise. But the real agency would be whether I can parallelly take up something like AI for science, or AI safety for scientific systems — the kind that needs nights and weekends, and where the cold-start problem hits, or where a good collaboration would help. I don't think I can just stick to one thing. As long as I can make a way, I'll keep going — and I'll always try to come up with evidence, not just speculation. I'm getting better at that balance. I'll brew it soon.

Settled · 17 Jul 2026