I have noticed that I rarely carry every detail of a system in my head.
I may forget the exact name of a library, the shape of an old configuration file, or one implementation choice we made three years ago. But I usually remember something else:
What the system actually enabled. Where the state lived. Who had authority. What could fail. Which trade-off was hiding underneath the interface.
I remember the shape of the system.
For a long time, I thought this was simply an imperfect memory. Now I think it is also a way of reasoning. I compress a complex domain into a smaller working model, then carry that model into another domain and look for a connection.
This is how I can move from a discussion about Bitcoin to a question about how autonomous agents will pay for services. Or from building backend infrastructure to thinking about identity and memory for AI. Or from planning a piece of family land to building an interactive product around it.
The useful part is not knowing everything.
It is knowing which details can temporarily be removed without losing the principle that matters.
The dangerous part is that the removed detail may be the one that makes the whole idea impossible.
Understanding is often lossy compression
A complete model of a real system is the system itself.
Everything else is an abstraction.
An architecture diagram removes code. An API removes implementation. A database index removes the need to scan every row. A financial statement removes millions of individual events and presents a smaller representation of what happened.
We cannot reason efficiently without compression.
When I enter a new domain, I usually look for a few questions:
- What capability does this create?
- What constraint does it remove?
- Who or what is trusted?
- Where does state live?
- What becomes cheaper, faster, or newly possible?
- What failure would invalidate the entire promise?
The answers become a compressed model.
That model is not the truth in full resolution. It is a portable version of the truth, good enough to compare with something else.
Raw details are often specific to one implementation. Good abstractions travel.
New ideas often live in the bridge
Most product ideas are not created from completely new ingredients.
They come from connecting two existing capabilities that have not yet been combined in a useful way.
A person deeply embedded in one field can know far more than I do and still miss that bridge. Their attention is correctly focused on the hard problems inside the domain. They see every reason the simple model is incomplete.
Someone looking from the outside can sometimes see the transferable principle more clearly because they are not carrying the full weight of the implementation.
That does not make the outsider more correct. It gives them a different search space.
Bitcoin and autonomous agents are a useful example.
I do not need to memorize every line of the Bitcoin whitepaper to notice a potentially important capability: software can control and transfer digitally native value without requiring a traditional human payment flow for each transaction.
I can connect that capability with another emerging system: autonomous software that buys data, compute, storage, or work from other software.
The bridge appears quickly:
Agents will need a way to hold budgets and pay other agents.
That is a useful idea.
It is not proof that Bitcoin is the answer.
Depth makes the synthesis less random
Cross-domain thinking becomes dangerous when it is only a collection of interesting words.
My protection against that is not expertise in every field. It is depth in one field that has forced me to understand how complex systems behave when they meet reality.
I have spent more than thirteen years building backend systems. At Tilt, that includes live commerce, auctions, payments, sellers, shipping, fulfillment, and operational tooling. These systems have users, money, retries, timeouts, race conditions, incomplete data, and business rules that cannot be hand-waved away.
That experience gives me a set of durable questions whenever I look at something new:
- What is the source of truth?
- Who can authorize a change?
- What happens when the call succeeds but the response is lost?
- How is identity established?
- Can the operation be reversed?
- Who owns the failure?
- Can someone understand what happened six months later?
I may only know the surface of a new domain, but I am not combining concepts completely at random. I am testing them against patterns that repeat across production systems.
Building PLAYGRND and smaller HILLS Lab experiments strengthens the same skill. A concept becomes much clearer once it has users, deployment, state, and consequences.
Shipping turns abstract similarities into concrete differences.
The compression error
Compression works by removing information.
Sometimes it removes the wrong information.
I call that a compression error: the simplified model preserves the exciting part of an idea but discards the constraint that determines whether it can work.
In machine-to-machine payments, the attractive model is straightforward. An agent has a wallet, purchases a service, receives the result, and continues working.
The details immediately make it harder:
- How does the buyer know which agent it is paying?
- How is the spending authority limited?
- What proves the service was delivered?
- What happens when the service is bad or only partially complete?
- Can the payment be refunded or disputed?
- Are the transaction costs sensible for the value being exchanged?
- Who is legally responsible when an autonomous action causes a loss?
- How does a company account for thousands of small machine purchases?
Any one of these could change the implementation completely.
The final solution may use Bitcoin, stablecoins, prepaid credits, a traditional payment provider, internal net settlement, or a combination of several rails. The original connection remains interesting, but the first answer may be wrong.
This is the point where good synthesis can become bad conviction.
If I forget that my model is compressed, I can mistake a clean story for a working system.
The Synthesizer and the Verifier
I need two different modes of thinking, and they should not run at the same time.
The Synthesizer
The Synthesizer is allowed to be early, incomplete, and slightly unreasonable.
Its job is to notice similarities, combine primitives, and produce hypotheses. It asks what could become possible if several trends continue. It does not stop every five minutes to prove the entire market, architecture, and legal model.
This mode needs freedom.
If I force every new connection through a complete expert review while it is still forming, most ideas will die before I can express them clearly enough to test.
The Verifier
The Verifier has a different job.
It does not ask whether the idea sounds exciting. It asks which assumption is carrying the most weight and how cheaply that assumption can be attacked.
It looks for the missing constraint, the uncomfortable expert, the production edge case, the legal boundary, or the user behavior that would collapse the bridge.
This mode needs discipline.
If I skip it, an intuition can quietly become a roadmap, an investment, or a public claim without ever passing through evidence.
The Synthesizer without the Verifier creates confident fiction.
The Verifier without the Synthesizer produces excellent reasons to build nothing.
I need both.
Label the level of certainty
A large part of intellectual honesty is simply naming the state of an idea correctly.
I find three labels useful.
Intuition
I see a connection worth exploring.
At this stage, the idea has earned attention, not belief. I should be free to discuss it, but I should not present it as expertise or make a large decision around it.
Working hypothesis
I understand the main mechanism and have investigated the obvious constraints.
The idea is specific enough to make predictions. I can describe what must be true, what could invalidate it, and which test would create better information.
Validated
Evidence supports the important part of the idea.
That evidence might be a prototype, real user behavior, production data, an expert review, or repeated results. Validated still does not mean permanently true. It means the idea has survived more than my own ability to explain it.
The problem is not shallow knowledge.
The problem begins when I describe intuition using the language of validation.
Find the weakest part of the bridge
Before I invest serious time or money into a cross-domain idea, I want to write down five things:
- The principle: What capability am I taking from domain A?
- The connection: What am I combining it with in domain B?
- The critical assumption: What must be true for the bridge to hold?
- The failure detail: Which ignored constraint could prove the model wrong?
- The cheapest useful test: What can I do now to get evidence without building the whole company?
The test should target the assumption, not decorate the idea.
A landing page can test whether people understand a promise. It cannot prove that the core technology works. A technical prototype can prove that two systems connect. It cannot prove that anyone wants the result. An expert conversation can expose a regulatory constraint. It cannot prove product demand.
Each test answers a different question.
The goal is not to collect activity. It is to reduce uncertainty around the part most likely to kill the idea.
This fits how I think about asymmetric bets. A small prototype, a focused research session, or one uncomfortable conversation can be cheap on the downside and extremely valuable if it prevents months of work in the wrong direction.
A T-shaped systems builder
I do not need to become an expert in cryptography, monetary policy, robotics, AI research, product design, regulation, and every industry I find interesting.
That is impossible, and pretending otherwise would make the problem worse.
The more useful profile for me is a T-shaped systems builder.
The vertical part is deep engineering experience: backend architecture, state, APIs, payments, failure modes, operations, and the work required to make a system dependable.
The horizontal part is a collection of sufficiently accurate models from other fields. Not enough to claim authority, but enough to recognize a capability, ask better questions, and notice combinations worth testing.
The vertical depth keeps the horizontal exploration grounded.
The horizontal range gives the vertical expertise somewhere new to go.
This is not a compromise between specialist and generalist. It is a specific way of using both.
I do not need the full map
I want to keep following ideas before I fully understand them.
That is where some of the most useful work begins.
But I also want to become more explicit about the boundary between a strong analogy and a reliable conclusion. A bridge between two concepts is the start of an investigation, not the end of one.
I do not need to know every detail of every system.
I need to know which level of abstraction I am speaking from. I need to know what I removed from the model. I need to find the one omitted detail most capable of proving me wrong.
Then I need to test it cheaply.
The useful skill is not only seeing connections other people miss.
It is knowing when a connection is still an intuition, and having the discipline to make it survive contact with reality.