The autonomous rep was the wrong abstraction

The mistake we made

The autonomous sales agent was the wrong abstraction. We treated judgment like a sequence of activities, when judgment depends on context, timing, and a human decision about what should happen next.

We sold one. That matters.

It would be easy to describe the original idea as obviously flawed and pretend we saw the problem from the start. We didn't. The premise sounded reasonable: give a system access to the data, inbox, calendar, campaign controls, and surrounding workflow. Let it operate the sales process.

The problem wasn't that the system lacked enough actions. It was that we had made the rep the unit of automation.

A rep doesn't simply execute a long chain of independent tasks. They decide whether a company is worth pursuing, which fact should shape the angle, whether a reply contains buying intent, whether a meeting request is premature, and whether a campaign is saying something defensible.

Those decisions change the meaning of the next action.

Activity decomposes cleanly. Judgment doesn't.

The short answer is this: an autonomous sales agent should prepare and coordinate sales work, but a person should still own the consequential decisions. The useful unit of automation isn't the rep. It's the decision.

Where the activity model breaks

Suppose a system finds a lead, enriches the record, drafts an email, sends it, reads the reply, books a meeting, and updates the pipeline. On a diagram, that looks like a process.

In practice, every step changes the conditions around the next one.

A new piece of research may make the original angle irrelevant. A reply that looks positive may actually be a request for information. A calendar opening may not mean the prospect is ready to meet. A campaign with strong opens may still be attracting the wrong people.

The system has to interpret those signals against the company's targeting, the user's preferences, and the history of the account. That's the work. Moving information between boxes is the easy part.

Take a 38-person cybersecurity company selling to banks. The trigger is a new compliance rule that comes into force in three months. A system can find security leaders at regional banks and draft a message about the rule. But it can't safely infer the company's angle from the trigger alone.

Does the team want to sell a compliance audit? A monitoring product? A short diagnostic that creates pipeline for the services group? Those are different offers, aimed at different people, with different claims. The same trigger doesn't answer the question.

The rep may also know that the company just lost a deal after sounding too alarmist. Or that the founder wants to avoid mentioning the regulation until a prospect raises it. That context changes the message.

More tools don't solve this. They make the system better at acting while leaving the important question unanswered: should it act, and what should it say?

That's how automation becomes expensive. It doesn't fail because it can't send an email. It fails because it sends the wrong email with enough confidence to make the mistake hard to unwind.

The unit of automation should be the decision

We now think of the product as an assistant at each step, not a replacement for the rep.

That sounds like a smaller ambition. It isn't. It puts the boundary in the right place.

The assistant should gather context, prepare work, notice changes, and present a decision in a form the rep can review. The rep should set the angle, approve consequential actions, and remain responsible for judgment the system can't safely infer.

My view is that sales teams get this wrong when they measure autonomy by the number of actions a system can take. That's a bad measure. A system that sends 500 messages without asking is not necessarily more useful than one that prepares 500 good drafts and stops before the first send.

The difference shows up in the product architecture.

The assistant has 102 tools available across campaigns, leads, email, research, calendar, infrastructure, discovery, pipeline, targeting, and reporting. But tool access isn't permission to act. It's the ability to prepare the next useful step.

There are also 13 reactive skills working in the background. They draft replies, triage the inbox, find leads, book meetings, and read A/B results. These skills respond to events and reduce the monitoring a rep has to do. They don't turn every event into an irreversible action.

Autopilot makes the boundary obvious. It can turn a filter into a full draft campaign. Then it stops.

That stop isn't a missing feature. It's the point. A filter can identify a group of people. It can't decide the angle that should be used to address them. Someone who understands the company's priorities has to make that call and stand behind the message.

Guardrails aren't decoration

Approval queues are often described as safety features wrapped around an autonomous system. That framing misses their actual role.

Guardrails and consent checks are part of the reasoning. They determine when the system has enough authority to proceed and when it needs the user.

Anything consequential is gated. The system asks before it acts when a mistake could change an external relationship, commit the user to a position, or create a message that can't be taken back.

The goal isn't to slow everything down. Drafting an internal response and sending a message to a prospect aren't the same event. Finding a possible lead and adding that person to an active campaign aren't the same event. Reading an A/B result and changing the campaign based on it aren't the same event.

A useful assistant respects those differences.

It can collect company details, compare account records, suggest a reply, or flag that a campaign is attracting the wrong job titles without interrupting the rep every thirty seconds. But when it is about to contact someone, change targeting, or make a claim on the company's behalf, the boundary should be visible.

If the user has to approve every tiny preparation step, the system becomes annoying. If the system can cross every external boundary on its own, it becomes untrustworthy. The product has to distinguish the two.

Memory helps, but it doesn't decide

An assistant that starts cold each session forces the user to repeat the same context. That turns every interaction into setup work and makes the system appear less capable than it is.

The assistant carries memory of the company, the targeting, the organization, and the individual user. That memory gives recommendations and drafts a working context. It can understand that a particular audience matters, that an organization has a specific structure, and that the user has preferences for how work should be prepared.

Memory still isn't judgment. It gives judgment better material.

A system can remember the company's positioning and still need the rep to choose the campaign angle. It can understand the target organization and still need approval before changing the relationship with an individual. Context improves the recommendation. It doesn't remove accountability.

This is also where bad memory creates a different problem. If the system remembers an old positioning statement, a closed initiative, or a preference that belonged to a previous operator, it can produce work that looks informed but is wrong. The user needs a way to see which context shaped the recommendation, not just a polished answer.

What changed

The phrase autonomous sales agent suggests that the endpoint is a digital rep that owns the whole motion. We don't think that's the right design target anymore.

The useful system is closer to a colleague who is always present, knows the account history, watches the work, prepares the next move, and asks before crossing a consequential boundary. It should be active without pretending to be authoritative.

That distinction changes what gets automated, what gets reviewed, and where the product has to preserve human intent.

We built the first idea around replacing the rep's activity. Now we build around extending the rep's judgment with context, preparation, and timely assistance.

The former asks a machine to decide what matters. The latter helps a person decide faster, with better evidence, and without making them reconstruct the entire account every time they open the system.