The harness: the same webhook twice does nothing twice

A reliable AI sales agent is a compiled graph, not a long prompt: typed steps, a fixed list of tools, one pause where a person decides, writes that are safe to repeat, a checkpoint after every step, and a CRM login that cannot touch stage, dates or amount. The interesting engineering is the boundary around the model, and knowing which steps should stop being agents at all. This part is for the head of sales whose CTO asks how it actually runs.

What is the harness connected to?

In the Lost Star build the graph is LangGraph and the model steps run through Claude Code. The names matter less than the shape. A compiled state graph means every step is a node with typed inputs and outputs, and the edges between them are conditions written in code: if an extraction comes back below its confidence threshold, the next node is the rep's review queue, not the CRM. The tool list is fixed when the graph is compiled. The node that extracts signals from a call cannot call the email tool, and the node that drafts the recap cannot call the CRM write.

What does "the same webhook twice does nothing twice" mean?

The run starts when the recorder says a recording is ready, usually through a webhook. Webhook senders retry when they do not get a quick answer, so the same event can arrive twice. Without protection, the Northwind call from part 1 produces eight open issues instead of four, two recap drafts, and two notes on the deal.

The fix is to make every write idempotent: keyed on the run, the tool and the target record. Before a write, the harness checks the key. If it already exists, it returns the earlier result instead of writing again. A redelivered event re-runs the graph and lands on the same four issues in the open-issue ledger, not eight. Reps stop trusting a ledger the first time it doubles.

What happens when a run fails halfway?

It picks up where it stopped. LangGraph's checkpointer saves a snapshot of the graph's state at each step, and its documentation describes the recovery directly: if a node fails, you restart from the last successful step, and writes from nodes that already finished in that step are not run again.

In practice, a timeout on the price book call does not re-extract the recording or re-draft the recap that is already written. That matters for two reasons. The model steps are the slow and expensive part, so re-running them because one API blinked is waste. And a re-drafted recap can come out different from the one the rep already read, which is worse than waste.

Where does a person decide?

At one interrupt. LangGraph's interrupts pause the graph at a chosen point, save its state, and wait, indefinitely if need be, until the run is resumed with outside input. In this harness the interrupt sits at the approval step. The drafted record waits in review. When the rep approves, edits or rejects each field, the graph resumes with that decision and only then writes.

That is the difference between a promise and a structure. A sentence in a prompt asking the model to wait for approval can be ignored. A node the graph cannot route around cannot.

How is the boundary enforced, not promised?

Part 1 said the agent's CRM login cannot write stage, dates or amount. How that is enforced depends on the CRM, and the difference is worth knowing before you sign anything.

In Salesforce it is a permission. Field permissions control whether a user can see and edit a particular field. The agent signs in as its own integration user, and that user's permission set denies edit on stage, close date and amount. The runtime could not move them if the prompt told it to.

In HubSpot it has to live one layer up. HubSpot's property restrictions are an Enterprise feature, and HubSpot's own documentation says users can still set restricted properties through the API and that restrictions should not be used as a security measure. So on HubSpot the write tool carries the boundary: it accepts an allow-list of evidence properties, has no parameter for deal stage, close date or amount, rejects anything else before the API call, and logs every write with its run. That is code, not a CRM permission, which is why the log is how you audit it.

Which steps should stop being agents?

An agent is how you find the shape of a job. It is an expensive way to keep running one. The same seven steps, today and at fifty times the volume:

A step graduates the moment its output schema stops changing. The agent is how you find that schema, not how you run it forever. Four account executives might record two hundred calls a month, an illustrative figure; fifty times that is ten thousand. At ten thousand calls a month, paying a model to ask whether a deal has gone quiet is a bill, not an architecture. The first three rows are language problems and stay agents. The last four are schema problems wearing a language problem's clothes.

The outbound series draws the same line from the other side: automate the known, escalate the consequential. A known event with an approved action belongs in a job. An ambiguous one belongs in front of a person.

Next in the series

Part 12, What to measure, and what the published numbers already say, covers how you would know any of this worked: the industry figures worth quoting with their weaknesses, two worth refusing, and the measures to baseline before anything ships.