We build small language models that run inside your infrastructure — so the intelligence that emerges from your operations stays sovereign, private, and continuously yours.
We started in revenue operations because the data is structured, the outcomes are measurable, and the feedback loops are tight. But the pattern — fragmented systems, high-volume decisions, sovereignty-sensitive data, need for continuous inference — repeats across every domain that runs on operational data.
Our research and our products are the same thing. Each thread here is active work — not a roadmap item, not a whitepaper. Code being written, models being trained, deployments being configured.
Loglens Labs is the research layer powering Logloop. The Nurture Agent, Causal ML ICP model, and GTM Data Hub Agents all run on Loglens SLMs deployed inside your VPC. The lab and the product share the same codebase, the same data, and the same researchers.
See Logloop →India is not just a large market. It is the fastest large-scale digitalisation of operational infrastructure in economic history — 60 million SMEs coming online, a manufacturing sector being rewired by PLI incentives, 500 million workers entering formal employment systems, and a government that has built the world's most ambitious public digital infrastructure. Every one of these systems generates operational data. Almost none of it can afford large-model inference economics.
A mid-market B2B SaaS company in Bengaluru running ICP drift detection on 40,000 accounts monthly at GPT-4o pricing would spend more on inference than on its entire engineering team's cloud infrastructure. The unit economics of large-model APIs were designed for enterprises with Western ARR. India's 60 million SMEs — the backbone of its operational economy — are not that. Small models running on commodity GPU infrastructure, fine-tuned on domain-specific operational data, are the only architecture that makes AI operationally viable at Indian SME economics.
India's Digital Personal Data Protection Act creates a clear architectural imperative: personal data of Indian users should not leave Indian infrastructure without explicit consent and purpose limitation. For operational AI systems running on customer data, employee data, and financial records, this is not a compliance checkbox — it is a structural requirement. SLMs deployed inside Indian cloud infrastructure or on-premise satisfy it by design. Sending operational data to a US-based API does not.
UPI, GSTN, Account Aggregator, ONDC, DigiLocker, the OCEN credit stack — India has built the world's most sophisticated public digital infrastructure in a decade. The consequence is an extraordinary volume of structured operational data now flowing through Indian enterprises and government systems. The intelligence layer that makes that data actionable has not been built yet. It will not be built with large-model APIs at Western pricing. It will be built with small, sovereign, continuously fine-tuned models that can run at the transaction volumes India generates.
India's Production Linked Incentive schemes across 14 sectors are the largest manufacturing infrastructure investment in the country's history. The factories being built, the supply chains being formalised, the quality systems being digitised — all of it generates operational data that needs intelligence to act on. Demand signals, supplier risk patterns, quality anomaly detection, maintenance prediction — these are small model problems running at high volume on OT-adjacent infrastructure where data sovereignty is non-negotiable and latency requirements make external API calls structurally unworkable.
Tools like Claude Code and Claude Cowork represent a genuine shift in how knowledge work gets done — AI agents that can write, plan, execute, and iterate across an organisation's systems. They are powerful precisely because they can reason over context. But that reasoning is only as good as the operational data it runs on.
General AI agents like Claude Code are orchestration and reasoning layers — they are extraordinarily good at interpreting instructions, generating code, planning multi-step tasks, and synthesising information across tools. They are not optimised to run continuously against your operational data at volume, privately, with causal reasoning and full explainability baked in.
That is the SLM layer. Not competing with Claude Code — running underneath it. The SLM scores the ICP. The SLM flags the data conflict. The SLM surfaces the intent signal. Claude Code reasons about what to do next.
An AI agent that can read your CRM, your code, your documents, and your communications is extraordinarily capable. It is also an extraordinarily large surface area for data to flow through an external API. As agentic tools become standard infrastructure, the question of which data leaves your boundary — and which intelligence stays inside it — becomes more consequential, not less.
SLMs deployed inside your VPC are the answer to that question for operational data. The agent calls the SLM. The SLM returns an insight. Nothing leaves.
Founding team members are not early employees. They are the people whose instincts, judgment, and obsessions shape what the lab becomes. We are not hiring for roles. We are looking for people who see the same problem we see — and have something specific to say about how to solve it.
You have worked on model fine-tuning, causal inference architectures, or efficient inference at scale. You are frustrated that most interesting small model work is happening inside large labs and never ships into production. You want to work at the edge — where the model meets real operational data and the feedback loop is measured in days, not papers.
You think about deployment architecture the way others think about model design. Sovereign inference pipelines, VPC-resident model serving, continuous fine-tuning loops, schema-aware data ingestion — these are interesting problems to you, not infrastructure chores. You want to build systems that run unattended and improve over time.
You have lived inside a revenue operations, manufacturing, supply chain, or financial services system long enough to know exactly where the data breaks down and which decisions are made on incomplete information. You are not a technologist first — but you know what you would build if you had the model layer available to you.
Founding team members shape the research agenda, not just execute against it. You will have a view on which problems we work on next, which domains we enter, and how we think about the tradeoffs between model performance and deployment constraints. Equity is part of this. So is the expectation that you have opinions worth arguing for.
Early. Deliberately. We have the thesis, the first deployments, the research threads, and a founder who has built at SAP enterprise scale and knows what operational data problems look like from the inside. We do not have a large team. That is the point. The people who join now will determine what this becomes.
We are looking for organisations with operational data problems worth solving, researchers who want to work at the production edge of small model deployment, and builders who want to ship something that matters.