A decision contract for choosing agents or rules in GTM workflows

Clay published six examples on 27 August describing how its own go-to-market team uses agents. The examples cover company and people research, structuring CRM and transcript data, deal postmortems, account-health scoring, persona classification, and email drafting. They are useful as workflow patterns, but they are vendor-described internal examples rather than independent evidence that an agent improves revenue, productivity, data quality, or customer outcomes.

The most useful operating idea in the article is smaller than the list of use cases: use an agent where the work requires interpretation, and keep fully expressible rules deterministic. RevOps teams can turn that distinction into a decision contract before introducing an agent into a production workflow. The contract defines the question, input evidence, allowed output, downstream authority, reviewer, failure path, cost boundary, and version. It also makes clear which steps should remain ordinary filters, formulas, branches, or API calls.

Start with the decision, not the agent

Describe the business decision in one sentence. Examples include classify the buyer role from a job title and public profile, summarize why a closed-lost deal failed from accepted evidence, or propose an account-health label from several recent signals. Avoid a brief such as improve pipeline quality with AI. It does not name a record, decision, owner, or observable result.

Then identify who already owns the decision. RevOps may own field definitions and workflow logic. Sales management may own a forecast call. Customer Success may own the account action. Legal, Security, Finance, or Data Governance may own constraints on evidence, retention, or commercial interpretation. An agent can prepare information for an owner; it does not acquire decision rights merely because it can produce a plausible answer.

Set the operating grain. Decide whether one run represents a person, company, deal, conversation, account-period, renewal, campaign, or message. Preserve stable identifiers and the source timestamp for every input. A summary produced from several records should point back to those records rather than becoming an unattributed block of text in the CRM.

Keep deterministic work deterministic

A deterministic step is one where the team can state the rule completely and expects the same validated input to produce the same output. Normalizing country codes, checking whether a required field is empty, matching an exact product ID, calculating days until renewal, applying an approved stage-to-probability table, and routing an exception by territory are usually better represented as formulas, filters, mappings, or explicit workflow branches.

HubSpot's workflow documentation illustrates the breadth of those conventional controls: enrollment criteria, delays, branches, record edits, record creation, notifications, and connected-app actions. These steps are inspectable and testable. They also expose edge cases. A record can remain in one workflow while entering another, an overwrite setting can replace existing data, and a branch can depend on the output of an earlier action. Adding a model between those steps should solve a defined interpretation problem, not hide incomplete workflow design.

Write the deterministic path first. Record the accepted input type, rule, output field, null treatment, duplicate behavior, permissions, retry behavior, and idempotency key. If the path cannot be explained without phrases such as the model will work it out, the team has not yet separated rules from judgment.

Give an agent an evidence contract

Agent work begins where evidence is unstructured, dispersed, or context-dependent. Even then, define the evidence envelope. List which CRM objects, calls, emails, tickets, documents, websites, warehouses, and time windows are allowed. Mark authoritative sources and sources that provide context only. State which data is prohibited, sensitive, stale, or too weak to support the decision.

For a deal postmortem, require the final deal record, accepted commercial version, stage history, close-date history, forecast changes, relevant conversations, and the closed-lost reason. Ask the agent to distinguish observed facts, attributed stakeholder statements, and inference. The output should cite the record or conversation behind each material conclusion. A fluent narrative without a trace is not a reviewable postmortem.

For an account-health proposal, keep raw signals separate from the label. Preserve dates, direction, source, missingness, and contradictions for product usage, support, billing, relationship coverage, commitments, and renewal timing. Ask the agent to return the proposed label, evidence used, evidence missing, conflicts, and confidence. Do not let a label overwrite the underlying record or trigger a customer action until the responsible owner accepts the evidence.

For persona classification or research, define an allowed taxonomy and an unknown state. Require source URLs and retrieval times for public evidence. A model should not force a person into the nearest label when the source is ambiguous. Unknown, conflicting, and needs review are operational outcomes, not model failures.

Separate recommendation from execution

The safest first production pattern is propose, review, then execute. The agent produces a structured recommendation in a bounded field or queue. A human or deterministic policy decides whether to accept it. A separate workflow performs the write, notification, enrollment, or customer-facing action and records the actor, prior state, reason, and result.

Read-only access does not eliminate risk, but it narrows the blast radius. Start with a representative cohort and include hard cases: missing fields, contradictory evidence, duplicate records, several associations, a recently merged account, a permission failure, and content in an unexpected language. Compare agent output with the current manual decision and inspect disagreements rather than reporting only an average acceptance rate.

When write access is justified, restrict objects, properties, operations, cohorts, and volume. Protect commercial amount, legal status, consent, billing, entitlement, forecast category, owner, deletion, and customer communication behind explicit authority. Use idempotency, replay protection, rate limits, a kill switch, and a tested rollback path. A model result should never be the only surviving evidence for a material record change.

Version the workflow as one system

Version the prompt, model, tools, retrieval rules, source mappings, taxonomy, validation schema, deterministic branches, and approval policy together. A prompt version alone is insufficient when the available evidence or downstream action changes. Store the version on each run so a reviewer can reproduce the operating context of an accepted output.

HubSpot documents enrollment history by workflow version and record path. That is the right kind of operating evidence, although retention and log limits vary by platform and plan. Export or preserve the evidence required by your own audit, customer, security, and incident-response obligations. Do not assume the product UI will retain every successful execution indefinitely.

Monitor inputs as well as outputs. Useful controls include missing authoritative records, source freshness, retrieval failures, schema rejection, unknown classifications, reviewer acceptance and rejection, corrections after acceptance, attempted prohibited writes, retry volume, duplicated actions, model or prompt changes, latency, and credit or token consumption. These are control measures. They are not universal benchmarks and should not be presented as proof of business impact.

Run a 30-minute boundary review

Choose one candidate workflow and draw every step from enrollment to final action. Mark each step as source retrieval, deterministic transformation, interpretation, policy decision, approval, execution, or verification. Circle any step where a model both interprets evidence and executes a material action. Those combined steps deserve the first redesign.

For each interpretation step, write the evidence contract: allowed inputs, source authority, maximum age, required citations, missing-data behavior, output schema, confidence treatment, and reviewer. For each deterministic step, write the exact rule, type checks, null handling, duplicate protection, and failure route. For each action, name the system owner, permission, prior-state capture, idempotency key, rollback action, and post-write verification.

Test five to twenty representative records depending on risk and variation. Record accepted, rejected, corrected, and unresolved outputs. Do not average away one severe failure, such as an unauthorized record change or an invented customer statement. Promote only the bounded path that another operator can explain from source evidence to final state.

What the current evidence does not prove

Clay's examples show what one vendor reports doing inside its own operation. They do not establish a universal agent architecture, a default model, a reliable accuracy level, a credit budget, or a measurable lift for another company. HubSpot's documentation establishes available workflow controls and logs, not that a particular agent step is safe or effective. NIST provides risk-management guidance, not a certification of any vendor implementation.

Local evidence still decides whether the workflow should ship. Keep the smallest system that satisfies the decision. If a formula, lookup, or branch can express the rule, use it. If interpretation is necessary, bound the evidence and output. If an action is material, preserve human or policy authority and verify the resulting record. The goal is not to maximize agent coverage; it is to make every automated decision inspectable and reversible.

Related reading: AI workflows for RevOps · GTM operations workflows · CRM data quality · Clay tool profile · Renewal control check