Skip to main content
Use AgentLinkOps with your existing CRM and email sender to prepare a qualified campaign, then check claimed placements. Your agent keeps the audience judgment and drafts. Your CRM keeps relationships; your sender keeps delivery, replies and suppression records. This guide follows the local toolkit’s qualified-campaign-handoff and placement-reconciliation recipes, version 1.0.4, reviewed September 14, 2026. The examples use fictional records. No CRM or sender connection has been tested for this guide. Check capability status for hosted operations.

Choose the task and the records

Give your agent the asset URL and publication state, audience, supplied publisher pages, campaign purpose and outreach constraints. Choose where to keep the handoff: an existing CRM, a file or a shared document. A ledger and SQLite CRM are optional. If you have the supplied toolkit with the linktrail-setup skill, ask:
With an authorized checkout or supplied package, preview setup from your chosen working directory:
Replace /path/to/linktrail with your package location. This command writes nothing and connects no accounts. It inspects known local path metadata; it does not read your records or verify credentials. A plan is a starting checklist. If your package lacks this command, use the recipe directly. See CLI access. Supplied-input preparation needs no AgentLinkOps account. Fresh checks need page access. Hosted operations need the selected tool, account permission and available service access; installing a skill grants none of these.

Qualify before handing off

Inspect each exact publisher page and record the relevant context, retrieval date and evidence limits. A domain alone cannot establish a relevant page. Keep eligible, rejected and unresolved candidates separate, with reasons. The campaign workflow covers audience fit and published contact routes. Check current reply and suppression records in the chosen sender. If access is missing, leave the handoff unready for sending. Do not guess contact addresses or claim deliverability from an address found on a page. Run the site’s content workflow on each draft, including source review, a separate humanizing pass and the final review. A draft cannot claim that you inspected a page, own an asset or represent its author unless the evidence supports that sentence.

Map a portable handoff

Use stable record references and preserve existing external IDs. The labels below describe a handoff document; they are not vendor field names or an import schema. Before writing to a CRM or sender, inspect its actual field schema and lookup behavior. Preview the selected rows, field mapping and intended changes. A CSV export, an agent’s vendor connection and a hosted AgentLinkOps command are separate surfaces. This guide supplies no native sender connector or vendor-specific import command. If authorized to save a draft, keep the operation receipt and read the destination afterward. Follow all cursor pages needed to find the selected IDs. Compare returned fields with the intended draft revision. Record accepted, rejected and unchanged rows separately. A successful command or zero-change receipt alone does not prove the draft exists there. If access is unavailable, save the portable document with its actual state and next action. The useful result is the qualified evidence and reviewed draft; destination access can follow later.

Reconcile a claimed placement

When the sender or publisher reports a placement, obtain its exact source page and expected destination. A reply alone supplies no link observation. For a supplied URL pair, the local CLI can check without an account or ledger:
The .example URLs are placeholders. Replace them with the actual pair before running. The check fetches the source page, so it needs network access. Read the structured observation, reason, method and timestamp. An incomplete check remains unknown; a single-check exit zero means a result returned. See check a placement and evidence states. Update the selected CRM record or companion document with that observation after any required write authorization. Read it back before calling the update complete. Preserve draft revision, delivery and reply facts separately. Keep a historical observation with its original timestamp even if a later check is unknown. For an existing ledger, preview optional monitoring uploads:
This preview makes no network request. It previews ledger uploads, not CRM writes. Continue through sync and export only when you want hosted history or monitoring and have the required connection.

Resume without duplicating records

If a write times out, record outcome unknown with the original operation identifier. Read that operation, then read the destination again. Preserve the receipt and later field comparison separately. Do not create a fresh record to bypass an ambiguous result. A failed operation may have partial effects. An empty lookup does not prove that nothing was saved. Keep unresolved fields unknown, retain the intended revision, and record the next permitted recovery step. Use not attempted only when no write occurred. Restored access permits another read; it does not prove the earlier write failed.