By this point in the series, the replacement has an audited workflow, a resumable orchestrator, and evidence-first worker contracts. Those pieces can process a batch correctly. Production begins when the system can control live effects and explain the result after the operator closes the terminal.
This is Part 4 of the four-part implementation series. Start with the Part 1 workflow audit, build the Part 2 resumable orchestrator, and define Part 3 evidence-first worker contracts. The parent guide maps the full replacement.
Production is a control plane, not a bigger prompt
The worker says what it found. The orchestrator says which job runs next. The production control layer decides whether the system may spend money, change a destination, enroll a lead, send a message, or continue after a policy threshold is crossed.
Keep that authority outside the prompt. A model should not be able to grant itself a larger budget, reinterpret a review hold as approval, broaden its own credentials, or decide that a partial write is good enough.
The control plane owns:
- Run manifests, approvals, write scopes, and destination allowlists.
- Budgets, concurrency limits, circuit breakers, and stop controls.
- Trace identity, metrics, structured logs, alerts, and incident evidence.
- Error queues, review holds, delivery snapshots, and reconciliation.
- Rollback, compensating actions, and bounded replay.
Separate readiness, approval, execution, and delivery
A single `done` flag collapses decisions that must stay independent. Use explicit states with guarded transitions.
DRAFT -> QA_PASSED -> APPROVAL_PENDING -> APPROVED -> EXECUTING -> WRITE_ACKNOWLEDGED -> READBACK_VERIFIED -> DELIVERED Any state may route to: HOLD_POLICY HOLD_REVIEW FAILED_RETRYABLE FAILED_PERMANENT RECONCILIATION_REQUIRED ROLLBACK_REQUIRED
`QA_PASSED` means the artifact meets its tests. It does not mean a person approved a CRM write or campaign enrollment. `WRITE_ACKNOWLEDGED` means the destination returned a response. It does not mean the intended record exists with the intended fields. Only `READBACK_VERIFIED` closes that gap.
Freeze an immutable launch manifest
The approval must point to an exact artifact. If the rows, copy, workflow, destination, or budget changes after approval, the system needs a new manifest and a new approval decision.
{
"run_id": "run-2026-07-16-004",
"workflow_version": "clay-replacement-v4",
"input_sha256": "...",
"approved_rows_sha256": "...",
"approved_row_count": 10,
"approval": {
"actor_id": "operator-01",
"approved_at": "2026-07-16T11:00:00Z",
"effect_classes": ["CRM_APPEND"],
"expires_at": "2026-07-17T11:00:00Z"
},
"destinations": ["crm:creator-intake"],
"write_cap": 10,
"provider_call_cap": 0,
"model_cost_cap_usd": 2.00,
"send_cap": 0,
"kill_switch": "run-2026-07-16-004.stop"
}
The manifest should be append-only once execution begins. Store amendments as new records, never as silent edits to the approved scope.
Approve effect classes, not vague projects
"Proceed with the campaign" is too broad for a machine. Define effect classes and approval owners:
Approval for `CRM_APPEND` does not imply approval for `CAMPAIGN_ENROLL` or `SEND_MESSAGE`. A successful run does not enlarge the next run's authority.
Default to previews and dry runs
Every live workflow should be able to produce the complete intended effect set without executing it. A useful preview contains:
- Stable row IDs and the proposed operation for each row.
- Before and after values for every destination field.
- The exact campaign, list, CRM object, sender, and schedule identifiers.
- Provider, model, write, and send cost estimates.
- Rows that would be held, rejected, or escalated.
- A digest that can be hashed and approved as the launch manifest.
Dry-run success proves the plan is internally coherent. It does not prove the live destination will accept it, which is why the readback stage remains mandatory.
Grant least privilege per step
A research worker does not need campaign-write credentials. A CRM writer does not need access to the full filesystem. A read-only monitor does not need the ability to stop or resume a campaign.
OpenAI's current Codex permissions documentation describes profiles that combine filesystem and network rules. The built-in profiles distinguish read-only, workspace write, and unrestricted access. Custom profiles can restrict writes to selected roots, deny matching secret files, and allowlist network domains. The practical lesson is to create one permission profile per effect class, not one powerful profile for the entire pipeline.
default_permissions = "delivery-preview" [permissions.delivery-preview] extends = ":read-only" [permissions.delivery-preview.network] enabled = true [permissions.delivery-preview.network.domains] "api.approved-crm.example" = "allow" "*" = "deny"
OpenAI also documents `workspace-write` with `on-request` approval as a lower-risk local automation posture. Use narrow rules for specific exceptions instead of removing the sandbox for convenience.
Make budgets executable
A budget in a spreadsheet is a forecast. A production budget is a check before every consequential call. Track at least:
- Maximum model input, output, and tool cost per row and run.
- Maximum provider calls, credits, retries, and duplicate attempts.
- Maximum destination writes, enrollments, and sends.
- Maximum allowed error, conflict, and review-hold rates.
- Maximum wall time and unresolved queue depth.
Stop new dispatch before a cap is crossed. Do not finish the current batch merely because most of it already ran. OpenAI's organization Usage API can group model activity by project, user, API key, model, batch, and service tier; its separate Costs endpoint can group billed spend by project and line item. Keep your real-time run ledger for immediate circuit breaking, then reconcile it to the provider's financial source.
Instrument one trace across the whole row
Every log, metric, and trace span should carry stable `run_id`, `row_id`, `step_id`, `attempt_id`, and destination identity. Then one row can be followed from source retrieval through model decision, approval, write, and readback.
OpenTelemetry separates observability into signals such as traces, metrics, and logs. Use them together:
- Trace. One causal path through worker calls, providers, database state, and destination operations.
- Metrics. Aggregate rates, latency, queue depth, spend, acceptance, holds, and reconciliation gaps.
- Logs. Discrete structured events with typed status, policy decision, hashes, and remote identifiers.
Google's SRE guidance names latency, traffic, errors, and saturation as four core monitoring signals. For outbound automation, map them to step duration, rows or effects per period, technical and policy failures, and queue or provider capacity. A destination can return HTTP 200 and still be wrong, so count incorrect content and policy violations as errors too.
Give every exception a queue and an owner
Do not bury unresolved rows in logs. Create separate queues for:
- Evidence conflicts and unsupported claims.
- Approval pending or approval expired.
- Provider timeouts, rate limits, and exhausted retries.
- Destination rejections, missing records, and schema drift.
- Ambiguous side effects that require remote readback.
- Compliance, suppression, sender-health, or schedule holds.
Each queue needs a definition of done, an owner, an age threshold, and a permitted next action. A human review is a state transition with evidence, not a comment pasted into a sheet.
Treat destination readback as part of the write
A provider response may confirm that it received the request. Production proof asks the destination what exists afterward.
- Write with a stable effect key and preserve the remote request ID.
- Read back by destination ID or stable business key.
- Verify required field values, campaign or list membership, sender, schedule, and active state.
- Compare the readback to the immutable manifest.
- Store the accepted remote identity and readback hash.
A real internal operating checkpoint illustrates the difference. One bounded cohort produced 8 added destination records, 1 updated record, and 0 failed writes. The follow-up readback then found 9 list records, 9 campaign records, and 0 missing required custom fields. A separate CRM lifecycle write reported 9 records written. The useful production fact is not merely that the calls returned successfully. It is that the destination counts and required fields agreed afterward.
Reconcile every row before delivery
The final equation should be explicit:
expected_rows = approved_rows = attempted_writes + not_attempted_holds = accepted_writes + rejected_writes + ambiguous_writes + holds readback_expected = readback_found + readback_missing delivery_complete only when: missing = 0 unexpected_extra = 0 duplicate_effects = 0 unresolved_ambiguous = 0
Keep accepted, rejected, held, and missing counts separate. Never make the numbers balance by dropping a category.
Preserve one immutable delivery snapshot
A completed run should produce a read-only package that another operator can audit without the original process:
- Launch manifest, approval record, and input hashes.
- Accepted worker results and evidence references.
- Effect ledger with attempt, request, response, cost, and remote IDs.
- Destination readback with required-field checks.
- Expected, accepted, rejected, held, missing, extra, and duplicate counts.
- Final error queues, unresolved exceptions, and operator decisions.
- Artifact hashes and the software or workflow versions that produced them.
The mutable CRM remains the operating surface. The immutable snapshot proves what this run delivered at this point in time.
A real approval gate: 100 staged, 10 written, 90 held
In one internal approval-batch workflow, 100 unique records were staged, personalized, and deterministically validated. The operator explicitly approved only the first batch of 10 for CRM append. The system wrote those 10, read back the exact destination range, kept the remaining 90 on hold, left outreach dates blank, and sent no outreach.
Design stop, rollback, and replay before launch
The incident procedure should be executable without inventing policy under pressure:
- Stop dispatch. Activate the run kill switch and prevent new effects.
- Preserve evidence. Snapshot state, logs, manifests, approvals, remote IDs, and unresolved leases.
- Read back. Determine what the destination actually accepted before retrying or undoing anything.
- Contain. Pause future sends, revoke the narrow writer credential, or move affected records to a suppression state.
- Compensate. Reverse only effects that are both reversible and covered by an approved rollback rule.
- Reconcile. Account for every approved effect and every remote record.
- Replay. Create a new bounded manifest for unresolved work. Do not reset the old run and hope.
Deleting remote records is not a universal rollback. It may erase audit history, replies, ownership, or valid changes made after the run. Prefer pause, suppress, annotate, or compensate according to the destination's semantics.
Launch in evidence-producing stages
- Fixture test. Run positive and negative contract cases without external writes.
- Shadow run. Read live inputs and render intended effects with all writers disabled.
- Approved pilot. Execute a small exact manifest under low write and spend caps.
- Readback gate. Verify destination IDs, required fields, counts, and downstream state.
- Controlled scale. Raise one cap at a time while watching latency, errors, saturation, cost, and review queues.
- Steady operation. Keep recurring reconciliation, incident drills, credential review, and regression fixtures.
A pilot is not just a small campaign. It is a test designed to produce enough evidence to justify the next limit.
Definition of done for Part 4
- Readiness, approval, execution, write acknowledgement, readback, and delivery are separate states.
- Every live run points to one immutable approved manifest.
- Credentials and network access are limited to the effect class and destination.
- Model, provider, write, send, time, and queue budgets stop work before caps are crossed.
- Traces, metrics, and structured logs share stable run and row identity.
- Every exception has a typed queue, owner, age threshold, and permitted next action.
- Destination readback verifies remote IDs, required fields, and active state.
- Final reconciliation accounts for every approved row and effect.
- An immutable delivery snapshot can be audited without the original process.
- The stop, containment, compensation, and replay procedure has been tested.
The complete Clay replacement stack
The four parts now fit together:
- Audit the workflow. Preserve the real trigger, logic, cost, failure, approval, evidence, and delivery contracts.
- Build the orchestrator. Give every job stable identity, bounded execution, checkpoints, idempotency, and recovery.
- Write worker contracts. Require strict schemas, allowed evidence, provenance, typed uncertainty, and fail-closed results.
- Operate the control layer. Enforce approval, permissions, budgets, observability, readback, reconciliation, and incident recovery.
That is the difference between replacing a Clay table and owning the outbound system around it.
Frequently asked questions
How much is a Clay subscription?
Clay's plans, credits, and prices can change, so use its official pricing page for the current numbers. Compare the full operating cost: subscription, data and action credits, models, providers, engineering, monitoring, review, and incident handling.
Is Clay better than Apollo?
They solve overlapping but different problems. Apollo is primarily a prospecting and sales-engagement platform, while Clay is built around flexible enrichment and workflow tables. A Codex control layer can orchestrate either provider, but it does not remove the need to choose reliable data and sending systems.
Who are Clay's competitors?
The relevant alternative depends on the job: prospect databases, enrichment waterfalls, intent tools, CRM automation, sequencers, or a custom orchestrator. Define the workflow contract first, then compare products against the steps you actually need.
What is an AI outbound production control layer?
It is the system around workers and tools that governs approval, permission, budgets, telemetry, exception queues, destination verification, reconciliation, and incident recovery.
How do I stop an agent from sending unapproved messages?
Keep send credentials outside research and writing workers. Require a signed or recorded approval for an exact manifest, enforce a send cap, allowlist the campaign and sender, and block the transition to live execution unless every approval field is valid.
Does a successful CRM API response prove the record was delivered?
No. Read the record back by remote ID or stable business key and verify the required fields, associations, ownership, and active state. Then reconcile the destination result to the approved manifest.
What should I monitor in a Codex outbound system?
Monitor step latency, row and effect traffic, technical and policy errors, queue saturation, provider and model cost, approval age, destination acceptance, missing records, duplicate effects, and reply or suppression state where sending is involved.
Can I roll back an automated outbound run?
Some effects can be reversed, while others require compensation. Pause future actions first, preserve evidence, read back destination state, and apply the destination-specific rollback rule. Never delete blindly or rerun the whole batch.
If you want something like this done for yourself for your outbound system, you can always use us.
