Abstract as High as Possible

Last night in Boston, Hongyin and I went to a talk by Omar Khattab on his fast growing DSPy framework. If you haven’t heard of DSPy (pronounced DS-pie), it’s a very clever approach to prompt optimization and abstraction. With over 2m monthly downloads, clearly developers are finding it useful.

One point that stuck out to me in Omar’s talk was his stance on the benefits of high level abstractions. He used the code below as an example of a low level, highly efficient, but hard to read function. Do you know what this function does? Unless you’ve seen this trick before, I doubt it.

This infamous function is used to quickly approximate the inverse square root, an optimization that enhanced the graphics for the PC game Quake III. Overall, it made the game slightly faster and more detailed, at the cost of a completely unreadable chunk of code.

If you can tell me what line 10 does without looking it up, I'll venmo you $100

This is a somewhat passable example of highly optimized code. The developer dove deeper down into the stack in a single isolated function to deliver a meaningfully more smooth experience throughout their game. Very often though, teams tend to over optimize their code and processes far too early. Imagine if this cluster***k broke containment of the sqrt function. The whole codebase would be unreadable, and it would be nearly impossible to adapt to new changes and improve the product over time without breaking things.

So many teams fall into this trap of optimizing deep down the stack early on, and as much as it might marginally improve that one particular thing you care about right now, it will certainly cause problems down the line. As Omar put it:

When you write at a lower level abstraction than you have to, you’re going to regret it.

We absolutely agree. Higher level abstractions are a gift for product builders to move faster and collaborate better. They lead to less bugs, less headaches, better teams, and better products. Better abstraction leads to good things in the long term.

Very few functions require the Quake III treatment.

A High Level Abstractions in Agents

The same principle applies to AI agents. In agent systems, there are really only two abstractions that matter: the agent’s instructions and the external tools it can use. Everything else is noise.

We’ve spoken with teams using LangGraph, CrewAI, n8n, and others with fine-tuned, low level control at the app layer, model layer, runtime layer, and even kernel layer. Every one of them ends up re-implementing similar fixes for context management, tool calling, and model selection. Most end up rip and replacing every couple of months. It’s a clear sign that they’re operating too far down the stack and that the abstractions available aren't complete.

I’ll promise you this, time spent improving your workflow instructions and your external tooling is time well spent. Focusing on these two inputs as the core abstraction of “what makes an agent” makes your development time more focused, your agent configuration more sharable and easily understandable, and opens up a whole new world of possibilities of what to build next as the models improve.

If it wasn't clear, Subconscious is an API to build agents that only requires text instructions and a set of tools to kick off a long running process. I’m hopeful that Subconscious will save teams hundreds of hours debugging and the headaches and regret that go with it by allowing teams to focus on the higher level abstraction for agents. We believe this is only possible with the optimizations we built into the core model-runtime co-design that underpins our system.

We had punchcards, then assembly language, then C, Java, and Python. Recently we had LLM APIs and agent frameworks. Now, you’ll have the Subconscious API to focus on what really matters when building long running, intelligent software.

We don’t think Subconscious is the last abstraction for agents or software, but it’s hard to get simpler from here.