At a small startup, a prospect's follow-up, a bug investigation, and a weekly update can all land with the same founder. Someone has to check whether the prospect returned after a demo, connect a complaint to a product problem, turn meeting decisions into tasks, and find out what the developers shipped. Preparing an account for a useful demonstration adds another job to that queue.
Each request crosses services and people. The founder dispatches work, a developer reconstructs the status, and sales waits for customer information. A product manager connects the conversation on a call with the behavior recorded in analytics. Much of the effort goes into gathering the context before anyone can answer.
At referent.law, we give some of this work to Eva, our shared AI assistant. We are building an AI-native CRM for small legal teams, and we use Eva inside our own company. These are separate things: she helps us build, sell, and test the product.
People ask Eva in Slack. She may search the history, query the CRM, analyze product events, work with tasks, launch a coding agent, or check the result in a browser. The requested output can be a summary, fix, document, or link that the person can verify.
These anonymized examples cover late June through September 2026. The business functions overlap in our small team; they are not separate staffed departments.
Sales: what happened after the demo
After a demo, sales needs to know whether the person registered, connected email, and tried the product independently. Those stages determine what to ask in the next conversation.
Previously, answering that question meant gathering information from the CRM and analytics or asking developers. Now a salesperson asks Eva for the outcome they need: check lead activity after onboarding and suggest the next contact.
Eva compares the available CRM records with PostHog events, separating registration, integration connection, import completion, and actions inside the application. Email processing on the server can continue after the person has stopped opening the product, so it cannot be counted as a return visit.
In one review, background events were still arriving for some leads. Once Eva separated those events from independent use, the recommendations changed. Sales could discuss the experience with people who had tried working on their own and help the others return to reach a first useful result.
The interpretation depends on what initiates an event. Once a mailbox is connected, processing can continue because the system has work to do, even if the prospect takes no further action. Registration, connection, and import therefore describe different stages of the relationship with the product. A useful lead brief would retain the latest supported stage and the evidence behind it. That lets sales ask about an unfinished import without congratulating the person on repeated use. It also leaves room for the prospect to explain activity that the available events do not capture, rather than making the event history the final account of their experience.
Instead of a generic “What do you think of the product?”, the conversation can address a particular stage: connection, import, or independent use. Eva must still avoid treating missing events as a diagnosis. A person might not return for many reasons, and analytics cannot replace a conversation.
She has also been asked to select priority leads for beta testing and analyze customer interviews. These tasks call for a different kind of work: assemble a profile, needs, and constraints from scattered materials without making the team reread the entire archive before every decision.
Marketing: acquisition, research, and demos
Marketing needs to know more than how many people visited the site. It needs to understand where they came from, whether they registered, and what happened next.
Eva has analyzed traffic sources, new trials, and partner referrals against product activation. The comparison helps marketing examine what happened after acquisition. Incomplete attribution remains a gap in the analysis, rather than evidence that a channel worked.
Another area is audience research. The CRM and call recordings already contain material for positioning: how lawyers organize work, which tools they use, where they lose time, and what they distrust. Eva helps organize these observations.
If a salesperson describes the same feature on every call, frequent mentions in transcripts do not necessarily indicate strong demand. We need to distinguish the customer's words from our presentation, and avoid counting the recording, summary, and note from one conversation as three independent confirmations.
These analyses inform which workflow to show first, which objections to address on the website, and what to prepare for a demo.
One practical example was a demonstration of customer request intake. Eva prepared a website for a fictional law firm, helped configure the form, followed the process through to the request appearing in Referent, and assembled a short video with English narration. The version intended for lawyers omitted the technical setup: viewers saw the form, submission, and result in the account. This was material that could be sent to a prospect.
The intake demonstration follows one request across the boundary between the fictional firm's website and the Referent account. The form is the starting point; the resulting request in the account is the part that makes the demonstration useful to a lawyer. Showing both gives the viewer a way to understand where a prospective client's information goes. The narrated version can omit configuration steps because the audience is assessing the intake workflow. That editorial choice depends on having followed the submission through first. A recording of the form alone would not show the part of the workflow the firm would use after receiving an inquiry.
A competitor review also changed after a source check. Eva's initial comparison used a limited view of another product's trial. Documentation then revealed export and API capabilities that the trial had not exposed, and the team corrected the competitive claim before using it in positioning.
The founders’ weekly review
An executive's questions usually cross departmental boundaries. What did we ship? Who started using it? What are people complaining about? What did we discuss with prospects? Where is the biggest risk now?
One real request asked Eva for exactly this overview. She gathered information about releases and GitHub changes, PostHog activity, available support requests, and lead conversations.
The overview puts delivery beside use. Extensive onboarding work, for example, can coexist with a drop between connecting an integration and taking a useful action. The team then needs to check the effect of the changes, rather than infer success from closed tasks.
The investigation also exposed problems in the inputs. Different events gave incompatible registration counts, and some call recordings contained almost none of the other person's speech. The executive brief needed to carry those gaps with the findings so the founders could see which questions remained unanswered.
The registration conflict and the incomplete recordings limit different conclusions. Conflicting event counts make the size of a group uncertain; they call for checking what each event counts before presenting a single registration total. A recording that mostly captures our side of a call limits what can be inferred about the prospect's needs. Repeated sales explanations in that recording cannot supply the missing response. In the weekly overview, the founders can still assess documented engineering changes while withholding a conclusion about adoption or customer demand. The source gaps should constrain the particular finding they affect, without making unrelated evidence disappear.
Eva also reviews AI service spending and limits, project statuses, and engineering queues. For a small team, this is a convenient way to investigate an operational question without turning it into a separate analytics project.
Eva does not set strategy for the founders. She helps them avoid basing it on the loudest messages in the chat.
Product: investigating incomplete onboarding
To investigate new-user difficulties, Eva has to reconstruct the sequence of actions. Product bugs, a confusing interface, missing data, and a person simply leaving can produce superficially similar drop-offs.
Eva investigated such a request using PostHog events. The conclusion was more specific than “improve onboarding”: some people successfully created a workspace or connected an integration, but did not move on to meaningful work.
Other signals appeared alongside this: repeated attempts to create an existing workspace, confusion about connected mailboxes, and application loading errors. The reasons behind the behavior remained hypotheses. Leaving checkout does not prove that the price is too high. Taking no useful action does not prove that the interface was confusing.
The product manager can then choose a focused next check: reproduce the failure, inspect the journey, speak with the person, or change the point of first value. The evidence supports that choice before a broader redesign.
Eva also turns discussions and meeting recordings into Linear tasks. She gathers the decisions and clarifies expected behavior, so the ticket carries context and acceptance criteria for someone who was not on the call.
For larger changes, we developed a process of discussion, visual prototyping, and choosing a direction. After implementation, review and a demonstration of the working product matter. A prototype helps agree on what to build; it does not establish that it has already been built.
Engineering: working through the PR queue
Eva is assigned fixes, CI investigations, reviews, release preparation, and the sequential processing of pull requests. She can work in the repository herself or launch a separate coding-agent session.
The engineering work includes finding the related ticket, checking the current branch, resolving conflicts, waiting for CI, and updating status. Code generation is one step in that sequence; the surrounding checks determine whether the change is ready to proceed.
On explicit team instructions, Eva processed PR queues oldest first, with exceptions and a fresh check before each merge. A preceding merge could change the base branch, so an earlier green result did not establish that the next PR was still ready.
A sequential queue makes each accepted change part of the environment for the next one. A conflict resolution can alter the proposed code, and a merge can change assumptions another branch depended on. The fresh check is therefore attached to the version under consideration at that moment. If Eva hands part of the investigation to a coding session, the returned result still needs to identify the change and its checks so she can continue the agreed queue. A contributor's completion message cannot establish that the branch now being merged contains the reviewed result. This explains the need for follow-through between implementation, CI, and the confirmed merge.
The team asks for evidence of the state reached: test results, CI status, a confirmed merge, and real screenshots or video for interface changes. A task, an open PR, and a release are different outcomes. Eva's completion report has to identify which one was requested and verified.
People retain priorities, architectural decisions, and authorization for risky actions. Eva should return a verifiable result or a specific blocker, rather than another promise to finish later.
PostHog Inbox: ten PRs merged into development
PostHog Inbox connects reports of product errors with proposed fixes.
The team chat received technical errors as well as reports of problems found in user sessions. For example, a person renames a matter, clicks save, receives a rejection, and tries again unsuccessfully. In the same thread, the team asks Eva to investigate and prepare a fix. The task already has observed behavior behind it, beyond “something is broken.”
In one agreed batch, Eva corrected ten PostHog PRs and brought them through to merges into the development branch. The team also worked with PRs created from PostHog and separately experimented with its own error-finding and fix-starting automation. The ten-PR result records queue processing; it does not mean Eva discovered the problems or that the changes reached every customer.
A useful working sequence looks like this:
- Receive a signal. A PostHog error, proposed fix, or user complaint.
- Understand the context. Where it occurred, whether it disrupts work, whether it recurs, and whether it is an expected access denial.
- Check existing work. Look for an existing task, open PR, or released fix.
- Prepare and implement the change. Give a developer or agent a specific case and check the result.
- Reach the required status. PR, tests, CI, and an agreed merge. Then check separately what happens after the change is delivered.
Eva gathers the alert's context, checks existing work, creates a task when needed, starts implementation, and reviews the proposed PR. That joins steps that would otherwise pass between several people. An automatically generated fix still needs inspection for incomplete work, conflicts with current code, or a change that only addresses a symptom.
We dismantled the early custom PostHog factory while simplifying our processes. Work with PostHog Inbox and individual fixes continued, with people reviewing the changes.
Checking the effect remains a separate step: a merged PR does not prove that users no longer encounter the error.
QA: testing a legal workflow
Testing a legal CRM needs a working situation: a client and matter with correspondence, documents, deadlines, and participants. An empty account cannot expose whether those records stay connected through a legal team's work.
Eva helps create extended test scenarios with fictional participants. She prepares emails and documents, develops a matter's history, supports the walkthrough, and records defects. These scenarios serve both a person testing the product and an agent performing a bounded check.
Instead of “test email,” there is a specific situation: a new request arrives with a document attached, the correspondence must be linked to a matter, a deadline must be found, and another team member must be able to see the right result.
This exposes problems that do not appear in an empty account: an email linked incorrectly, a lost attachment, duplicate correspondence, an awkward confirmation, or an unclear import state.
Domain experts can show a failure without writing a technical bug report. Eva helps capture the steps, expected behavior, and visual evidence in the task, giving engineering a reproducible starting point.
The fictional matter supplies relationships a tester can follow through several actions. The attachment belongs to a particular incoming message; the message belongs in a particular matter; another participant needs to find the resulting record in the intended context. A useful defect report would name the step where that relationship broke and retain the expected result. This helps an engineer distinguish a missing attachment from an attachment present on the wrong record. The scenario's history also lets a later check revisit the same relationship after a fix, instead of starting with an empty account that cannot reproduce the original difficulty.
A prepared scenario must not be counted as a passed test: execution and its result need separate confirmation.
What happens without a new chat message
Some work starts on a schedule. Our configured processes include importing meeting materials into the knowledge base, synchronizing team sources, backups, a weekly project review, and preparing the Referent Weekly team edition.
Referent Weekly turns product changes, discussions, and other working sources into a readable account of the week. Team members can use the edition instead of separately reviewing each system's history.
The Linear project review addresses a related need: maintaining a clear view of work and visual evidence of changes. Temporary automations are also used for individual assignments, such as continuing an agreed PR queue or watching a specific release.
Not every step needs a reasoning model. Scheduling, data transfer, and condition checks are often better handled by an ordinary script. The model is needed where interpretation or a decision within the task is required.
Background jobs can fail at launch, access, or delivery. The status needs to distinguish a configured schedule from a successful run and a transferred recording from useful recorded content.
Scheduled processes still need visible statuses and a way to recover after a failure.
The sources behind a Slack request
A developer, salesperson, and founder ask different questions. Their sources are often the same.
The CRM holds relationships with prospects. Meeting recordings explain context. PostHog shows observed behavior and errors. Linear holds work agreements. GitHub holds changes and their checks. The knowledge base and conversation history help recover past decisions. A browser lets the result be examined from the user's perspective.
Eva connects the relevant sources within the request. Sales can ask for a lead-activity investigation without writing SQL; a founder can ask for the week's picture without specifying APIs. The same route supports documenting a problem or preparing a demo.
Working context: Twenty CRM and meeting recordings help reconstruct lead relationships and conversations; Gmail supports the review of available correspondence and preparation of email scenarios. GBrain is the corporate knowledge base, while Honcho is a separate memory layer for interactions.
Product and execution: PostHog supplies events and errors, Linear holds tasks, and GitHub holds code and checks. Through Conductor and coding-agent tools, Eva starts separate working sessions. The browser supports real walkthroughs, screenshots, and screen recordings; Cloudflare Pages is used to publish prepared web materials.
Hermes Agent, integrations, and accumulated working instructions support these tasks. Access is specific: some connections use APIs, others use tools or scripts. Eva needs to know where the relevant evidence is, which operation is permitted, and how to check the result.
Working rules accumulate too. For example: search for an existing task before creating another, avoid treating background events as human activity, attach real screenshots to defects, and do not declare completion based only on a contributor's reply. A repeated clarification becomes part of the next process.
A shared interface still does not mean unrestricted access. Permissions vary by system and operation, and some actions require separate authorization. For a team working in a legal context, this is a substantial part of how the assistant is designed.
Removing unnecessary supervision
At one point, engineering had accumulated too many supervising agents, watchers, and repeat checks. Maintaining that process began competing with doing the work.
The team asked us to simplify that process. We removed unnecessary management layers and limited repeat cycles so a small bug could follow a short path to implementation and review.
We also tightened what counts as completion. A prototype establishes a direction, an open PR proposes a change, and a successful build passes a technical step. When the request is for a working workflow, the demonstration must exercise that workflow rather than show one screen.
These constraints make Eva's work manageable. The team needs an assistant it can give work to and then understand what happened, including when it failed.
How we assess value
Time savings and a causal effect on sales have not been measured.
Based on team estimates, a post-demo lead activity check takes a salesperson around 10 minutes with Eva, including checking the result, against roughly 50 minutes of manual CRM and analytics work: around 5× faster. The minutes are estimates for that one repeat task, not a time study.
The working results are concrete: sales activity analyses, prospect demo materials, audience research, executive summaries, Linear tasks, engineering changes, and recurring team publications. The ten-PR development-branch batch is one bounded engineering outcome within that wider work.
The next evaluation should follow a request to its accepted result: a question to a usable answer, a complaint to a reproducible case, or a meeting decision to a task with an owner. Human interventions and corrections belong in that measurement.
The team still sets the result and checks whether Eva reached it. Investigations and preparation can cross systems within one request, but release decisions, risky actions, and acceptance remain explicit responsibilities.
It still begins with a short Slack message: Eva, look into it.