What does 'serialize writes' mean in practice?

The system processes writes to a given record one at a time in a defined order. Two agents' writes to the same record can't race each other and land in a random order. The database or the app makes that promise; the agents don't have to agree on it themselves.

Is designing agents 'per job, not per pipeline' just a naming convention?

No. It changes what scope each agent needs. An agent scoped to a pipeline tends to pick up broad rights over everything in it. An agent scoped to a job, like 'the one that drafts follow-ups' or 'the one that scores leads', has a narrower scope tied to what it does.

What is the actual failure when two agents have overlapping cleanup instructions?

The two agents undo each other's work. Each acts on its own idea of what counts as 'stale' and can undo or redo the other's changes forever. Neither knows the other exists or what it just did, so the loop never ends, unlike one agent making a mistake once.

Can two agents work the same pipeline?

Yes, if each has its own scope and the system orders writes and drops duplicate actions. If not, they collide: two follow-ups to one contact, two stage moves.

Want to see it first? Book a demo

app.salescrew.io/inbox

The unified reply inbox with classified threads

The short answer

Two agents can safely work the same pipeline if each has its own scope that doesn't overlap. The system must also process writes to a shared record one at a time and drop duplicate scheduled actions, so the same follow-up can't be queued twice.
Without those two protections, agents with overlapping responsibility collide. Two agents both deciding a contact needs a follow-up send two. Two agents both reasoning about a deal's stage move it in conflicting directions within the same day.
The fix is not fewer agents. It is scoping them by job rather than by pipeline. An agent that drafts follow-ups and an agent that scores leads can coexist on the same pipeline, because their jobs do not overlap even though the records do.
The worst case is two agents with the same loose instructions, like both being told to 'clean up stale records'. With nothing to keep them in step, they can undo and redo each other's changes forever. Neither knows the other exists.

Why collisions happen even when each agent is behaving correctly

It's tempting to assume a collision means one of the agents is broken. Usually neither is, because each agent, looking at the same record on its own, can reach a sound conclusion. This contact looks due for a follow-up. This deal looks ready to advance. The problem is not that either conclusion is wrong in isolation. Neither agent knows the other reached a similar conclusion at nearly the same time. Without a mechanism to prevent it, both act.

So this is a timing problem, not a reasoning problem, and it needs a timing fix. Ordering writes, so the system finishes one write to a record before it allows the next, closes the most direct version. Dropping duplicate scheduled actions closes a related one. If two agents both decide to schedule tomorrow's follow-up to the same contact, the system should spot the duplicate and send only one.

Collision, cause, and prevention

Collision	Cause	Prevention
Two follow-ups sent to one contact	Two agents independently decide a follow-up is due at nearly the same time	Deduplicate scheduled actions per contact before they execute
Conflicting stage moves on one deal	Two agents reasoning from different signals reach different conclusions	Serialize writes to deal records; keep stage changes in review regardless
Overlapping cleanup undoing itself	Two agents both told to 'clean up' with no shared definition of stale	Scope cleanup responsibility to one agent, or define the rule identically for both
Duplicate research or enrichment	Two agents both enrich the same record without checking recent activity	Check for a recent enrichment before running it again

Scoping by job, not by pipeline, as the actual design principle

If you run several agents on one pipeline, make sure their jobs don't overlap, even when the records they touch do. An agent that only drafts follow-ups and an agent that only scores leads can operate on the exact same deals without colliding. Neither one's job includes deciding what the other decides. The risk grows when two agents share a job, like both being asked to manage follow-up timing.

Disclosure: SalesCrew is our product, and its agents are scoped by job rather than by pipeline. The Inbox agent drafts replies, and the chief-of-staff digest writes summaries. Each one works inside its own job, not a broad mandate that overlaps another. Its guardrails keep at least 3 days between touches to one contact, and every external send waits in the review queue for a person to approve.

Two agents with overlapping 'clean up' instructions can loop forever

Without one clear, shared rule for what needs cleaning up, two agents each following their own reading can undo and redo each other's changes forever. Give cleanup to one agent, or write the rule once and use it for both.

Questions

What does 'serialize writes' mean in practice?: The system processes writes to a given record one at a time in a defined order. Two agents' writes to the same record can't race each other and land in a random order. The database or the app makes that promise; the agents don't have to agree on it themselves.
Is designing agents 'per job, not per pipeline' just a naming convention?: No. It changes what scope each agent needs. An agent scoped to a pipeline tends to pick up broad rights over everything in it. An agent scoped to a job, like 'the one that drafts follow-ups' or 'the one that scores leads', has a narrower scope tied to what it does.
What is the actual failure when two agents have overlapping cleanup instructions?: The two agents undo each other's work. Each acts on its own idea of what counts as 'stale' and can undo or redo the other's changes forever. Neither knows the other exists or what it just did, so the loop never ends, unlike one agent making a mistake once.