2026 has been a year of subtraction.
I am a founder who loves adding features. Every feature I ever added came with a good reason: users asked for it, a competitor had it, or it made a demo look more complete. That is exactly the problem. Adding is easy because every addition can be justified on its own.
This year we went the other way. Today our product has one core feature:
Make it simple for an agent to talk to another agent.
To get there, we deleted agent memory, calendar, to-dos, a security layer, personal agent execution, and much more. Roughly 99% of what we had built is gone.
It hurt. But it taught me something I now believe strongly: subtraction is a harder version of addition. To add, you only need a reason. To subtract, you need to actually know what matters most, and be willing to bet on that answer.
This essay is about why that one-sentence thing, a simple abstraction, matters so much. I've come to see the same lesson from three directions: as a founder, as a researcher, and as someone building infrastructure.
What a simple abstraction looks like
The products that changed how we live can each be explained in one sentence:
- Google lets you search every website.
- ChatGPT gives you a box that answers your questions.
- Stripe sets up global payments for you with a few lines of code.
Behind each sentence is an enormous amount of complexity: crawling and ranking billions of pages, training frontier models, negotiating with banks and card networks in dozens of countries. But none of that leaks into the abstraction. The user sees one box, one input, one promise.
That is the trick. A simple abstraction is not a simple system. It is a complex system that has been compressed until it fits in one sentence, and that compression is the hardest part of the work.
The founder's view: one sentence or nothing
Every VC and every incubator asks you the same thing: what does your product do, in one sentence?
When I was younger I thought this was a test of communication skills. Now I think it is a test of whether you actually know what you are building. If you need a paragraph, you probably have a bundle of features rather than a product.
For a long time we were a bundle. We had memory, calendar, tasks, execution, security, and agent-to-agent connections. Each was defensible. Together they were unexplainable.
Shortly after we cut down to one thing, a user did something we had never designed for. They shared a link to their agent so it could help someone else debug a problem. There was no "debugging feature". The two agents simply talked.
That only happened because the product was simple. When it was a whole workspace, there was too much to understand before you could do anything. Once it became just "your agent can reach another agent", people started finding uses for it themselves.
If the abstraction is right, the use cases grow out of the users, not out of your roadmap. Our job stopped being "build every use case". It became "make connecting two agents so cheap it costs almost nothing", and then get out of the way.
I saw the opposite lesson while looking at a peer team building agent infrastructure. In many ways they built the most complete version of what our product used to be: a full workspace, with very comprehensive ways of connecting agents. It is a good product, with a real community. And yet it still felt heavy. I didn't want to start using it.
I think the reason is structural. A workspace is a huge surface; Microsoft has spent decades on it, and Lark a decade. Agents are already complex, with many brands, runtimes and tool formats. Put one complex thing inside another and the difficulty doesn't add, it multiplies, both for the builder and for the user deciding whether to take the first step.
The same discipline applies to what you choose not to optimise. We cut our security layer. That wasn't because security doesn't matter. It was because our current users, teams coordinating internally and individuals coordinating their own agents, are not yet bottlenecked on it. Over-optimising that early would have tied the product in knots. First find the abstraction people actually want to use, then harden it.
The researcher's view: hierarchical exposure
There is a famous line, usually attributed to Pascal: "I have made this letter longer than usual, because I have not had time to make it shorter."
Short is expensive. Writing something short means processing it, deciding what to drop, and then thinking carefully about how each layer of your audience will actually engage with it: what they will click, what they will skip, where they will stop reading.
Research papers are the clearest example I know. Why is an abstract written the way it is? Why does the introduction follow such a rigid shape? Because a paper is read in layers:
- The title: most people read only this.
- The abstract: a smaller group decides here whether the work matters to them.
- The first figure and the introduction: fewer still, who want to know why it works.
- The method and experiments: the few who will build on it or review it.
Each layer has to stand on its own. Someone who stops at the abstract should leave with the correct one-sentence idea. Someone who stops after the introduction should be able to explain the contribution to a colleague. I think of this as hierarchical exposure: the same idea, revealed at increasing resolution, where every level is a complete and honest compression of the next.
I often rewrite the introduction of a single paper dozens of times. The results don't change. The method doesn't change. I am only trying to get the exposure right, so that the core idea arrived first and every paragraph after it earned its place. That is the same work as finding a product's one sentence. A paper's abstraction is its abstract.
The infrastructure view: the stronger the agents, the simpler the interface
My advisor at Columbia has spent decades in systems research, and his work has stood the test of time. The thing he keeps coming back to is not a particular algorithm. It is the importance of a simple abstraction.
Systems history keeps proving him right:
- Unix: everything is a file. One idea, and pipes, devices and sockets suddenly composed.
- The web: a URL plus HTTP. Anyone could publish, anyone could link, and nobody had to coordinate.
- The relational model: tables plus a declarative query. You say what; the database decides how.
None of these were the most feature-rich option of their time. They won because the abstraction was small enough to fit in your head and general enough to carry things nobody had imagined yet.
When I asked him about JEV, his answer was the same: it is a simple enough abstraction. He added something I hadn't appreciated. Once the abstraction is right, others can clone your implementation immediately, and many open versions will appear. But they all end up learning your abstraction. The implementation can be copied; the way of thinking becomes the standard.
This matters even more for infrastructure built for agents and for the people who build LLM systems. You might expect that as agents get more capable, they need less help. I think the opposite is true. The stronger the agents get, the more they need good infrastructure, and the more that infrastructure needs a simple abstraction.
A capable agent is a new kind of user. It reads your interface, reasons about it, and composes it with everything else it can reach. A small, general abstraction is something it can pick up instantly and combine freely. A sprawling, special-cased interface wastes its capability on figuring out your system instead of doing the work. Builders feel the same thing one level up: they adopt the primitive they can explain to their teammates in one sentence.
That is the bet behind what we are building now. Connecting two agents should be as obvious as following a link.
Knowing and doing
What I learned this year has two halves, and both matter.
Knowing: understanding that a simple, general abstraction beats a complete one, and being able to say in one sentence what yours is, whether it's a product, a paper or a piece of infrastructure.
Doing: actually deleting the features, cutting the paragraphs, rewriting the introduction one more time, even when every piece you remove had a good reason to exist.
Knowing without doing is just taste. Doing without knowing is just thrashing.
A simple abstraction is one of the great things a builder can give the world. It is hard to find, painful to commit to, and looks almost too small when you finally ship it. That is usually how you know it's right.