Clay’s inbound agent: validate before connecting real leads

Before connecting real leads, define which decisions the agent may make and what evidence each permission requires.
Start with qualification, demo boundaries, routing, data handling, and recovery.

In its October 8 Sculpt recap, Clay previewed an inbound agent for voice qualification and sandbox product demos.
The invitation is for pre-beta partners.
The recap's attendee access and Workflows beta statements concern separate products.

Clay's product page offers a waitlist and describes phased shipping starting in fall 2026.
These pages were checked October 13, 2026, UTC.
Neither statement confirms access for your team.

This article proposes evaluation requirements. It does not report a product test or verify that Clay provides the controls below.
The recommendation is simple: approve each customer-facing permission separately, using evidence from a bounded evaluation.

Confirm access before designing the rollout

Ask Clay which components your team can evaluate, under what terms, and with whose support.
Request the cost basis and a supported method for stopping customer-facing actions.
Keep unanswered questions visible in the evaluation decision.

Assign a RevOps owner to collect those answers and coordinate sales, product, and security approval.
That person should distinguish requested access from enabled access.
An invitation, contract discussion, or convincing demonstration should not substitute for confirmation of your actual permissions.

Write down the initial scope before connecting anything: approved inputs, permitted actions, excluded systems, and the person who can stop the evaluation.
If the available environment cannot support that scope, postpone the trial.

Separate the permissions

Treat reading context, recommending a route, booking a meeting, and changing qualification policy as independent approvals.
Permission to inspect a lead is not permission to act on it.

For an initial evaluation, require a proposed route without a customer-facing action.
Then compare that recommendation against a decision your team recorded beforehand.
Only a separate approval should permit a booking in a test calendar.

Keep policy changes outside that approval.
A useful suggestion about qualification should still require a named owner, supporting evidence, and an explicit decision.
Do not let an accepted booking silently authorize changes to future qualification rules.

For inbound sales, also name the person responsible when the permitted action cannot finish.
The boundary needs a human next step, not merely a disabled button.

Define qualification before scoring

Write the expected disposition before asking for a score.
Use the same input facts to distinguish qualified, disqualified, and unresolved cases.
Specify which missing facts require a question and which contradictions require review.

For example, an unavailable company size should remain unknown unless your policy explicitly explains a different treatment.
It should not become evidence that the company falls below your threshold.
Require every disqualification reason to point to an allowed criterion and supporting input.

Connect lead scoring to that decision record rather than accepting a persuasive explanation afterward.
Record the criterion, source, expected disposition, and permitted next action.
Ask a reviewer who did not configure the evaluation to check the result.

Keep the initial inputs invented and free of customer information.
Before introducing recordings or personal data, have the responsible privacy owner approve collection, disclosure, permitted reuse, retention, deletion, and access.
Do not assume permission for the original conversation also permits its use in this evaluation.

Keep the demo inside its boundary

Require an isolated demo tenant with synthetic records and restricted credentials.
List what the agent may inspect, change, and transmit.
Exclude production credentials and customer records from the initial evaluation.

Have product owners approve the claims the demo may make.
Include an unsupported feature request in the test inputs.
The expected response should acknowledge the limit and offer a human follow-up, without inventing functionality or committing to a delivery date.

Include a request to ignore instructions and expose a restricted record.
The expected outcome should preserve the restriction, regardless of how politely the request is phrased.
Check the destination system for unauthorized changes; an agreeable response alone does not prove the boundary held.

Treat a sandbox description as the start of a permissions discussion.
Ask what is isolated, which connections remain active, and how the team can verify those boundaries.

Test the exceptions before the happy path

Consider an invented subsidiary that uses its parent's email domain.
The synthetic CRM fixture gives the subsidiary its own account and assigned owner.
A domain-only match points to the parent, whose owner is different.

Record the expected account as the subsidiary, the expected parent as its parent account, and the intended owner as the subsidiary's assignee.
Those are separate assertions. A correct parent relationship does not, by itself, establish the correct route.

In this proposed test, conflicting evidence should hold the record before booking.
Send the reviewer both candidate accounts, the conflicting evidence, and the expected ownership rule.
If the reviewer confirms the subsidiary and its owner, require explicit approval before allowing a test-calendar booking.
Otherwise, keep the hold and assign a manual next action.

Check for a single booking receipt with the intended owner.
Also verify that the parent owner's calendar received nothing.
This is an authored test scenario, not an observed Clay result.

Set a review deadline and escalation owner before running it.
Measure speed to lead alongside the disposition, rather than treating an immediate but incorrect booking as success.
If review times out, escalate the case. Do not silently release it.

Require evidence before expanding access

Clay's Workflows documentation describes run records containing configuration versions, step inputs and outputs, timing, and errors.
That is adjacent documentation, not confirmation of equivalent inbound-agent controls.

Ask what evidence the proposed evaluation can actually retain.
For each case, record the input, expected decision, permitted action, observed result, configuration identifier, reviewer, and approval decision.
Include actual side effects: the CRM record, assigned owner, calendar receipt, and any message sent.
Keep those records access-controlled and subject to the approved retention policy.

For the first authorized Clay run, cap the evaluation at 10 inputs.
Use cases covering missing facts, conflicting ownership, an unsupported request, a repeated submission, and an interrupted action.
This is a proposed safety ceiling, not a reported sample or proof of reliability.

After changing a rule, repeat the relevant cases within the approved cap.
Include a duplicate submission after an interrupted booking.
The expected outcome should reconcile the existing calendar state before creating anything new.
If the result remains unknown, require review instead of an automatic retry.

Stop on an unauthorized disclosure, wrong owner, unapproved action, or unreconciled write.
Confirm how to disable further actions and identify anything already pending.
Assign a person to continue affected conversations through the approved manual route.

Restoring an earlier configuration cannot retract a sent message or erase information a recipient already saw.
Plan the response to those consequences separately.

A clean evaluation should support a specific next permission, with its own scope and owner.
It should not authorize unrestricted access to real leads.
Before requesting that next stage, write the expected result for the case you most need the agent to refuse.