5 Comments
User's avatar
Justin's avatar

Two more questions;

On engineering productivity: if AI meaningfully increases output, does that actually reduce legacy tax, or just let us build complexity faster? Without changes to governance and architecture, I wonder whether velocity simply increases entropy.

And on SaaS fragmentation: do you think cheaper engineering leads enterprises to rebuild more internally, or instead pushes vendors to expose more composable, memory-native substrates? It feels like lower production costs could lead to either more insourcing or a new generation of specialized platforms.

James Kaplan's avatar

On complexity, it all depends on how well you build

In Saas, I think its all of the above

Companies will build more

They will leverage more “components”/substrates

Because of the lower cost of “production” SaaS companies will get more specialized, reducing the “one size fits none” phenomenon

Kunal Binjewar's avatar

This is a much-needed reality check for the industry, James! Coming from a Strategy background, I constantly see the hype around AI coding overshadowing the actual architecture and mechanics of software. You perfectly highlighted why the physics of development can't just be bypassed.

Are you planning to expand more on this specific angle? It honestly feels like a series in the making!

Justin's avatar

One thought I’ve been wrestling with: both context graphs and agent-driven world models seem to start from artifacts that are already compressed - tickets, approvals, logs, etc. By the time something shows up as a “trace,” much of the real context (uncertainty, side conversations, social nuance) is already gone. It makes me wonder whether we’re building better maps of bureaucracy rather than capturing how decisions actually happen.

I’ve started to think enterprises may need a different primitive - more of a System of Memory than a System of Record. Start with the raw substrate (meetings, threads, emails) and derive structure from that, rather than assembling structure from APIs and logs. In that framing, context graphs become views over memory, not the foundation itself. The difference feels meaningful: one tells you what happened; the other helps explain why.

Curious how you think about that distinction!

James Kaplan's avatar

I think we are going to have multiple layers

We will always need RDBS to store transactions

There will be a “state graph” to track relationships among products, customers, vendors, etc.

Then I could see a context graph on top of that that tries to store all the context that got us to the state that exists