Developer relations & product at NVIDIA. Writing about things I'm figuring out. No fixed schedule, no polish.
Agents are the most overhyped and underdelivered area in AI right now. Three gaps that frameworks mostly ignore.
Improved memory pooling for multi-model inference and new per-kernel profiling hooks that don't require Nsight.
Every friction point costs you developers — not in a measurable way. Just quietly, one at a time.
Runs a query N times, embeds responses, flags pairs where cosine similarity drops below a threshold.
The problem is almost never about embedding quality — it's semantic units being split mid-thought.
You want infrastructure you understand at 3am when it breaks. A useful check on any architecture decision.
Opinionated takes on AI, developer tools, and building things people actually use.
Agents are the most overhyped and underdelivered area in AI right now. Three gaps that frameworks mostly ignore — and what actually needs to change before agents are useful in production.
Every friction point costs you developers — not in a measurable, dashboard-visible way. Just quietly, one at a time, as they close the tab and go back to whatever they were using before.
Every few weeks, a new agent framework ships. Every few months, someone declares that agents are finally here. And yet most of the agent demos I see are still impressive in a controlled environment and frustrating in production.
I've been thinking about why, and I think it comes down to three gaps that frameworks mostly ignore.
The hardest part of agentic behavior isn't tool use — it's deciding when to break a task into subtasks and how. Current models are inconsistent at this. They'll nail it on easy examples, fail silently on edge cases, and hallucinate a plan that looks reasonable until step three when something breaks.
What's missing is better scaffolding for planning that's legible to the developer — so you can inspect, override, and debug the plan before it executes. Most frameworks treat planning as a black box. That's fine for demos, bad for anything in production.
Everyone has added some form of memory to their agent stack. Vector stores, conversation history, summaries. But memory without schema is just noise retrieval. What I haven't seen yet is a clean, developer-friendly way to define what should be remembered, in what form, and when it expires. That's a product problem, not just a research problem.
Right now, most agent systems either succeed or fail completely. What I want is agents that can say "I got to step four and hit an ambiguity — here are two interpretations, which one did you mean?" without needing to restart the whole task. Partial progress + human-in-the-loop checkpoints is the pattern, but building it well is still harder than it should be.
None of this is unsolvable. But I think the frameworks and the research community are optimizing for benchmark performance rather than production resilience. The next generation of useful agents will be built by people who've been burned by the current generation's failure modes.
There's a metric nobody tracks but everyone pays: the number of developers who bounced off your product at 11pm on a Tuesday because something didn't work and the docs didn't explain why.
I call it the developer experience tax. Every friction point — a confusing error message, an underdocumented parameter, an example that doesn't match the actual API — costs you developers. Not in a measurable, dashboard-visible way. Just quietly, one at a time, as they close the tab and go back to whatever they were using before.
The ones who debug are your best developers. The ones who bail are everyone else.
The most impactful fix is almost never better documentation. It's making the error message tell you what to do next. "Invalid API key" is nearly useless. "Invalid API key — make sure you're using a Project API key, not a User API key. See: [link]" saves five minutes of confused developer and probably the whole relationship.
The second most impactful fix is realistic examples. Not toy examples. Not "hello world" with a fake dataset. Examples that look like what the developer is actually trying to do. If your SDK is for production use, show production patterns.
The third is response time on the hard question — the one where someone has done everything right and it still doesn't work. How fast does your community or support surface an answer? That's the real measure of developer experience.
This is developer relations work, but it's also product work. The boundary is blurry on purpose — both functions are responsible for whether a developer feels capable or confused when using your product.
Things I've built or experimented with — what I tried, what I found, what surprised me.
I kept running into the same problem: asking an LLM the same question twice and getting subtly different answers that were both technically "correct" but contradicted each other. Built a small script that runs a query N times, embeds the responses, and flags pairs where cosine similarity drops below a threshold. Not a solution to inconsistency — just a way to measure it before putting anything in production.
Quick utility to estimate peak GPU memory usage for a given model + batch size + precision combination before actually loading the model. Saves time figuring out whether a workload fits on a single A100 or needs multi-GPU. Archived now because better tools exist — keeping it up since a few people found it useful.
Things worth reading — with a sentence or two on why.
Two things stood out: improved memory pooling for multi-model inference, and new profiling hooks that surface per-kernel timing without Nsight. If you're fighting memory fragmentation across multiple models in the same process, worth understanding before your next architecture decision.
The vision capability is genuinely useful, not just benchmark-impressive. Context length for image + text inputs is finally long enough for real document understanding tasks without chunking gymnastics. Read the token compression section before building anything with it.
Articulates something I've seen in practice but hadn't seen written up well: the chunk boundary problem is almost never about embedding quality — it's about semantic units split mid-thought. Semantic chunking with sentence-similarity overlap is simple and makes a noticeable difference.
Not AI-specific, but one of the better arguments for reliable over impressive — relevant now because AI infrastructure is racing toward complexity. "You want infrastructure you understand at 3am when it breaks" is a useful check on any architecture decision. I've started using it in design reviews.
AI coding tool adoption has plateaued in the last 6 months, but satisfaction among heavy users is up. Tools are getting better — the marginal developer just isn't convinced yet. The gap is about trust and predictability, not capability.
I work on Physical AI and Agentic Intelligence at NVIDIA — product and developer relations for the messy, interesting problem of getting AI to take dependable action in the real world. That means simulation, multi-agent systems, and platforms like Omniverse. It's where most of my curiosity lives right now: the point where a model stops just generating text and starts moving things.
I didn't start here. I started on plant floors — commissioning automation systems, then building the MES and industrial IoT software that ran them, most of it over a long stretch at Rockwell Automation. From there the work climbed the stack: analytics, digital twins, and then generative and agentic AI at AWS. Twenty years of watching the same industrial problems get attacked with progressively better tools. That arc is why I care less about what a model can demo and more about whether it holds up on a factory floor at 2am.
So I tend to sit at the intersection of what's technically possible and how developers actually experience it — I see the gap between what's announced and what ships, between what's impressive in a keynote and what survives contact with real systems.
This site is where I think in public. Not a portfolio. Not a newsletter. Just a place where I write down things I'm figuring out — about AI, about developer tools, about building products that practitioners actually want to use — and share what I find worth reading.
If something here is useful to you, that's the whole point.
Currently NVIDIA. Previously AWS and Rockwell Automation. Based in San Jose, California.