AI Outbound Task Completed: Verify the Business Actions Behind the Status
When an AI outbound task reports completion, compare the requested work with its returned artifacts and the current state of the systems it was allowed to change. Research results, enriched fields, message drafts, CRM updates, sequence enrollments, and sent emails are different outcomes. A finished agent run does not establish that all of them happened.
The practical question is: what can the team now rely on? Answer it for each requested action, using record identifiers and destination evidence where relevant. Then continue with the verified results, repair a specific gap, or leave the affected work on hold. The review method below is a proposed operating procedure, not a report of measured campaign performance.
What does a completed AI run actually establish?
It establishes something about the execution of that run. The meaning depends on the tool's status definition and the scope of the task. An agent asked to prepare research can finish successfully without touching the CRM. An agent asked to draft outreach can return useful copy while sending nothing. Judge completion against the actual request, including any limits the operator set.
Our engineering post on the Unify plugins for Claude and ChatGPT describes background agent work, progress checks, clarification, and results returned to the conversation. Results also link to a Unify thread that can be continued. That continuity helps an operator investigate a result; it is not evidence that a proposed campaign has executed.
In the Unify MCP tool reference, READY means a run finished successfully and its results can be read. ERROR also permits reading the terminal result to inspect the failure. The returned answer and structured content deserve their own review. Preserve the run and thread identifiers so a subsequent question refers to the correct work.
Start with the requested action, not the summary's confidence
Retrieve the original task and any later changes to scope. Identify the intended population, required output, destination, and stopping point. If the request was research-only, a missing enrollment is expected. If it required an authorized CRM update, a recommendation to update the CRM is still an unfinished action.
Write down what would count as completion before inspecting the result. For a research task, that may be a reviewable set of account findings with unresolved fields retained. For a field update, it is the intended value on the intended destination record. For sending, it requires evidence from the sending system, not merely a prepared message.
Keep task authorization distinct from evidence of execution. An action can be authorized but unverified, or verified but outside the requested scope. If the original task already authorized a specific action, do not manufacture an additional approval step. If the next action expands the scope, resolve that decision before proceeding.
| Requested action | Evidence to inspect | What it does not prove |
|---|---|---|
| Research accounts | Returned rows, matched account identity, supporting findings and unknowns | Contacts were enriched or outreach began |
| Enrich contacts | Intended person, returned field values, validation status and unresolved fields | The person is the buyer or the CRM was updated |
| Draft outreach | Actual recipient drafts and their reviewed version | An enrollment exists or email was sent |
| Change CRM records | Destination record ID, requested field and current value | A sequence was started |
| Enroll recipients | Person and sequence IDs, enrollment state and relevant steps | Every email has sent |
| Send outreach | Individual sending activity, recipient, message and recorded outcome | Delivery, reading or a qualified conversation |
Inspect the actual artifacts and reconcile the rows
Open the returned table, list, draft, or record reference. A prose answer can summarize an output without exposing its missing values or duplicates. The review should establish which artifact belongs to the run, whether the artifact is final, and whether the visible rows cover the requested population.
For Unify DataTables, the MCP reference documents pagination and an indicator of whether a job is still populating the table. A visible page is therefore not necessarily the complete result. Inspect the remaining pages and any active-job state before treating the displayed row count as a final total.
Reconcile identifiers rather than totals alone. The same total can conceal a missing requested account and an unintended replacement. Preserve the original input identifier alongside the returned record identifier, then classify each requested item as verified complete, intentionally excluded, failed, or unresolved. Those categories are a proposed worksheet convention, not product status names.
Keep the unit consistent. Company rows, people, email addresses, enrichments, enrollments, and messages are not interchangeable counts. A request to research companies can legitimately produce several contacts per company. Record that relationship before deciding whether there are too many or too few results.
Inspect exclusions individually enough to distinguish expected policy decisions from accidental omissions. A protected account should not be forced through merely to make a completion percentage look better. Equally, a missing row should not be reclassified as an exclusion without evidence that an exclusion was applied.
How do you verify an authorized CRM change?
Read the destination record using its stable identifier and compare the current field value with the requested value. Verify the person or company match first. A correct value on the wrong account is not a successful update. Check associations and ownership when those were part of the requested change.
Our CRM chat documentation distinguishes sending existing Unify records through integration matching and mappings from updating a CRM record directly. It also explains that ordinary create or update requests can execute directly when requested and enabled. Inspect the path actually used rather than assuming that all writes follow the same mapping rules.
For HubSpot, the bidirectional sync documentation identifies the Sync log as the place to inspect write results, the connection used, written values, and the HubSpot record ID. Use that evidence together with the destination record. A value in a local research table does not substitute for a confirmed CRM write.
Record the observation time. A later automation or another teammate may change a field after the agent writes it. If available history shows the requested write succeeded and was later replaced, investigate the competing process. Repeating the same write without understanding that process can create an avoidable loop.
Separate drafts, enrollments, completed steps, and sends
A sequence draft is an artifact to inspect. An enrollment is a person's participation in a sequence. A send is a particular message event. Keep these levels separate in both the audit and the completion summary, even when one conversation initiated several of them.
Our enrollment documentation explains that queued enrollments may be waiting for a first step, a send window, or mailbox capacity. A completed enrollment can have ended early after a reply or opt-out. Neither label by itself means every planned email was sent. Open the person's enrollment and its reason or next step.
If sending was requested, identify the relevant message and recipient, then review its recorded state. A queued message, a blocked step, and a recorded send need different follow-up. Do not infer delivery or engagement from the existence of an enrollment. If the task only requested drafts, stop at draft verification.
The sequence results guide describes individual email-step reporting for delivered, replied, opened, clicked, opted-out, bounced, and bounce-stopped outcomes. Use the level of detail appropriate to the question. Aggregate campaign results cannot identify which specific row from an agent task reached the intended state.
Also distinguish automated email steps from manual work. A created call or follow-up task establishes that work was assigned; it does not establish that a conversation occurred. Review the relevant activity and outcome when the task's scope calls for completed human follow-up.
What should you do with partial success?
Partition the result before retrying. Preserve verified successes, identify intentionally excluded records, and isolate unresolved or failed actions. The next operation should address the specific gap. Re-running the entire instruction can repeat writes or duplicate outreach preparation that already succeeded.
A missing acknowledgment is especially important to investigate. The destination may have accepted an action even if the originating process did not receive a usable response. Read the destination first. If the action already exists, reconcile its identifier with the original request instead of issuing another mutation immediately.
When a record cannot be inspected because of access, classify the outcome as unverified for that reviewer. Lack of access is not proof of failure or proof that no record exists. Ask the authorized owner to inspect it, or retain the unresolved status until sufficient evidence is available.
For a repair, state which records and fields are in scope and which verified results must be preserved. Recheck eligibility before any resumed outreach because customer status, ownership, opt-outs, or active conversations may have changed since the first run.
| Review field | Record from the actual task |
|---|---|
| Run and thread reference | ________ |
| Requested population and stopping point | ________ |
| Returned artifact and destination IDs | ________ |
| Verified complete items | ________ |
| Expected exclusions and their reasons | ________ |
| Failed or unresolved items and evidence | ________ |
| Specific next action and responsible owner | ________ |
Continue, repair, or hold the affected work
Continue when the evidence supports the next dependency. Reviewed research may be ready for contact selection even while unrelated CRM repair remains open. Do not block useful independent work unnecessarily, but do not let an unresolved prerequisite silently become a verified fact.
Repair when the failure is identified and the correction remains within the authorized task. Hold the affected action when identity, eligibility, destination state, or scope is unresolved. Describe the missing evidence precisely so the next operator can resolve it without restarting the entire investigation.
A completion note should state what was verified, what remains open, and what happens next. Include counts only after reconciling the underlying identifiers. Avoid a single overall Done label when it hides a mixture of prepared drafts, accepted writes, queued sends, and unresolved records.
Use this read-only review request in the existing conversation:
Compare this run with the original requested scope. Inspect its returned artifacts and the destination records you are authorized to read. Separate research, enrichment, drafts, CRM writes, enrollments, and sending outcomes. For each requested item, return its identifier, supporting result or destination reference, verified state, unresolved issue, and recommended next action. Do not repair records, enroll people, or send messages during this review.
For the earlier research and source-review stages, see the ChatGPT prospecting workflow. To put research and supported outbound actions in a connected conversation, try Unify and define the intended stopping point for your first task.
Frequently asked questions
Does READY mean an AI outbound campaign has sent?
No. In Unify MCP, READY means the agent run finished successfully and its results can be read. Confirm any requested enrollment or sending outcome in the relevant destination.
Should I retry the whole task after a partial failure?
First reconcile the completed and unresolved actions. Check destination state before retrying a mutation, then repair only the items that require it within the authorized scope.
Is an exported table proof that CRM records changed?
No. Inspect the requested destination records and fields. A table may contain research or proposed updates without any corresponding CRM write.
What if I cannot read the destination record?
Keep the outcome unverified and route the check to an authorized owner. An access limitation does not establish whether the business action succeeded or failed.
