Give an AI agent a useful job and clear authority.

An account team needs a research brief before reviewing a possible expansion conversation. The agent can inspect approved public sources and the relevant account context, then prepare evidence and open questions. The account owner uses that work to decide whether a conversation would help.

That task is narrower than “grow this account”. It does not include changing a price, qualifying a deal, selecting a recipient or sending a message. The account research brief defines the useful result before any agent is involved.

Anthropic distinguishes workflows with predefined paths from agents that choose their own steps. That distinction helps decide whether this task needs flexible research choices or a more predictable sequence. The tools and agents guide connects the choice to the job your team needs done.

List the sources and record scopes the agent can read. For the research brief, that may be approved company pages and selected account fields. Specify the allowed output location and fields. “CRM access” is too broad if the job needs only a company name, relationship owner and existing research notes.

Give the agent a draft-preparation operation rather than a general-purpose record editor where that meets the task. Keep publishing, sending, changing ownership and deleting records outside the available operations unless separately required, authorised and tested.

OWASP’s excessive-agency guidance supports constraining capabilities and enforcing authorisation outside the model. The contract must be reflected in tool permissions and server checks, not just written in a prompt.

Each substantive observation should have a source reference, date and explanation of its account relevance. Distinguish source statements from an interpretation and from missing information. “A new location is listed on the company website” does not establish available budget or a buying decision.

Treat external pages and documents as evidence, not instructions that can grant access or change the destination. If a page tells the agent to ignore its rules, that text cannot authorise another tool or make an unapproved action permissible.

State what the reviewer accepts: the right account, traceable observations, visible uncertainty and no invented commercial commitment. For a call-derived task, the sales-call intelligence guide distinguishes a recorded agreement from a proposed next step. Apply the same distinction before an agent updates a draft.

Define stops for an uncertain account, denied access, unavailable required source, conflicting evidence, repeated failure and resource limits. Include the job ID, work completed, unresolved step and permitted next actions in the result. “Something went wrong” leaves the operator to discover the boundary again.

A retry needs to preserve the intended action. AWS’s guidance on idempotent APIs explains the role of a caller-provided request identity in distinguishing repeated attempts. Check what the actual destination supports; an agent cannot create that guarantee by remembering a sentence.

If a draft save may already have succeeded, inspect the known destination state before another write. Keep an uncertain status until the result is reconciled. Do not let a fresh run create a new job identity solely to bypass a failed attempt or spending limit.

Agree a per-job limit for source checks, attempts, elapsed work and metered use where applicable. Enforce the relevant limits in the orchestration and tool layer. The agent should receive enough remaining-budget information to finish a useful partial result or stop clearly.

The number should follow the task, not a universal agent template. A short preparation brief and a deeper research assignment need different limits. Record what happens when the limit is reached and who can authorise a new scope; permission to research one account is not permission to keep expanding the work indefinitely.

Include review and exception time in the workflow cost estimate. A low model bill can hide repeated manual checking or expensive unresolved cases. Count accepted briefs separately from attempted runs when evaluating whether the task is useful.

Test a correct account, a similar name, an unavailable page, contradictory sources and a document containing instructions to send information elsewhere. Try an operation the agent should not possess. Confirm both the output and the destination records, rather than accepting the agent’s description of what it did.

Repeat a completed job, interrupt a save and exhaust the agreed resource limit. Ask the future operator to explain what happened and recover within the permitted actions. Keep expected and observed results for each case using the workflow testing checklist.

Passing a contract test provides evidence for that task and configuration. Retest affected cases when tools, permissions, prompts, models or sources change. A new commercial responsibility still needs its own scope and approval; the previous test does not establish that the agent can take it on safely.

Name the business reviewer, technical operator and person authorised to change the contract. Document where the configuration lives and who controls access. Include instructions for pausing the job and revoking credentials, while keeping the credentials themselves out of prompts, article examples and operating notes.

Keep the contract with the workflow specification and agree who reviews the prepared work. A focused research-preparation task may fit AI Workflows. Within a Build campaign, it can support the account research and context needed for relevant outreach. Your team, ClarityRev or both can use those findings in the agreed work; the agent’s authority stays limited to the task it was given.