Daniel Svonava

Daniel Svonava is the CEO and co-founder of Superlinked, building infrastructure that helps companies search complex data and run specialized open models in their own cloud. His work tackles the engineering between a model and a useful application: representing the right information, retrieving it accurately, and serving the models economically enough to use in production.

From Google to building for smaller teams

Svonava spent six years at Google, building core machine-learning infrastructure for YouTube Ads with a focus on predicting user behavior. His personal writing describes his motivation for returning to startups and his work on Primeflow. That career spans both the infrastructure of a large technology company and the smaller organizations trying to build useful products without its resources.

He founded Superlinked with Ben Gutkovich to make machine-learning-powered search, recommendations, analytics and retrieval-augmented generation easier for other companies to develop. In March 2024, the company announced $9.5 million in seed funding, co-led by Index Ventures and Tomasz Tunguz through Theory Ventures. Svonava’s ambition was to make vector-based computing accessible beyond the handful of technology companies with extensive internal machine-learning infrastructure.

His interest in enabling other engineers also runs through his writing about management. He values infrastructure and documentation that help people do their work, rather than organizing engineering around promotion rubrics. That preference gives his technical work an organizational purpose: reduce the amount of specialized knowledge and coordination an application team needs before it can ship something useful.

Retrieval that preserves more than text

Superlinked’s early contribution addressed a limitation of treating enterprise search as a text-embedding problem. Useful records often combine prose with structured attributes, and a search system needs to preserve those different signals. A vector database can index numerical representations, but the quality of its results depends on how those representations were constructed.

Svonava’s approach to semi-structured retrieval combines type-specific encoders and aggregates their outputs into one searchable vector. Different kinds of information receive representations suited to their type, then contribute to a shared representation used for retrieval. This gives the system a way to search across a record’s different attributes without reducing everything to an undifferentiated block of text.

His preference for better initial retrieval over heavy reranking follows from that design. A reranker can reorder the candidates it receives; it cannot recover a relevant record that the first search never found. Investing in the representation and initial candidate selection therefore changes what the rest of the pipeline has available to work with.

From retrieval infrastructure to inference

Building search, document-processing systems and agents brought Svonava and his team into another operational problem: serving many different models. An application might need an embedding model, a reranker, document recognition, structured extraction and a language model. Each has different runtime requirements and traffic patterns, while custom fine-tunes add another layer of deployment work.

Superlinked’s earlier vector-computing repository was deprecated as the company shifted toward Superlinked Inference Engine, or SIE. The Apache-2.0 engine brings those model workloads into a shared serving stack that can run inside a company’s cloud or an air-gapped environment. The shift extends Svonava’s infrastructure work from preparing data for retrieval to operating the models that process it.

Several choices distinguish his approach:

• Choose models task by task. Svonava advocates evaluating specialized open models against particular parts of a workflow, then adapting them where necessary. A contract-review agent, for example, can use different models to read scanned documents, retrieve clauses, extract fields, check content and run its agent loop. The benefit depends on matching each model to its job, rather than assuming one small model can replace a general-purpose model everywhere.

• Let workers build their own batches. For many short requests, a router can assign work using an outdated picture of worker capacity, leaving some queues crowded and others underfilled. SIE uses a shared queue from which workers pull requests and form batches. This worker-controlled batching puts the decision closer to the hardware that must execute it.

• Share GPUs across a fleet. Allocating a permanent worker pool to every small model can leave expensive hardware idle. Svonava’s team combines pinned models with on-demand loading and eviction under memory pressure. A Rust sidecar and local socket interface separate common serving logic from model runtimes, allowing the team to improve batching without rebuilding the same logic separately for every backend.

These inference design choices also address the coordination cost of deployment. Svonava wants AI engineers to introduce models and adaptations without an extended negotiation with infrastructure engineers every time. His team uses automated measurement and optimization loops to develop model support and ship tuned configurations. The aim is practical independence: application teams can experiment with their models while infrastructure teams maintain the systems that run them.