Watching an AI-Native CRM Run the Full GTM Loop Live: Lightfield CEO Keith Peiris Demos a Stalled Deal, an Automation, and Ten New Prospects
Most CRM demos show you a nicer place to store data you still have to enter yourself. Lightfield’s demo at SaaStr did the opposite. Keith Peiris, co-founder and CEO, worked a real stalled deal in real time, turned what he learned into an automation, then used that same learning to generate ten new prospects. No slides about the future of selling. The full loop ran end to end on live data.
Lightfield is a natural language CRM with about 3,000 customers. The pitch reduces to one idea: if the CRM holds complete customer context and runs an automation layer on top, reps stop doing CRM work and start doing the actual selling. Here is what that looked like running.
The CRM assembled itself
Before any deal work, Keith made one point that reframes everything else: nothing in the demo instance was entered by hand. He connected mail, calendar, a data warehouse, and a call recorder, and Lightfield built the rest.
Accounts came in enriched across multiple data providers. Opportunities were created automatically from emails and calls. The contact book was populated by roughly ten different vendors. Tasks and meetings filled in on their own.
That is the foundation the whole product sits on. The CRM is not a form to fill out. It is a customer context engine that builds from the systems where work already happens, and the go to market gets built on top of it.
Working a stalled deal in real time
The deal: selling process automation into Johnson Controls, a very large manufacturer. The timeline showed lead scoring, opportunity updates, and email back and forth with the VP of Innovation. The summary flagged it as stalled. They had been trying to scope a 30-day POC and could not move it forward.
Instead of guessing, Keith asked the CRM directly: why is this deal stalled?
What happened next is the part worth paying attention to. Lightfield did not just summarize the thread. It pulled every interaction inside the opportunity, then compared the deal against closed won and closed lost opportunities and even looked into QBRs. It ran code in a sandbox to find similar deals and surface the pattern.
The finding: they had never met the CIO. The analysis built its own proof. Every deal they had won got a head of IT or a director of IT involved early. The deals they lost did not get IT approval early. This deal was stuck in the same place the lost deals got stuck.
The recommended action was specific: get a meeting with the CIO, who the champion had referenced a few times without a meeting ever landing.
So Keith said: find the CIO and add them to the opportunity. Lightfield ran web searches, worked through about twenty account and contact enrichment tools, cross-checked LinkedIn, created the contact, and associated it with the opportunity. Then it drafted an email looping the CIO into the POC, written in the rep’s own tone, pulling in specific details about the pilot.
One deal, unstuck, in a few minutes. The mechanics are interesting. The reframe is more interesting: the CRM diagnosed the deal by comparing it to history, not by following a static playbook.
One deal became an automation
The lesson from that single deal applied to the whole team. Every rep should loop in IT before the POC stage.
So Keith turned the work he had just done into an automation, in one sentence: run this process every time a deal reaches the POC stage without an IT contact.
Lightfield built a natural language automation that pulls the relevant CRM data, applies the logic, finds the IT contact through web search, and drafts the outreach email when a deal moves stages. Keith compared it to Salesforce Apex, with one difference that matters. You write and iterate on these in plain language, and they run in Python in the background.
Activation surfaced a permissions check. A RevOps leader or CEO might have full CRM access, but a rep does not, so the system asked for the specific permissions the automation needed: account access, note creation, the enrichment service. Approve and activate.
The workflow was discovered by working a deal, not designed in a planning meeting. That sequencing is the point.
From a single deal to new pipeline
With the deal unstuck and the pattern codified, Keith pushed for the third move: turn the learning into prospecting.
He asked what patterns in closed won deals could generate new pipeline. Lightfield read the Johnson Controls context, then the full set of closed won deals, and came back with a few findings. Large industrial hardware manufacturers respond to the downtime figure, because that is where the real pain sits. IT leaders are receptive to the value prop based on existing QBRs and sales engagement. And the POCs should be scoped more tightly, a note worth taking back to the sales team.
From there: find contacts at ten companies matching that profile. Lightfield ran an account discovery skill across the CRM accounts they had not sold to, ran an ICP search across data sources, read unstructured data from every stalled and lost deal, and found the IT leader at each company, cross-checked across two or three sources including LinkedIn.
It created the contacts and the associated accounts, following clean CRM hygiene: if you prospect someone, they belong in the CRM, connected to operations.
Then Keith added a filter that shows where this gets sharp: show me which of these companies are already using legacy factory floor software. The logic is real. Companies running legacy SCADA and PLC systems feel the downtime pain most, which is the wedge.
Lightfield ran a web search across the ten contacts and graded the signal. One aerospace company showed high signal pulled from job postings, which Keith called out as a reliable prospecting source. Another surfaced from a LinkedIn post. A few came back lower signal from heuristics.
The last step built a custom three-step sequence for the high-signal accounts, learning from prior sequences, the research just completed, and the rep’s writing style. The structure: lead with the legacy burden, bump on opportunity cost, leave the door open. It pulled a proof point from a QBR with a large elevator manufacturer in their data and built the sequence in real time.
Connect the CRM to email, diagnose why a deal stalled, learn from it, codify the learning into an automation, and apply that same learning to outbound. That is the loop, and it ran on one screen.
The Q&A answered the harder questions
The demo is the easy part. The questions from the room are where AI-native CRM usually breaks down. Lightfield had answers.
Data governance. Asked what happens when someone overwrites important information, Keith explained the architecture. Everything is stored at a foundational level, including emails and events, with a CRM schema sitting on top. They track edits and version history for every field, every attribute, every object. They can see whether an agent or a human changed something and roll it back. Role-based access control applies to every piece of data.
Adoption. The CEO of We Crush Events, an eight-figure event planning company running thirteen reps on Zoho, asked the question every operator asks: how do you get non-technical reps to adopt something new? Keith’s answer had three parts. Migration is fast, often two hours off a Zoho or HubSpot, so people are in the new tool quickly. The carrot is that reps have no CRM work left to do, since fields, forecasting, and reporting update on their own. Training runs 30 to 45 minutes, and anyone who has used ChatGPT picks it up.
Deliverability. The same operator runs a cold outbound farm with fifty inboxes and roughly 200,000 contacts, and asked how Lightfield controls email quality at that volume. Keith described in-house email warming, distribution across inboxes, and intelligent sync rules. For most reps, outbound only syncs to the CRM when someone responds, so you never end up with half a million dead contacts. A contact lands in the CRM when it is real and a meeting is booked.
Metrics. On measuring twenty combinations of ICPs and angles, Keith pointed to a code sandbox. You generate any custom report on demand, save it, and build interactive charts per campaign to compare performance.
Security. On the agent generating and executing code freely, Keith explained that the agent, external systems, and the UI all run through the same Lightfield API. Rate limits and data access are controlled through that API. An agent acting as an AE is bound to the same information access and rate limits as that AE, enforceable at the admin level.
One more detail from the close: Lightfield does not hide the product behind a sales team. Self-serve signup, a 14-day free trial, and a sales team available if you need help.
Five unexpected learnings
1. The CRM stays clean because it refuses to write most contacts. Every other CRM captures everything and drowns in dead records. Lightfield inverts it. Outbound contacts only sync when someone replies. The database stays clean by default, not by quarterly cleanup projects. For a company sitting on 200,000 contacts and a fifty-inbox outbound farm, that single rule is the difference between a usable CRM and a graveyard.
2. The automation was found, not planned. The best workflow in the demo did not come from a RevOps planning session. It came from working one stalled deal and noticing the pattern. Lead with the deal, extract the lesson, then codify it. Most teams do this backwards: they design elaborate automations up front and then watch reps ignore them. Discovering automations from real deals means they actually reflect how you win.
3. Job postings are a top prospecting signal, and the CRM knows how to read them. The highest-signal account in the prospecting run surfaced from job postings revealing legacy SCADA and PLC systems. Hiring activity is one of the most honest indicators of what software a company runs and what pain it feels, and almost no CRM mines it. Treating unstructured public signal as first-class prospecting data is a real edge.
4. Version history on every field is what makes autonomous agents acceptable. The governance answer was not a compliance afterthought. It is the unlock. You let an agent write to your CRM only if you can see every edit and roll back any change. Tracking version history at the field, attribute, and object level is the boring infrastructure that makes the exciting agent behavior safe to turn on.
5. The agent inherits the human’s permissions, so there is no separate agent security model to manage. The security answer was cleaner than expected. The agent runs through the same API as the UI and is bound to the access level of whoever is operating it. An AE’s agent can only do what the AE can do. That removes an entire category of “what is the AI allowed to touch” governance work, because the answer is already encoded in your existing role-based access control.
