Sriram Sundar Blogs

The AlphaFold Problem

Thu, 09 Jul 2026 00:00:00 GMT

I think enterprise AI has an AlphaFold problem.

Not because the technology is weak. Because we keep treating the solved part like it's the hard part.

I've been circling this in two places for a while: medicine and the enterprise. AI is very good at speeding up work inside a clean, bounded problem. It is much worse at making the messy downstream work disappear.

AlphaFold solved protein folding: sequence in, shape out. A fifty-year problem, gone and deservedly Nobel-Prized. But the shape was never the point. Curing disease was the point. That next gap is stubborn. A molecule still has to work in a human body. Biology is slow. Trials are slow. Compute doesn't erase that.

Enterprise AI is the same shape. LLMs are excellent at a bounded version of the problem: clean context in, useful output out. But useful output is not the same as changing how a company runs.

The harder question is whether that output survives contact with the real enterprise estate - undocumented dependencies, brittle workflows, old architecture, incentives that were never designed for this pace.

Software engineering makes this visible. In greenfield codebases, AI coding tools move very fast. In mature enterprise codebases, the story is messier. METR has pointed to flat-to-negative gains for experienced engineers in legacy settings. Same model. Different patient.

A clean codebase is a clean patient population. A legacy estate is the complicated one. Same drug, different result. This is also why AI-native companies can look a generation ahead, not because they have better models, but because they carry less baggage. DORA has made the same point: AI doesn't fix an organization, it amplifies what's already there.

So here's my real claim. Enterprise AI adoption isn't slow because the technology is weak. It's slow because we keep solving the manageable half, model capability, the fold and acting like the whole problem is solved. The rest is slower and less glamorous: clean data, documented architecture, decoupled systems, trust, redesigned workflows.

That's how I read the recent moves from Anthropic, OpenAI, Microsoft, and others around forward-deployed engineering teams. The hard part is no longer just building the model. The hard part is getting the model to work inside the patient (enterprise).

DeepMind spun out Isomorphic Labs to own the part AlphaFold couldn't reach; turning a solved structure into an actual treatment. Anthropic, OpenAI, and Microsoft are now building FDE ventures to get closer to enterprise estates. GSIs have quietly been operating inside those estates for two decades, without the lock-in or constraints that come with being a frontier model or hyperscaler.

Which is why I think the market has this backwards. Services firms are being priced like the fold was what mattered. It isn't. The clinical trial, "estate readiness" is where the value sits. It gets bought, one embedded engagement at a time. Now you decide!

Your AI Privacy Strategy Is Probably Solving the Wrong Problem

Thu, 30 Apr 2026 00:00:00 GMT

A few weeks ago, I was excited when Claude Cowork came out. Finally, I could sort my iCloud Drive and MacBook. Ten years of personal documents, no taxonomy, sitting in a single folder structure I had given up on.

Then I read the fine print. Cowork made clear that giving it access to sensitive files meant those files would be processed in the cloud. The mainstream alternatives all did the same. For my own data, that was a no. Think Tax returns, Scanned IDs, Healthcare records and Family financial history.

So I built it locally. A small model, a vector index, a search interface. None of it on the cloud. Everything ran on the laptop. Ollama running Qwen 2.5 7B and Qwen 2.5 VL, with nomic-embed-text feeding ChromaDB, served through a FastAPIlocalhost UI. Entirely on a 32 GB M-series MacBook, zero cloud calls.

That night I realized something. The wrong problem is “where does our data live.” The right problem is “what gets to read it.” And almost every enterprise AI privacy strategy I see is solving the first one.

I was actually stumbling into the question every enterprise leader I talk to is going to face within the next two years.

The privacy frame is wrong

When most leaders think about AI privacy, they think about storage. Where does the data live. Who can see it at rest. What the contract says about retention.

That is not the right frame anymore.

Storage in an encrypted cloud you trust is one decision. Processing by a service you do not control is a different one. The moment you point a frontier AI service at sensitive data, the encryption stops at the API boundary. Whatever reads the file to classify, summarize, or search has the file. This distinction is going to redraw the AI buying pattern of the next five years.

What is actually shifting

The dominant assumption in 2026 is that serious AI work happens in the cloud. The frontier models, the infrastructure, and the economics are all there.

That assumption is correct for most workloads. It is wrong for the workloads that matter most to most enterprises. What I call Enterprise Context: regulated data, contractual IP, customer information, strategic decisions.

Something has changed in the last eighteen months that most enterprise leaders have not absorbed yet. Open-weight models in the 7B to 70B range are now genuinely capable for classification, retrieval, and generation against proprietary data. Apple Silicon and equivalent enterprise hardware can run those models at production speeds. And the orchestration tooling around vector databases, embedding pipelines, and retrieval frameworks has matured enough that a competent integration team can stand up a private inference stack in weeks rather than quarters.

The implication is more subtle than “data leaves the cloud.” The default shifts. For workloads that are regulated, contractual, or strategic, local or in-tenant inference becomes the obvious answer. Hyperscalers will sell into both worlds. The enterprises that win will be the ones who learn which workload belongs where.

What enterprises should be building

The right question is not whether to use AI. It is which workloads belong close to the data, and what the architecture looks like when local inference is the default rather than the exception.

The answer is what I call the Enterprise Orchestration layer. A modular layer that sits inside the enterprise tenant and routes workloads intelligently. Frontier cloud for general reasoning. On-tenant for sensitive processing. Edge for latency-critical decisions. What you are building is not a model. You are building the system that decides which model handles what.

Three properties make this layer work. The data does not cross an API boundary you do not control. The underlying models can be swapped as the open-weight frontier moves, without re-platforming. Every inference is logged against the data it touched and the model that ran.

Sovereignty, interchangeability, auditability. Build for those and you own your AI trajectory. Skip them and you keep paying for the same data to be re-uploaded, re-processed, and re-licensed by someone else.

How I advise clients to think about this

Three questions, in order.

One. Which of your workloads are touching data you cannot afford to release? Not data you would prefer not to release. Data where the cost of a leak, a subpoena, or an unintended training signal is unacceptable.

Two. For those workloads, what is the gap between what your current AI vendors offer and what an in-tenant alternative would deliver? In my experience, the gap is smaller than the vendors suggest.

Three. What would it cost to close that gap? Not in licensing. In the operating muscle to run inference, manage models, and govern outputs inside your own walls.

That third question is where most enterprises get stuck. The hardware and models exist. The gap is organizational.

The bet

The enterprises that win the next five years will not be the ones with the biggest cloud AI bills and token costs. They will be the ones who figured out early which workloads belong close to the data, and built the muscle to run them there.

A claims-adjudication model. A contract-review pipeline. A trading-desk research assistant. A reservoir-engineering copilot trained on proprietary subsurface data. These belong inside the enterprise, not on someone else’s infrastructure & model.

This is the conversation I am having with clients across industries. The interesting work in 2026 is not picking a model. It is designing the architecture that decides which model runs where, on whose hardware, against whose data, under whose control.

That architecture may be the enterprise AI strategy of the next five years. The companies that own it will compound their advantage.

AI, Agents, and the Enterprise Stack: Facts, Fears, and Operating Reality

Wed, 11 Feb 2026 00:00:00 GMT

A growing argument in the AI debate suggests that most business applications are essentially CRUD databases wrapped in business logic. If intelligent agents can assume that logic layer, why retain traditional SaaS and ERP platforms? Why not reduce them to data stores and allow AI to orchestrate the enterprise? It is a provocative thesis — and one that deserves a balanced response.

Fears

The anxiety is understandable. If agents can reason, trigger transactions, reconcile data, and manage workflows across systems, it raises legitimate questions about the durability of traditional enterprise software. In my conversations with CXOs across industries, this concern surfaces repeatedly — not as theory, but as practical unease about accountability, compliance, and risk.

There is also transformation fatigue. Over the past decade, enterprises have invested heavily in cloud, ERP modernization, automation, and data platforms. The promise was agility and simplification. The reality has often been architectural complexity and uneven value realization. Leaders are understandably cautious about embracing another sweeping narrative.

At its core, the concern is whether AI is simply the next expensive overlay — or something structurally different.

Facts

Enterprise systems are not merely CRUD layers. Platforms such as SAP, Oracle, Workday, ServiceNow, Salesforce, Microsoft Dynamics, and Ariba encode decades of regulatory compliance, accounting standards, segregation-of-duty controls, audit trails, tax engines, and tightly coupled transactional dependencies. These systems enforce financial integrity, risk controls, and operational guardrails at global scale.

They are deterministic by design. Agents are probabilistic by design. An agent can recommend, synthesize, and orchestrate. A system of record must guarantee accuracy, auditability, and legal defensibility. Public enterprises cannot operate on “almost correct.” They require replayable, compliant execution.

Business logic will increasingly move upward into orchestration layers, and the user interface of the enterprise will evolve. But replacing the regulatory and financial backbone of global organizations is not merely a technology decision. It is a governance and liability decision. AI can and will sit above systems of record; it is unlikely to eliminate the need for them - at least not in the short to medium term.

Operating Reality

What makes AI potentially different from prior digital waves is its proximity to judgment and decision-making. Earlier automation digitized workflows. AI can augment planning, forecasting, analysis, and coordination. That is where structural productivity gains may emerge — if implemented with discipline.

The more relevant question is not whether agents will replace SaaS, but how workflows can be redesigned around intelligent orchestration while preserving deterministic cores. Organizations must separate experimentation from industrialization, scaling only what delivers measurable value. Cross-functional teams that combine domain expertise, architecture, risk, and AI engineering are essential. Incentives must align to business outcomes — productivity, cycle time, revenue impact — not tool adoption.

From where I sit, this shift is already redefining our role. In discussions with enterprise leaders, the demand is not to dismantle core systems, but to orchestrate across them intelligently. We are designing governed agent frameworks that operate above systems of record while preserving compliance, observability, and transactional integrity. The objective is not to replace SAP or other SaaS systems, but to weave AI across them to unlock measurable operating value. We are evolving into the AI autonomy orchestrator — intelligently layering governed agent frameworks above enterprise systems to unlock value without compromising control.

This transformation will not occur in a single budgetary cycle or year. Over the next three to five years, we will likely see structured layering of agents above core platforms, targeted workflow redesign, and progressive industrialization of AI use cases. Core systems of record will remain in place while orchestration layers mature on top of them. The enterprises that move deliberately — balancing experimentation with control — will be the ones that convert AI from narrative into durable advantage. This can be a steady and realistic blueprint for Enterprise AI at Scale.

Terminal Agents vs IDE Agents: What’s Driving Adoption

Fri, 16 Jan 2026 00:00:00 GMT

A shift I didn’t expect
Over the last few months, I’ve noticed an interesting pattern. Even as IDE-first AI tools are getting remarkably good — especially tools like Cursor and GitHub Copilot — the developer community seems increasingly excited about terminal-based coding agents like Claude Code, Codex CLI, and (increasingly) Gemini CLI.

Is it just developer culture?

At first glance, it’s easy to assume this is just classic developer culture. The terminal has always been associated with “real engineering,” and there’s a certain credibility attached to being fluent in the CLI. So yes, if we’re being honest, there’s a small amount of identity-signaling in the mix.

The real reason: software is shipped in the execution loop

But after experimenting with these tools myself, I’m convinced that explanation is incomplete. The real reason terminal agents are catching fire is simpler: they match how software actually gets shipped.

In an enterprise environment, the IDE is not the system of record. The repo is. The CI pipeline is. The build logs are. The test outputs are. The security scans and policy gates are. In other words, what matters isn’t that the code “looks right” in an editor — it’s whether the change survives the execution loop: build, test, validate, and deploy. That loop lives in the terminal.

Why terminal agents feel like “real work getting done”

A terminal agent isn’t just generating code. It can search the repo, make changes across modules, run tests, observe failures, fix them, and rerun until everything is clean. That’s what makes tools like Claude Code and Codex CLI feel less like “autocomplete” and more like a junior engineer who can execute.

My personal takeaway: IDE-first wins for experimentation

That said, I’ve noticed something in my own workflow. I’m not using these tools to ship large-scale enterprise software every day. I’m experimenting, learning, and building practical apps faster than I ever could before. And in that mode, IDE-first AI tools shine. Using an IDE-first tool like Cursor, I’ve built a NetWorthTracker, a ShoeMileageTracker, a CashFlowTracker, a Runway Simulator, and a Retirement Planner — all in the last month. The plain-English narrative inside an IDE — “add a new screen,” “connect this API,” “build me a simulator with sliders” — is intuitive, fast, and genuinely enjoyable.

The enterprise lens: traceability beats convenience

But when the goal shifts from experimentation to production-grade delivery, the terminal agent model starts to make a lot of sense. And the enterprise angle makes it even clearer: trust requires traceability. What changed? What commands were run? What tests passed? Can we reproduce it? Can we audit it?

Terminal workflows are explicit and replayable. IDE workflows can be incredibly productive — and tools like GitHub Copilot have become a default in many development environments — but they often feel harder to standardize and govern at scale.

Conclusion: it’s not IDE vs terminal — it’s both

My conclusion isn’t IDE versus terminal. It’s both: IDE AI for creative shaping of code, and terminal AI for validation, reproducibility, and shipping.

The Stack Just Moved

Wed, 17 Dec 2025 00:00:00 GMT

For years, we’ve talked about “moving up the stack." Last weekend, I experienced what that actually means.

After a long break from hands-on development, I built a complete, production-quality application in a matter of hours with the help of modern AI coding agents. My total investment was refreshingly modest: a $60 Cursor Pro license and a free Alpha Vantage API key to pull real-time market prices.

What changed wasn’t my ability to code. It was the economics of software creation.

The last time I wrote serious production code was in the late 2000s, back in the C#, VC++ and MS SQL Server era. Since then, my career has evolved through solution architecture, pre-sales & marketing, program leadership, sales leadership, and executive roles. Over time, I moved away from writing code — not because I stopped caring about software, but because my role shifted toward shaping systems, teams, and outcomes, rather than functions and classes.

Out of curiosity — and prompted by a very practical consideration while looking for a replacement for the much loved and retired Mint app (it used to track budgets and portfolio's beautifully) — I decided to build something again last weekend.

I didn’t build a demo. I built something I actually use.

I started with a simple idea: a portfolio tracker that could calculate returns and compare performance against market indices. Within hours, it evolved into a full portfolio management application that handles real-world complexity — multiple asset types, missing purchase dates, manual overrides, and account-level aggregation — all presented in a clean, usable interface.

At a feature level, the application includes:

Real-time stock prices using a free Alpha Vantage API
Excel/CSV imports
Annualized return calculations with edge-case handling
Multiple asset classes, including stocks, other assets, and cash
Account-level aggregation and intelligent classification
Weighted returns with manual overrides where math doesn’t apply
Export/import for data portability

By the end of the weekend, I had written over 4,000 lines of working code and had a production-quality React application that I genuinely use to track my own portfolio.

Before tools like this, building something of this completeness even as a serious side project would have required weeks of sustained effort and constant context switching — and realistically, it’s the kind of thing that often never quite gets finished.

What changed for me wasn’t ambition or capability. It was the ability to move from “someday” to “done” in a single weekend.

What struck me most was that the real shift wasn’t speed. It was compression.

AI coding agents didn’t replace development. They collapsed the distance between intent and execution. Instead of spending time remembering syntax, wiring libraries, debugging boilerplate (all of which i was terrible at even when i was coding during my early years), or setting up infrastructure, I stayed focused on data models, business logic, UX decisions, and architectural trade-offs.

The agent handled the mechanics. I stayed in the judgment loop.

That distinction matters — because clarity, intent, and trade-offs are where real value is created. This experience reinforced something important: most organizations don’t suffer from a lack of ideas. They suffer from the cost — financial, cognitive, and organizational — of turning ideas into software.

When a production-quality application can be built with a modest tool subscription, free or low-cost APIs, and a few hours of focused intent, the economics shift. Small internal tools suddenly feel worth building. Prototypes replace long documents. Experimentation becomes cheap enough to encourage learning rather than delay it. This isn’t just faster delivery. It’s a reframing of what’s now feasible.

When building becomes this easy, the bottleneck moves. It shifts away from raw engineering capacity and toward organizational clarity and guardrails. The question becomes less about who has time to build and more about what should be built, why, and with what constraints. This wasn’t about going back to coding.

It was about recognizing that the human role has moved up the stack — from writing code to shaping systems, defining intent, and exercising judgment. AI doesn’t eliminate the need for engineering excellence. It amplifies it.

The people and organizations that benefit most won’t be the ones chasing tools. They’ll be the ones who learn how to convert intent into working systems — clearly, quickly, and with purpose.