Build a post-call CRM hygiene Outreach agent using Claude Agent SDK

TL;DR

• Outreach returns two different ⁴⁰³ responses, and only one of them is knowable before the call. ^{unauthorizedOauthScope} means the token lacks the scope; ^{unauthorizedRequest} means the rep's governance settings do not let them touch that record. A scoped tool surface catches the first. Nothing about your tool list catches the second.
• The Claude Agent SDK runs an autonomous loop, so a ⁴⁰³ is not a stop condition; it is context the model reasons around. A hygiene agent that gets denied on ^{outreach_prospects_update} can decide ^{outreach_prospects_create} is a reasonable alternative and leave you a duplicate prospect.
• ^{allowed_tools} does not restrict anything. It auto-approves. By default the session also carries the full Claude Code toolset including ^Bash and ^Write, which is documented behavior. Restriction is ^{disallowed_tools} plus ^{permission_mode="dontAsk"}.
• ^can_use_tool fires only when the permission flow falls through to a prompt, so it never runs for tools you pre-approved. The only gate that runs on every call is a ^PreToolUse hook.
• Outreach rate-limits per user at 10,000 requests per hour and caps a user/application pair at 100 live tokens. A shared service account funnels every rep's agent traffic into one bucket; per-user connected accounts give each rep their own.
• Scalekit's Outreach connector carries 80 tools over OAuth 2.0. A Virtual MCP config declares which of them the agent role may reach, ^{list_scoped_tools} confirms the rep authorized them, and the hook denies the ones the surface cannot refuse.

A rep finishes a discovery call with Northwind. The prospect's title changed, the account has grown past the employee band on record, and the next step moved out two weeks. Twenty minutes of retyping, or an agent that reads the call activity and writes the deltas back.

The agent is not hard to build. The first version works on the rep who built it. It breaks on the second rep, and it breaks in a way that produces worse data than doing nothing.

The two 403s Outreach returns, and why only one is visible to your tool surface

Outreach OAuth scopes are period-separated pairs of a pluralized resource and an access level: ^{prospects.read}, ^{accounts.write}, ^calls.all. The Outreach developer portal is explicit that they are not additive; ^{prospects.write} grants no read access at all. A hygiene agent needs read and write on the same resource, so it needs both tokens or ^.all.

Miss a scope and the API is helpful about it:

Then there is the second gate. Outreach describes scopes as the front gate, and notes that holding a scope does not authorize the action on every resource: many customers run governance settings that permit a rep to manage only their own prospects, even when the app holds ^{prospects.all}. That failure looks different:

Two failures, precisely. One is a property of the credential; one is a property of the record.

This is the distinction that decides the architecture. A tool surface is an authentication artifact: it answers "what did this identity authorize." Record scope is an authorization question: it answers "may this identity act on this row." No amount of tool-list filtering answers the second one, because the tool that succeeds on prospect ⁴⁴¹⁷ and the tool that fails on prospect ⁹³⁰² are the same tool.

Your agent reasons around a 403. That is the failure mode.

In a deterministic pipeline, ^{unauthorizedRequest} raises, the job fails, someone reads a log. The Claude Agent SDK does not work that way. It runs the same loop that powers Claude Code: the tool result goes back into context, and the model decides what to do next. A denial is an input, not a halt.

Give that loop the Outreach connector and a goal phrased as "make the prospect record reflect the call," and the recovery path it finds is legitimate-looking and wrong:

1. ^{outreach_prospects_update} on prospect ⁹³⁰² returns ^{unauthorizedRequest}.
2. The model reads a generic authorization error with no record-level detail.
3. ^{outreach_prospects_create} is in the same connector, needs no existing record, and satisfies the goal as stated.
4. You now have two Northwind prospects, one of them owned by the wrong rep.

Three SDK properties turn that from a bad afternoon into a structural problem.

The default tool surface is everything. The SDK's own documentation states that Claude has access to the full Claude Code toolset by default. For instance, a developer set ^{allowed_tools=["Read", "Grep", "Ls", "Glob"]}, and the init ^{SystemMessage} reported ^{Task, Bash, Glob, Grep, ExitPlanMode, Read, Edit, Write, NotebookEdit, WebFetch, TodoWrite, BashOutput, KillShell, Skill, SlashCommand}. Another reported issue filed the naming itself as a security concern, noting that developers trying to restrict capability may instead grant unrestricted autonomous access.

^can_use_tool is not a gate. It is invoked only when permission evaluation resolves to a prompt. Anything approved by ^{allowed_tools}, a settings allow rule, or the permission mode skips it entirely. Put your authorization logic there and pre-approve your tools, and the logic never executes. The Claude SDK reference says this directly: to gate every tool call, use a ^PreToolUse hook.

You cannot force the write. The Messages API exposes ^tool_choice; ^{ClaudeAgentOptions} does not. The loop is free to summarize the call in prose and end the turn without ever writing. A hygiene agent that silently does nothing is indistinguishable from one that worked, unless you check.

Who is the agent when the call ends?

"Post-call" implies a trigger, and the trigger is the part most designs get wrong. ^{outreach_webhooks_create} will POST to you on a ^call resource event, which is the right signal. It is also an unauthenticated-actor event: a webhook carries a payload, not a session. Nobody is logged in when it fires.

So before any tool runs, the orchestrator has to answer one question: on whose behalf is this run executing?

The answer is never the payload. It is a server-side resolution:

• Read the call's ^prospect_id, then ^{outreach_prospects_get} for ^owner_id.
• Map that Outreach ^owner_id to a user in your own system, and that user to a tenant.
• Derive the Scalekit ^identifier from your own records, never from the request body.

Getting this wrong is the classic cross-tenant path. If ^identifier is a bare email, two reps at two customer organizations who share an address collide on one connected account, and the agent writes into whichever Outreach instance authorized last. Namespace it, and pass the tenant explicitly when the account is created:

Three planes, three different jobs

Each plane below enforces something the other two structurally cannot. Dropping any one of them reopens a specific failure.

Prerequisites

Configure an Outreach connection in the Scalekit dashboard with ^{prospects.all}, ^accounts.all, ^calls.read, ^tasks.all, and ^users.read. Request read and write separately or use ^.all, because scopes are not additive.

The ^{connection_name} string in every snippet below must match the Connection name in the dashboard character for character. Scalekit's docs flag this on ^{ScopedToolFilter} specifically: ^{connection_names} takes the dashboard Connection name, not a provider slug. It is the most common integration error in this whole flow.

Plane 1: bind the run to one rep's connected account

Twelve tools are enough for post-call hygiene. Declaring them once as a Virtual MCP config gives the agent role a fixed surface, independent of any single rep.

That leaves 68 of the connector's 80 tools outside the agent's reach, including every ^_delete tool and ^{outreach_prospects_create}, the tool that produced the duplicate.

The endpoint is static. The identity is not. Nothing in that function hands the agent an Outreach access token, and nothing in the agent process ever holds one; Scalekit injects the rep's credential at call time from the token vault and handles the refresh cycle behind it.

Plane 2: cut the surface before the model sees it

The Virtual MCP config says what the agent role may call. It says nothing about whether this particular rep authorized those scopes. ^{list_scoped_tools} answers that, and it is worth being precise about what it returns: the tools bound to this identifier's connected accounts. It reflects scope, not governance. A rep whose Outreach role cannot edit another rep's prospect still gets ^{outreach_prospects_update} in their scoped surface, and still gets ^{unauthorizedRequest} when they aim it at the wrong row.

Used for what it does answer, it converts a mid-loop ^{unauthorizedOauthScope} into a pre-run decision:

Surface reduction is also the cost lever. Every tool in context is tokens spent before the agent does any work; 40 tools at roughly 200 tokens each burns 8,000 tokens per run. The effect is measurable in the wild: an issue on GitHub reports a session where MCP tool definitions alone consumed about 144,802 tokens, with a single 135-tool server accounting for roughly 125,964 of them. Loading all 80 Outreach tools to use 12 is the same mistake at smaller scale, and it degrades selection accuracy at the same time it inflates the bill. The fix is not better prompting. It is surface reduction.

Recommended Reading: Token-efficient tool calling for AI agents — MCP is up to 32× more expensive than CLI, and surface reduction is the primary lever.

Plane 3: deny the call the surface cannot refuse

Everything the tool surface cannot express lives here. The hook runs first in the permission evaluation order and it runs on every matching call, which is exactly the property ^can_use_tool lacks.

Three policies, none of which the Outreach tool schema can encode:

• Record scope. The run was triggered by one call on one prospect. Any write aimed at a different ^prospect_id or ^account_id is out of bounds by construction, regardless of what the rep's Outreach role permits.
• Field policy. ^{outreach_prospects_update} accepts 14 parameters, including ^owner_id. A hygiene agent has no business reassigning ownership. The schema permits it; policy does not.
• Idempotency. Webhook redelivery is normal, and ^{outreach_prospect_note_create} has no idempotency key. Writing the same note twice is a hygiene regression caused by the hygiene agent.

Returning ^{} falls through rather than approving, which matters: a hook ^allow does not skip deny rules, and deny rules win in every permission mode including ^{bypassPermissions}. The hook narrows; it never widens. To rewrite arguments instead of refusing them, return ^updatedInput inside ^{hookSpecificOutput} alongside ^{permissionDecision: "allow"}; putting it at the top level silently does nothing.

Durable deduplication belongs upstream of the agent. Before the run starts, list the prospect's notes and refuse to launch if one already carries this call's tag:

Wire the agent shut, then run it

^{allowed_tools} auto-approves; it does not restrict. Restriction takes three separate options, and each one closes a different hole.

^{ResultMessage.permission_denials} is the audit signal worth alerting on. A denial means the model attempted something the hook refused, and a pattern of denials on the same tool is a policy or prompt problem, not noise. Pair it with ^num_turns and ^{total_cost_usd} per run and you have the operational picture; for the compliance picture, Scalekit logs every ^execute_tool call against the connected account that made it, which is the trail a security questionnaire on agent auth actually asks for.

Two connector behaviors will bite this specific agent. ^{outreach_tasks_create} requires both ^owner_id and ^prospect_id, and ^owner_id must resolve to the authorizing rep rather than an admin, which is why ^{outreach_users_list} with ^filter_email is in the read set. And ^{outreach_tasks_complete} works only on ^action_item and ^in_person tasks; call and email tasks cannot be completed through it, so a hygiene agent reschedules rather than completes. Both are documented on the Outreach connector page.

What breaks at 200 prospects

One prospect works. A nightly sweep is a different system, and the constraints are all upstream.

The per-user numbers are the case for connected accounts that has nothing to do with security. Because Outreach computes the rate limit from the user attached to the token, twenty reps on twenty connected accounts have twenty independent 10,000-per-hour budgets and twenty independent 100-token ceilings. Route the same twenty reps through one service account and you have one of each, plus an agent that holds admin-level access no individual rep has. What the user can't do, the agent can't do; that property is only available if the agent runs as the user.

Two more things worth knowing before the sweep goes nightly. The connector exposes call records, not transcripts: ^{outreach_calls_get} returns direction, outcome, note, and a recording URL, so the agent reasons over what the rep logged and the disposition they picked. Design for that, not for a transcript you do not have.

Recommended Reading: How to handle token refresh for AI agents and Single vs multi-tenant tool calling.

Where this design costs you

• Three planes means three places to change a policy. Adding a writable field touches the Virtual MCP config, the hook's field list, and the system prompt. That redundancy is deliberate, and it is still redundancy.
• A session per prospect costs latency and prompt cache reuse. You trade throughput for a bounded blast radius and clean per-prospect attribution. On a nightly batch that is usually correct. On an interactive assistant it usually is not.
• The record-scope check assumes single-record runs. An agent reconciling a whole account's contacts needs a set-membership check resolved server-side before the run, not the equality check above.
• ^{disallowed_tools} is an enumeration, and enumerations rot. A new built-in tool ships and your deny list does not cover it. Assert the surface at startup by reading the init ^{SystemMessage} rather than trusting the list you wrote.
• Denial reasons are model context. A specific reason redirects the agent well and tells anyone reading the transcript how your policy works. Write them to be actionable, not descriptive of the rule.

FAQs

Can the agent read the Kaia transcript to extract what changed?

Not through this connector; its 80 tools cover prospects, accounts, calls, sequences, tasks, templates, and webhooks, with no transcript tool. Kaia access is also rate-limited at the org level (3 calls/second, 6,000/day), so it does not scale with rep count the way per-user record access does. The agent works from the call's ^note, ^outcome, and disposition.

Why not run the whole org on one service account and skip connected accounts?

Three costs. Every rep gets identical access, usually admin-level, so the agent can reach records no individual rep can. Outreach's per-user rate limit and 100-token ceiling collapse to a single bucket. And every write lands under one identity, so the audit trail cannot tell you which rep's call produced which change. Service accounts have a place for genuine org-level background jobs; a per-rep hygiene agent is not one.

Should the authorization check go in ^can_use_tool or a ^PreToolUse hook?

The hook. ^can_use_tool runs only when permission evaluation falls through to a prompt, and every tool in ^{allowed_tools} skips it. In an unattended agent with pre-approved tools, a ^can_use_tool handler is code that never executes.

What happens when the rep's Outreach role genuinely cannot write the prospect?

Outreach returns ^{403 unauthorizedRequest}. Nothing in the tool surface predicts it, because scope and governance are separate gates. Surface it as a run failure with the record ID attached and route it to the record owner; do not let the loop improvise a workaround.

Does the agent process ever hold an Outreach token?

No. It holds a short-lived Scalekit session token scoped to one config and one identifier. Scalekit resolves the rep's Outreach credential from the vault at call time and manages the 2-hour access token and 14-day rotating refresh token. Credentials never touch the agent runtime.

Two reps at different customers share an email address. What breaks?

The connected account, if ^identifier is the bare email. Namespace the identifier with the tenant and pass ^{organization_id} when creating the account, so resolution is unambiguous and the audit trail names a tenant.

The session token expires mid-run. Then what?

Tool calls start failing on auth and the loop will try to reason around them. Mint the token immediately before the run with a lifetime sized to the expected duration, cap ^max_turns, and treat an auth failure as terminal rather than retryable. A run that outlives its token should end, not improvise.

Start building

1. Add the Outreach connection in the Scalekit dashboard with ^{prospects.all}, ^accounts.all, ^calls.read, ^tasks.all, and ^users.read, then confirm the tool names against the Outreach connector docs.
2. Create the Virtual MCP config with the 12 hygiene tools using ^{actions.mcp.create_config}, and keep ^{outreach_prospects_create} and every ^_delete tool out of it.
3. Wire the webhook-to-identity resolution before anything else; the run cannot start without an ^identifier derived server-side.
4. Harden ^{ClaudeAgentOptions} first and add the hook second, then verify against the init ^{SystemMessage} that the surface is what you declared.
5. Scaffold it from your editor: ^{/plugin marketplace add scalekit-inc/claude-code-authstack} then ^{/plugin install agentkit@scalekit-auth-stack}.

Adjacent builds worth reading before you start: the Post-Call CRM Agent guide, the deal intelligence agent, and agent tool calling auth patterns for the capability tradeoff between the two paths.

Start with the AgentKit quickstart, or talk to an engineer about the multi-tenant shape.