Loglens Labs builds enterprise AI that runs inside the customer’s own systems.
Loglens Labs builds AI products and runs small-model experiments, out of years of CRM, front-office and enterprise middleware work. This site holds the finished work and the work in progress, from founder Gokul Anantha.
What the lab believes
Three convictions behind everything Loglens Labs builds.
01
The right model for the job doesn’t have to be the largest one.
Operational work is narrow, repetitive and high-volume: scoring an intent signal, flagging a data conflict, choosing the next email. A small model trained for one of these jobs can beat a general large model at it, for a fraction of the cost, inside the customer’s own infrastructure.
02
Data sovereignty is an architecture decision, not a compliance box.
Every call to an external model is a data transfer. Operational AI runs on CRM records, financial data and customer conversations. The model should travel to the data, not the other way round.
03
AI that can’t explain itself won’t be trusted.
A score without its reasons is a black box. Every model the lab builds returns its output with the inputs that drove it, in words the person acting on it can check. Trust is what gets AI used.
Where small models fit
AI agents plan and act across tools. They are only as good as the operational signals they reason from. Loglens small models produce those signals inside the customer’s boundary: the agent asks, the small model answers, and the data stays where it is.
Layer 3Orchestration
AI agents and assistants
Plan, write and act across tools. They take operational signals from the layer below as inputs to their decisions.
Often an external API
Layer 2Operational intelligence
Loglens small models
Score intent, flag data conflicts, surface churn signals and draft with reasons. They run continuously, at volume, and return explainable outputs to the agents above.
The raw record. The small model reads it where it lives; it is never sent to an external model.
Inside the customer’s boundary
Insights flow up. The data never leaves layer 1.
Projects
Each project opens into the same short case study: the problem, what I built, and what it did.
Adaptive nurture (Logloop)
Live with customersA headless AI decisioning layer for B2B revenue email.
Problem
High-value B2B email goes out through third-party email providers with no signal, context or learning behind it.
What we built
An API-native layer above CRM and email infrastructure. It reads signals, builds context for each contact, drafts the email, enforces send guardrails and learns from every human edit.
Result
In a design-partner deployment: 4,604 mid-funnel leads activated, a 47% response rate, a 52%+ open rate and over 400% ROI on hard intent signals.
What we learned
Excel is still where the work happens. However capable the AI, people share their segments and check the results in spreadsheets, so the product has to fit around Excel, not ask them to leave it.
v1 ready · with a design partnerAn account 360 for mid-sized enterprises: a command-line tool that builds the whole lakehouse, from data through to insight, on the client’s own MongoDB and S3.
Problem
A full view of every account means stitching together several layers: ingestion, storage, modelling and reporting, each with its own tool and its own specialist. Mid-sized enterprises want the account 360 without owning all that complexity.
What we built
A command-line tool that generates a 360-degree lakehouse for each account, with the data, the model and the insight in one place. Purpose-built agentic frameworks sit behind it, and everything runs on the client’s own MongoDB and S3 instances, so the data stays in their storage.
Status
Version 1 is ready, and we’re building it out with an early design-partner client.
Collab
In-house testing · seeking betaA shared workspace on MLflow where data engineers, data scientists and business users build models together.
Problem
For a business user, enterprise ML is a black box from start to finish: the data, the model and how it was validated. People can’t trust or defend what they can’t see, so models don’t get used with confidence.
Why we built it
In GTM engineering engagements, finding ideal leads meant the same loop every time: reshape CRM data into an ML-ready form around outcomes and lifecycle, run a model such as XGBoost on a laptop, then translate the results into business language for the people who had to act on them. The work lived on one machine, and a lot was lost between the model and the meeting.
What we built
A shared workspace on MLflow, in business-friendly language, that brings the data engineer, the data scientist and the business analyst or executive together through every cycle: data, model, then deployment and validation. Business users take part through a conversational interface. It grew out of the work to find ideal lead profiles.
Status
In in-house testing. We’re looking for early beta teams, starting with an insurtech platform team and a mid-market enterprise ERP team.
The Collab prototype. Everyone on a flow shares one thread, and the pipeline moves through source, review, leakage, validity, target and training, with a teammate’s sign-off at each gated step. Sample data is illustrative.Deploying an ideal-customer-profile model. The assistant guides each step, and the model can start from a cold-start scaffold, an industry baseline or the customer’s own data, deployed locally or to SageMaker. From an in-house test run.
Cold-start data generator
v1 ready · pilot soonAn app that simulates industry lifecycle data, so models can be trained before real data exists.
Problem
A new model has no history to learn from. Real lifecycle data is scarce, slow to build up and sensitive to share, so models can’t be trained or tested on day one.
What we built
An app that generates industry lifecycle data to mimic real-world scenarios. Each run outputs a YAML configuration describing the scenario and a Parquet data file. The first use cases are GTM lifecycles for churn and win-loss, with parameters such as seasonality and buyer-committee engagement varied across runs.
Beyond GTM
Repurposed to generate cold-start data for an insurtech, where it worked well.
Result
Version 1 is ready, with a pilot launching soon.
Quotation AI for MSMEs
In build · prospective partnerA quoting decision layer for MSME manufacturers: it finds the quote request in the inbox, decides the quote, and sends it.
Problem
Quote requests arrive by email, mixed in with everything else. Someone has to spot them, read the spec, cost the job by hand and write the reply. That takes hours per quote while the buyer is asking competitors too, and quotes that go out are rarely followed up.
What we’re building
Intelligent email. Picks out quote requests from the inbox, or from WhatsApp.
Quote request. Reads the request and extracts the job spec.
Quoting decision layer. Small models cost the job from the shop’s machine rates, live material prices, catalogue and past similar jobs. The owner adjusts any line and approves; every correction, with its reason, calibrates the next quote.
Automated send. Sends the approved quote by email and follows it up until the customer answers.
Why it’s here
It’s the same decision layer as Logloop, applied to quoting: read the signal, decide the next move, act, and learn from every human correction.
Status
In build with a prospective design partner, an MSME lubrication-systems manufacturer, starting from a clickable prototype of their quoting workflow.
From the prototype: an enquiry costed line by line, with the last similar job for reference. The owner can open any line, change it and give a reason. Names and figures are illustrative.
Gifting-moment integrations for Postal (now Sendoso)
Client workWorkato integrations that turn employee, customer and partner events across 29 enterprise apps into automated gifting workflows.
Problem
Postal already integrated with HubSpot and Salesforce for the deal lifecycle a salesperson cares about. Everything beyond that was invisible to a Postal administrator: the employee, customer and partner moments that live in HR, CRM and other enterprise systems.
What we built
Integrations on Workato to Workday, UKG, BambooHR, Microsoft Dynamics 365 CRM and 25 other apps. Events in those systems show up inside Postal as gifting moments and trigger automated gifting workflows.
Why it’s here
A gifting moment is a signal that a relationship has a next move. The same idea runs through Logloop: find the moment, then act on it, for every relationship and every channel.
Result
Integrations with 29 enterprise apps, built for Postal’s platform.
One of the integrations, as Postal presents it: a Workday event, here an employee birthday, triggers a gift send. Screen grab from postal.com.
Lab notebook
Small-model experiments, written as hypothesis, setup and result. Unfinished entries stay visible, and results that didn’t work get published too.
Version 1In build
A learning engine that tests and learns for each customer
Each customer’s outcomes should teach the engine what works for that customer alone. A contextual bandit per tenant, a reinforcement-learning method that keeps trying new options while using more of what already works, can learn from every result and tailor each choice to the lead or account in front of it, without pooling one customer’s lessons with another’s.
Setup
A contextual bandit for each tenant, updated from outcomes as they arrive, inside the inference engine behind Logloop.
Result
The first build is in progress. Results will be published here, including what doesn’t work.
Version 2Planned
Small-model learning that keeps each customer’s nuance
The bandit learns which choice works; a small model can learn how each customer writes, sells and decides. Training customer-specific learning into a small model, such as one shared base model with a small adapter per tenant, should capture that nuance while keeping it from being generalised across customers.
Setup
Next version of the inference engine, building on the per-tenant contextual bandit.
Result
Pending.
Open research threads
The questions the experiments above are working toward.
Models that keep learning from the work
Active
A frozen model is out of date by the time it ships. The lab is building engines that learn from the signals operations already produce (human edits, accepted drafts and outcomes), learning from every outcome for each customer first, then moving to small models that keep each customer’s learning separate.
Inference at the data boundary
Active
Running models inside a customer’s VPC, on-premise or air-gapped network, without losing the ability to keep improving them. GTM360 is the first place this runs.
Reasoning as a first-class output
Active
Every score or draft ships with a structured account of which inputs drove it. Logloop already drafts each email with its reasoning; the research is about making that reasoning faithful, not after-the-fact.
Loglens Labs is led by someone who has built a decision layer for enterprise communication before, at SAP scale.
Gokul Anantha led the launch of SAP Intelligent Notification 365 as Head of Product: a communication services API with an embedded decisioning engine, behind SAP Cloud for Customer, SAP Marketing Cloud and other SAP products. Its intelligent channel orchestration lifted engagement and helped grow annual recurring revenue from $200M to around $350M. More than a billion emails and notifications ran through it, across email, SMS, push and WhatsApp.
The lab carries that work into the age of small models: decision layers that run inside the customer’s own systems, explain themselves, and learn from the people who use them.
