Benchmark external-agent work by verified write-back

External assistants can now participate in revenue work that once required direct use of a prospecting, engagement, collaboration or support platform. Product capability does not by itself establish operational reliability. A useful benchmark should measure whether a defined request produced the intended state in the authoritative system and whether another operator can explain the path from permission to outcome.

This protocol is a local benchmark, not an industry claim. It does not assume that one platform is more reliable than another, and it must not be used to fabricate a market average. Teams should publish their own sample, definitions, account configuration and observation window so later runs are comparable.

Define the action population

Start with consequential action classes that the tested workspace can actually perform. Apollo's Claude connector documentation provides a practical set: prospect search, enrichment, contact create or update, one-off email drafting or sending, sequence creation or variant work, adding contacts to sequences, task management and team-performance analysis. Do not test undocumented actions or generalize beta behavior beyond the verified account.

Create separate populations for read, propose and execute. A search result is not equivalent to a CRM write, and a drafted email is not equivalent to a sent email. Stratify customer-facing and bulk actions because their recovery characteristics differ. Record plan, permissions, credit state, connector version and feature availability at the start of the run.

Freeze a representative sample

Select records across normal and difficult cases: complete and sparse profiles, existing and new contacts, clear and ambiguous ownership, eligible and suppressed recipients, sufficient and near-limit credits, and permitted and denied actions. Preserve stable source IDs and a snapshot time. Exclude real customer communication unless the organization has approved a production test design.

Publish the sample size for every action class. Small samples can reveal control failures but should not be presented as stable rates. Keep failed and excluded cases in the denominator defined before execution. Changing the denominator after results arrive destroys the value of a benchmark.

Capture the authority packet

For each request, record the human initiator, external workspace, connected tenant, effective role, relevant object or field permission, commercial limit and any manual approval. The benchmark should mark a packet complete only when the evidence was available at execution time. Reconstructing permissions later may explain an incident, but it does not prove the workflow exposed its boundary to the operator.

Add an authority mismatch test. Attempt a harmless protected action with a user who should be denied, in a safe test context. A correct denial counts as a control pass. Never widen a role solely to make the benchmark succeed, and never run an unapproved customer-facing negative test.

Verify the write-back

Define the expected final state before sending the request. After the platform acknowledges it, read the authoritative destination using a fresh query. Compare record identity, changed fields, prior values, new values, owner, lifecycle state, sequence membership, task status or message disposition as applicable. Record asynchronous completion time instead of assuming acknowledgement is final.

Use five outcome states: verified exact, verified with explained normalization, rejected as designed, unresolved, and incorrect. Explained normalization covers documented behavior such as formatting or canonicalization; it requires evidence. Unresolved includes timeout, partial batch, missing read-back or ambiguous identity. Incorrect means the authoritative state differs from the approved expectation.

Measure evidence completeness

Calculate verified write-back rate as verified exact plus verified explained outcomes divided by all attempted actions. Report rejected-as-designed separately because a healthy authorization boundary is valuable but is not a successful business write. Publish unresolved and incorrect shares with counts, not percentages alone.

Score the evidence packet using independently visible components: stable source ID, initiator, tenant, effective permission, plan or credit condition, requested action, platform response, destination read-back, final-state timestamp and recovery owner. Report component coverage rather than hiding missing authority data inside one composite score.

Measure time to evidence: the elapsed time from request to verified read-back, plus the time a second operator needs to reconstruct the action. The first reveals asynchronous or connector delay. The second reveals whether the operating record is usable. Use medians and a high percentile only when the sample is large enough; always show sample sizes.

Test interruption and recovery

Introduce safe failure conditions such as an exhausted test credit budget, denied object permission, duplicate contact, suppressed recipient or destination timeout. Observe whether the workspace reports partial progress and preserves record-level results. A batch that stops after 40 of 100 records must identify the completed, rejected and untouched sets.

For reversible writes, execute the documented recovery and verify the authoritative state again. For irreversible communication, do not manufacture a live error. Evaluate the pre-send guard, escalation procedure and correction path instead. Record recovery attempted, recovery verified, manual reconciliation required and recovery unavailable.

Interpret without overclaiming

Compare the same action class, environment and configuration over time. A higher result after permissions, duplicate rules or logging change is evidence of local improvement. It is not proof that the underlying vendor outperforms another product. Different products expose different actions, availability states and operating grains.

Use product documentation as capability context. Apollo states that the Claude connector is beta and uses existing Apollo permissions, plan limits and credits. Outreach's KPI documentation supplies an example of explicit refresh and comparison qualifications. Intercom's macro administration change shows that knowledge actions also have ownership and distribution consequences. None of those statements substitutes for tenant-level verification.

Publish the benchmark with its exclusions and repair queue. Assign every unresolved or incorrect result to the system owner, integration owner or process owner. Repeat after material connector, permission, schema or packaging changes. The objective is not a perfect score; it is a repeatable way to prove that external-agent work becomes authoritative state with visible control.