Give Headless Email Campaigns One Writer at a Time

Migma can be operated from its interface, an SDK application, and a connected agent. When two authorized controllers can change the same campaign, assign one writer at a time and make ownership transfer explicit. Permissions answer whether an actor may act; an ownership record answers whether it should act now.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 10, 2026.

Migma’s MCP documentation describes agent access to drafts, campaigns, exports, and results. Its campaign API exposes identifiers, status, scheduling information, and update timestamps. Those surfaces make a shared operational record useful, but the reviewed documentation does not establish atomic locking between an application and every other editor.

The failure starts with two reasonable instructions#

Consider a fictional equipment supplier. A scheduled agent has instructions to prepare tomorrow’s maintenance newsletter. A marketer opens the same campaign and asks an interactive agent to replace the featured guide. Both have appropriate access. Each reads the original state, makes a valid change, and reports success.

The last write may leave only one change visible. A more subtle outcome is a campaign whose email, subject, and schedule each came from a different controller. Neither actor intended that combination. Repeating the requests with the same retry keys would not fix the ownership conflict: these are separate, legitimate operations.

The practical response is a single writer for the campaign object, with other actors submitting change proposals. Creative work on an independent draft can continue. The moment a proposal changes what the campaign will send, it enters the campaign’s ownership protocol.

Keep an ownership record outside the chat#

Use a durable application record keyed by the destination account and campaign ID. The following fields are a proposed application design, not Migma API parameters:

resource: account-demo / campaign-maintenance
owner: scheduled-preparation-worker
ownership_epoch: 18
purpose: replace reviewed creative for September newsletter
expires_at: explicit UTC instant
expected_email: email-demo-4
expected_campaign_status: draft
last_reconciled_at: explicit UTC instant
handoff_state: active

An ownership epoch is an increasing number assigned by your coordination system. It lets the system reject a delayed instruction from an older ownership period. A timestamp alone is weaker because two actors can hold different assumptions about when a lease expired.

Acquire and renew ownership through a storage operation that your application can enforce atomically. Do not implement it as “read an unlocked flag, then write my name”: two workers can read that flag together. Route all participating automation writes through the same enforcement point. If the Migma interface or another integration can bypass it, document that boundary and use an operational editing window or pause those controllers. An external lock cannot magically constrain a tool that never checks it.

Transfer responsibility with a fresh read#

The outgoing owner should stop issuing writes, resolve any in-flight request, and record the final campaign and email identifiers. The incoming owner then reads the campaign again and compares the current state with the handoff record. Do not accept the previous owner’s summary as the current platform state.

There are three useful outcomes:

• Match: the incoming owner can proceed within its assigned purpose.
• Known change: a named human or controller explains the difference; update the proposal and review the resulting combination.
• Unexplained difference: stop mutations and reconcile ownership before continuing.

The SDK’s campaign methods provide documented ways to retrieve and operate on campaigns. The coordination policy belongs in your application. Do not invent an If-Match header, revision precondition, or lock endpoint without verifying that the specific API supports it.

Rehearse an interleaving, not just a happy path#

Use a disposable campaign with no live recipient action. Have controller A read the draft and pause. Transfer ownership to B; let B prepare its change. Then resume A’s delayed operation.

Your coordination system should reject A before it reaches the mutation call. Retain the two ownership epochs, attempted action, rejection reason, and the final read of the campaign. If A can still write, the ownership boundary is incomplete even if the final email happens to look correct.

Repeat with an expired lease whose previous request is still running. Expiry should trigger reconciliation, not immediate confidence that the old actor stopped. A lease timeout is a statement about your coordinator’s willingness to wait; it is not proof that an external request has been cancelled.

The release decision#

For the equipment supplier, the scheduled worker can finish its draft proposal and relinquish campaign ownership. The marketer reviews the replacement guide, assumes ownership, selects the exact email, and checks the resulting subject and schedule together. One actor then performs the authorized final transition.

Keep version-bound approval and API retry safety as separate controls. This protocol addresses concurrent authorized writers. It does not establish product-level atomicity, cancel an email already in delivery, or verify that a campaign is otherwise ready to send.