{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/headless-email-campaign-single-writer","id":"headless-email-campaign-single-writer","slug":"headless-email-campaign-single-writer","title":"Give Headless Email Campaigns One Writer at a Time","description":"Prevent a scheduler and an interactive agent from overwriting the same campaign by assigning a single writer and reconciling handoffs.","dek":"An application-side ownership protocol for a Migma campaign controlled from more than one surface.","category":"Email Operations","topics":["Migma","email marketing","Ownership record"],"publishedAt":"2026-09-10","updatedAt":"2026-09-14","lastVerifiedAt":"2026-09-14","readingMinutes":5,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma: MCP Server","url":"https://docs.migma.ai/mcp-server?utm_source=marketingwiki&utm_medium=referral&utm_campaign=headless-email-campaign-single-writer"},{"title":"Migma: List Campaigns API","url":"https://docs.migma.ai/api-reference/campaigns?utm_source=marketingwiki&utm_medium=referral&utm_campaign=headless-email-campaign-single-writer"},{"title":"Migma: Node.js SDK","url":"https://docs.migma.ai/sdk?utm_source=marketingwiki&utm_medium=referral&utm_campaign=headless-email-campaign-single-writer"}],"wordCount":818,"body":"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**.\n\n> **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.\n\n[Migma’s MCP documentation](https://docs.migma.ai/mcp-server?utm_source=marketingwiki&utm_medium=referral&utm_campaign=headless-email-campaign-single-writer) describes agent access to drafts, campaigns, exports, and results. Its [campaign API](https://docs.migma.ai/api-reference/campaigns?utm_source=marketingwiki&utm_medium=referral&utm_campaign=headless-email-campaign-single-writer) 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.\n\n## The failure starts with two reasonable instructions\n\nConsider 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.\n\nThe 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.\n\nThe 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.\n\n## Keep an ownership record outside the chat\n\nUse a durable application record keyed by the destination account and campaign ID. The following fields are a proposed application design, not Migma API parameters:\n\n```text\nresource: account-demo / campaign-maintenance\nowner: scheduled-preparation-worker\nownership_epoch: 18\npurpose: replace reviewed creative for September newsletter\nexpires_at: explicit UTC instant\nexpected_email: email-demo-4\nexpected_campaign_status: draft\nlast_reconciled_at: explicit UTC instant\nhandoff_state: active\n```\n\nAn 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.\n\nAcquire 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.\n\n## Transfer responsibility with a fresh read\n\nThe 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.\n\nThere are three useful outcomes:\n\n- **Match:** the incoming owner can proceed within its assigned purpose.\n- **Known change:** a named human or controller explains the difference; update the proposal and review the resulting combination.\n- **Unexplained difference:** stop mutations and reconcile ownership before continuing.\n\nThe [SDK’s campaign methods](https://docs.migma.ai/sdk?utm_source=marketingwiki&utm_medium=referral&utm_campaign=headless-email-campaign-single-writer) 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.\n\n## Rehearse an interleaving, not just a happy path\n\nUse 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.\n\nYour 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.\n\nRepeat 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.\n\n## The release decision\n\nFor 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.\n\nKeep [version-bound approval](/articles/ai-email-collaboration-version-control) and [API retry safety](/articles/email-api-retry-idempotency-contract) 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."}