I’m a researcher, a (failed) founder, and a former/future startup executive. Intellectually promiscuous. A fox, not a hedgehog. I’ve always read widely to forge as many interesting connections as possible, curiosity catalyzed by an obsession to understand.

Modern R&D has rapidly become both easier to execute and harder to navigate. Agents enable us to translate ideas into software at a pace and scale that was previously impossible - but the expanding universe of models, methods, tools, and knowledge makes understanding what’s possible, and how to use it well, an increasingly demanding undertaking of its own. This begs the question: how should we organize research when general-purpose intelligence can be summoned on demand, configured for different kinds of work, and deployed across "infinite" investigations at once? Kensho is a generalizable, extensible operating system for R&D, built for humans and agents to investigate any idea, opportunity, or solution regardless of domain or expertise within a singular platform.

A paper, a photograph, a conversation, and a codebase each present us humans with different containers for consuming information, and though eminently useful in these forms, these containers mask underlying structures that provide different, container-agnostic connections. Every information object preserves some distinctions and obscures others; the forms that make it useful to read, watch, or work with also shape which relationships we can readily perceive, and which remain buried. Knowledge graphs are far from a new concept, but we can now put agents to work continuously constructing, managing, and evolving them across a breadth of materials that would be impractical to connect by hand.

Open-Ended Knowledge Graph Construction (OKGC) is built to construct knowledge graphs from any type of material without requiring us to prescribe its entities and relationships in advance. It decomposes materials into collections of primitives, then extracts and resolves the entities and relationships as part of the ever-growing knowledge graph. These graphs aren’t simply different storage vehicles for information but instead allow us to forge the unusual connections that often emerge from crossing between domains or disciplines. And thus every information object we ingest or create can become raw material for persistent, perpetual graph construction - not simply adding to what’s there, but connecting previously separate ideas, exposing contradictions, and revising the structures through which we understand them.

Choosing the right model for a particular job is a highly challenging problem unto itself. The proliferation of models gives us an extraordinary range of capabilities, prices, and trade-offs, but knowing what a model costs or how quickly it responds tells us little about whether it will actually do the work well (or optimally). And even that question is incomplete: the same model can perform fundamentally differently depending on its instructions, context, memory, tools, and the environment in which it operates. Model selection is therefore one decision within a much larger design problem - the construction of a harness whose components and configurations collectively determine what a given implementation can accomplish. We tend to define this as "agent design", but agents are only one way we use models; a single extraction or classification also depends on the conditions we construct around it.

The Model Use Platform brings these decisions together in a generalizable, extensible system for designing the complete implementation: the model, its harness, and how both interact with the product and work they’re meant to serve. And though I described this above as “harness design”, this is effectively a problem of DISCOVERY. Rather than settling on a configuration through habit, intuition, or a handful of promising results, the platform is built to explore populations of candidate implementations, judging their outputs against the application’s requirements while preserving useful differences across quality, cost, and speed. Deployment feeds the persistent delta between expectation and reality back into that search, allowing the implementations to evolve with the work itself.

From my time at Omaze raising money for nonprofits, it's been a consistent shock that there is not, to this day, a singular platform for delivering and managing donations as an individual giver. Mind you, individuals in the US donate $200B-$300B annually. So I'm building one instead. Amplify makes it dead simple to make one-off or recurring donations to the more than 1.5M 501(c)(3) charities in the US.

But consolidating giving into one place also creates an opportunity to vastly improve how we decide where to give. Today our national giving system presumes you already know which ones to look for, and thus the vast majority of nonprofits struggle to find even those that would absolutely be interested if only they knew! We have this backwards. As humans, we start from our broader wants and feelings - each with a distinctive answer to the question "how would you like to make the world better?" That's the starting point within Amplify - drill deep with each individual donor to elicit what they care about and then provide detailed recommendations.