When AI Runs Your Sales Team, Who Is Accountable?

Jeffrey Wang spent a week off building a version of himself that never sleeps, never misses a Slack message, and can draft a response on his behalf to anyone at Exa who asks. He calls it Jeffbot. He described the project at the AI Engineer conference, and the talk is worth watching not primarily for the engineering — which is genuinely inventive — but for what it reveals about how fast AI-native companies are moving past questions that regulators, employment lawyers, and enterprise compliance teams have barely started forming.

Wang is co-founder of Exa, which he describes as "a search engine for agents" — the web-access layer powering tools like Cursor and Cognition. His argument, laid out in a recent talk, is that go-to-market is now an AI engineering problem. That part of the thesis is well-supported by what he's actually built. The part that deserves more scrutiny is what his stack assumes about data ownership, accountability, and the organizational structures that are quietly being redesigned around it.

The engineering case is coherent

Wang's dismissal of the product-versus-distribution debate is brisk but earned. "If you don't do both things, then you don't have a company," he says. The interesting move in his talk is what comes underneath: the claim that go-to-market, at its core, is a data problem. Not a hiring problem, not a culture problem — a data problem. And if it's a data problem, it can be structured as an engineering problem, which means it can be automated, measured, and improved iteratively.

Exa's implementation of this idea involves two interfaces and two agents. The ICP dashboard uses Exa's embeddings over the web to classify effectively every company in their addressable market, with anticipated spend attached to each. Request Lens monitors customer behavior — signups, usage spikes, sudden drop-offs — and alerts the team when something actionable happens. Layered over both are about a dozen agents accessible through Slack, each with access to internal company data, available to anyone on the go-to-market team who needs to dig into an account or build a demo. The system is lean by design; Wang's point is that a small team with the right data infrastructure can outperform a larger team without it.

None of this is especially controversial from an engineering standpoint. The sharper questions live elsewhere.

Whose emails, exactly?

Wang said he analyzed 760 of his own emails to derive his communication voice — his cadence, his preferred sign-off, the texture of how he writes — and then used hundreds of past decisions drawn from Slack and email to build evals that calibrate Jeffbot's judgment against his own. The model he named as his instrument during that week off was "Opus 4.5" — a designation worth noting carefully, since Wang presented this as his experience from the talk; Anthropic's public model versioning does not include an Opus 4.5 as of current releases, and that detail should be taken as Wang's characterization rather than an independently verifiable fact.

The engineering achievement is real regardless of which model he used. But the data provenance question is one Wang did not address, and it matters more than the technical implementation.

Email correspondence is bilateral. When Wang mined his inbox to extract his voice and decision-making patterns, he was necessarily mining the words of everyone who wrote to him — customers, partners, job candidates, investors. Those counterparties did not consent to having their communications become training material for a commercial AI system that other Exa employees can now invoke. Whether that implicates GDPR's Article 6 lawful basis requirements, CCPA's definitions of personal information, or simply the reasonable expectations of people who sent a professional email to a co-founder depends on jurisdiction, the nature of the correspondence, and exactly how the data was processed. Wang didn't say. The audience didn't ask.

There is also a forward-looking question that nobody in the room raised: what happens to Jeffbot when Wang leaves Exa? The system has read and write access to every internal data source Wang can reach — which, as a co-founder, is everything. That access architecture presumably changes when his employment does. But the decisions Jeffbot encoded, the voice it learned, the evals it was calibrated against — that institutional memory doesn't dissolve with a departure. Who owns it? Who can audit it? Who decides whether it's retired or retrained?

The audit trail problem hiding inside "arbitrarily customizable"

Wang's third principle — that buy-versus-build is a false dichotomy — is where his argument is most commercially interesting and most legally underexamined. His position is that the right question isn't whether you purchase SaaS or build in-house; it's whether the system you're using is arbitrarily customizable. He cites Salesforce as an example: a good database with strong product decisions baked in, now exposed via MCP so Exa's agents can interact with it programmatically.

The economic logic is sound. The regulatory logic is more complicated. When your sales process runs through an AI agent stack that sits on a third-party MCP implementation, the audit trail for any given decision is distributed across your internal systems, your vendor's infrastructure, and the model provider's logs — assuming those logs exist and are accessible. In a regulatory inquiry — an FTC investigation into deceptive sales practices, a GDPR data subject access request triggered by something an AI drafted, an employment dispute over a deal that went wrong — "our agents ran on Salesforce MCP and we checked everything for correctness" is not a compliance posture. It's a description of a workflow.

The question of who owns the audit trail when AI agents mediate commercial decisions is one that existing regulatory frameworks have not answered cleanly. The EU AI Act's requirements for high-risk AI systems include obligations around record-keeping and human oversight, but enterprise sales automation occupies an ambiguous classification tier. The FTC has signaled interest in AI-enabled commercial practices, but its guidance remains general. Companies like Exa are making architectural choices right now that will determine whether they can reconstruct a decision trail two years from when a deal closed — or whether that trail is simply gone.

Two jobs, one person, and the accountability gap

The Forward Deployed Engineer model Wang described — where technical staff simultaneously run deals and build the systems that run deals — is his most organizationally significant innovation, and also his most legally interesting. Wang noted in the Q&A that the FDE role traces to Palantir's terminology, though in his telling, AI is what has made the compression of the two functions practically possible at scale. "Before," he said, "that was like two jobs, and now it's like one job."

That compression is efficient. It is also a compressed accountability chain. When an AI-assisted sales engineer makes a representation to a prospective customer — drafts an email through Jeffbot, pulls a recommendation from a Slack agent querying internal data — and that representation turns out to be wrong or misleading, the question of who bears liability is not straightforwardly answered by existing employment or contract law. Was the decision made by the FDE? By the agent? By the system the FDE built? By Wang's encoded judgment embedded in Jeffbot? The organizational chart says one person. The decision architecture says something more distributed.

Employment law in the United States has largely not caught up to the question of how liability is allocated when workers are acting partially through AI proxies they themselves configured. EU frameworks under the AI Act and the Platform Work Directive are beginning to grapple with algorithmic management, but B2B sales automation is not their primary target. For now, companies are making these choices in a legal vacuum and calling it agility.

Wang's talk is a competent, honest account of what Exa built and why it works for them. The engineering is coherent, the business logic is tight, and the presentation is refreshingly candid about what the team doesn't do well. What's missing — and what every company evaluating a similar stack should supply for itself — is a parallel accounting of what the system assumes: that the data feeding it was gathered with appropriate consent, that the vendors hosting it will preserve the records you'll need, and that when something goes wrong, there is an identifiable human being whose name goes on the answer.

Automating judgment and distributing accountability are two very different design choices. Right now, most AI-native GTM stacks are doing both simultaneously, and presenting it as one.

---

Samira Barnes covers technology policy and regulation for Buzzrag.