• Three checks that separate a real agent from a named wrapper: persisted state, a disclosed data layer, and recovery from a failed tool or API call.
    • One data layer for the whole loop: Explorium unifies 150M+ company profiles, 800M+ people profiles, and 18 buying-signal categories under one account, so no second vendor is needed.
    • Built for scale so the loop does not stall: the AgentSource API processes up to 1,000 entities per call at 100 QPS sustained, server-side, not loaded into a model’s context window.
    • Disclosed and inspectable by design: called from your own code, Explorium’s data layer is something your team inspects, not a name you have to trust.
    • Explorium metric: 97.8%+ company match accuracy is disclosed and testable, unlike an undisclosed data partner behind a branded agent name.
    • Install / outcome: pip install explorium, then run the 3-check evaluation below against any named agent you consider.

    At Dreamforce 2026, Salesforce introduced seven Agentforce agents with human names: Casey, Paige, Carter, Hunter, Marshall, Piper, and Fin, each scoped to one job. A named AI agent vs real orchestration distinction matters here: a human name signals packaging, not architecture, and a keynote demo cannot show the difference. Six of the seven are generally available now; Hunter, the outbound agent, is still in pilot, GA planned for November 2026.

    The same week, a separate practitioner thread on agent resilience argued most so-called agents are one model call in a wrapper, a human deciding what happens next after every response, and that real orchestration means persisted state, shared context, and error recovery. Below: three checks to run before you build or buy, plus what building your own on a disclosed data layer takes.

    What Does Salesforce’s Hunter Agent Actually Do, and Why Does Its Data Partner Matter?

    Salesforce’s Hunter agent, not to be confused with the email-finding tool Hunter.io, runs company and person search, enrichment, and outbound sequencing, and it is built on a named external data partner rather than a proprietary data layer. Salesforce’s own announcement does not disclose the partner or memory-retention duration; that came from the partner’s own press release, not the platform, so even this “disclosed” case was vendor-disclosed, not platform-disclosed.

    💡 Why the Disclosure Itself Is the Signal

    • Salesforce named an external data partner for Hunter instead of claiming a proprietary layer, a fact a buyer can verify.
    • The named partner’s own materials claim 240 million contacts and a claimed 98% email accuracy, numbers checkable only because the vendor published them.
    • Hunter’s GA is November 2026: today’s evaluation is of a pilot, not a shipped product.

    ⚠️ What “Named” Does Not Tell You

    • Whether it remembers what it tried on an account between runs.
    • Whether a failed call ends the workflow or triggers a retry.
    • The metering unit underneath the packaging.
    “Salesforce released seven named AI agents… each scoped to a specific job. The product story is packaging: buy a finished agent instead of assembling one. The strategic story is the metering unit underneath it.” — Mark Vigoroso, LinkedIn

    What Is the Difference Between a Named AI Agent and Real Agent Orchestration?

    A named AI agent is a product label; real orchestration is the engineering that lets an agent survive past its first successful run. Salesforce’s own long-horizon runtime description lists memory, durable execution, and dynamic steering as what makes an agent durable, a definition that puts its own six agents not yet on that runtime in the same catching-up category as everyone else.

    “Two years into the agent era and most ‘agents’ are still one model call in a nice wrapper. Prompt in, text out, a human decides what happens next. Real orchestration is a different engineering problem. State that persists across steps.” — Avi Gupta Konda, LinkedIn

    ❌ The One-Call Wrapper Pattern

    • Prompt goes in, text comes out, a human decides what happens next after every response.
    • No memory of what the agent already tried on this account previously.
    • No shared context between tools, so each call starts from a blank slate.

    ✅ The Orchestration Pattern

    • State persists across steps: the agent does not repeat a failed action.
    • Tools share context: a search result feeds the enrichment call directly.
    • The agent recovers from a failed call instead of stopping on the first error.
    Diagram comparing a one-call prompt wrapper against a real orchestration loop with persisted state and error recovery

    How Do You Check Whether an Agent Persists State Across Steps?

    Ask the vendor, or test the agent yourself, whether it remembers what it already tried on an account after a session ends. Run the same account through the workflow twice, a day apart, and check whether the second run repeats the first run’s failed attempt or skips it.

    🔄 The Two-Run Test

    • Run the agent on a test account and record every action: contacts enriched, sequence queued, call failed.
    • Run it again 24 hours later without feeding it that history manually.
    • If it repeats the same failed action, it has no persisted state. If it adjusts, it does.

    🏗️ What Real State Persistence Looks Like

    A stateful agent stores what it tried per account, not just per conversation, as a small, inspectable record you own:

    {
  "account_id": "acct_48213",
  "last_attempted_step": "email_enrichment",
  "outcome": "no_match",
  "next_action": "retry_with_secondary_domain",
  "attempts": 2
}

    That object, written back after every step, separates an agent that learns from history from one that starts fresh each time.

    How Do You Tell If an Agent’s Data Layer Is Disclosed or a Black Box?

    Ask who the underlying data provider is, whether that answer is published, and whether you can test the accuracy of what it returns. The Hunter disclosure is a useful example: a named partner is at least a checkable data layer, even though the platform itself stayed silent.

    📊 The Disclosure Checklist

    QuestionBlack box answerDisclosed answer
    Who provides the data?“Our proprietary database,” no source namedA named provider or inspectable data source
    Can you test accuracy yourself?No sample data, sales call required firstA free, sample-before-you-commit account
    Are accuracy numbers published?Marketing language only (“top-tier accuracy”)A specific number (for example, 97.8%+ match accuracy)
    “Your outbound agent has read access to the CRM and send access to email. What else can it reach from there?” — Abraham Noya, LinkedIn

    🛡️ Why Access Scope Is Part of Disclosure

    That access-scope question applies to data provenance too: if you cannot answer where the data comes from, you cannot answer what the agent is allowed to touch.

    How Do You Check If an Agent Recovers From a Failed Tool or API Call?

    Force a failure, a bad domain, a rate-limit hit, a timeout, and watch whether the agent retries with a fallback or stops outright. A demo never sees a failed call; production hits rate limits and missing records within the first week.

    ⚡ A Minimal Retry Pattern to Test For

    import requests, time

def enrich_with_recovery(domain, api_key, max_retries=3):
    for attempt in range(max_retries):
        r = requests.post(
            "https://api.explorium.ai/v1/companies/enrich",
            headers={"Authorization": f"Bearer {api_key}"},
            json={"domain": domain},
        )
        if r.status_code == 200:
            return r.json()
        if r.status_code == 429:
            time.sleep(2 ** attempt)
            continue
        break
    return {"status": "failed", "attempts": attempt + 1}

    🛡️ Reading the Pattern

    If a named agent cannot explain an equivalent pattern, one bad response ends the workflow, and every downstream step silently never happens.

    Why Does a Demo-Ready Agent Still Break on Real Accounts?

    A demo runs against a clean account, conditions a real book of business never provides. A team that builds its own “agent” as a single prompt calling a single API works in the demo and breaks in production.

    ❌ Failure Modes That Only Show Up in Production

    • An ambiguous company name resolves to the wrong entity, and nothing catches it.
    • A contact record is missing an email, with no fallback path.
    • One rate limit or timeout takes down every step queued after it.

    ✅ Why Server-Side Bulk Processing Avoids the Worst of This

    Loading every record into a model’s context window caps a useful run at roughly 20 to 100 prospects before tokens overflow. Explorium’s AgentSource API processes up to 1,000 entities per call server-side at 100 QPS sustained, so a bulk step does not stall partway through.

    Building your own outbound orchestration instead of trusting a named agent’s branding? Start free: 100 credits, no subscription required

    What Questions Should You Ask a Vendor Before Buying a Named AI Agent?

    Ask the three questions a keynote demo never answers: what persists between runs, where the data comes from, and what happens on a failed call. A vendor with specifics has shown you real orchestration; one who answers “our proprietary technology” has shown you a wrapper.

    🔑 The Three-Question Script

    • “What does your agent remember about an account between two separate runs, a week apart?”
    • “Who is your underlying data provider, and can I test the match rate myself first?”
    • “When a single API call inside this workflow fails, does the whole run stop, or retry?”

    💰 Why This Matters Before You Buy

    A vendor with nothing to hide answers all three concretely, even about a product still in pilot, like Hunter until its November 2026 GA.

    What Does It Take to Build Your Own Orchestration on a Disclosed Data Layer?

    Building your own stateful outbound agent means putting state and error-recovery logic on a data layer you can inspect, not a name you have to trust. Explorium is built for this: a REST and SDK data layer for teams writing their own agent loop.

    🔑 One Data Layer for Everything the Loop Needs

    • 150M+ company profiles, 800M+ people profiles, 50+ data sources, one account, one credit pool.
    • 18 buying-signal categories and 80+ signal types on the same API surface as company and contact search.
    • 97.8%+ company match accuracy, a disclosed number verifiable on a free account.

    🚀 Built for Scale So the Loop Does Not Stall

    • Up to 1,000 entities per call, server-side, at 100 QPS sustained.
    • 99.999% uptime and a unified credit pool, not a per-endpoint allocation limit.
    • Minutes to first API call on a free account, no sales call required.

    💡 Disclosed and Inspectable by Design

    Called from your own code, this data layer is something your team inspects, unlike a packaged agent where “who is behind this” stays undisclosed unless a partner volunteers it.

    curl -X POST https://api.explorium.ai/v1/companies/enrich \
  -H "Authorization: Bearer $EXPLORIUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "example.com"}'

    For a build-your-own comparison, Explorium’s side-by-side B2B data provider comparison covers what matters for an orchestration loop, not just a feature list.

    DimensionExplorium APICoresignal
    Pillar 1: one data layer150M+ companies, 800M+ people, 18 signal categories, one credit pool792M+ employee, 103M+ company records, raw dataset access
    Pillar 2: scale per callUp to 1,000 entities/call, 100 QPS, server-sideCredit-metered per record (10/employee, 20/multi-source)
    Pillar 3: disclosedFree account, minutes to first call, 97.8%+ match accuracy publishedPlans from $49/month (2,500 credits) to $5,000/month (10M credits)

    Getting Started: From Data Layer to Production Orchestration in 5 Steps

    Test the data layer for free before writing any orchestration code, then add state and error recovery in layers.

    pip install explorium
    • Step 1: Create a free account and run test enrichment calls against accounts you already know.
    • Step 2: Add a persisted state record per account, the JSON pattern above.
    • Step 3: Wrap every API call in retry logic with backoff.
    • Step 4: Graduate to bulk requests of up to 1,000 entities once state and retry logic work.
    • Step 5: Layer in buying signals once the loop is stable.

    🔑 The Decision Framework

    A human name tells you nothing about whether an agent remembers what it tried, whether its data source is disclosed, or whether it survives a failed call. Test it, or ask the vendor for specifics, not marketing language. If a vendor cannot answer, Explorium gives you the disclosed data layer to build the orchestration yourself.

    Ready to build the orchestration layer yourself instead of trusting a name? Start free with Explorium

    Related Posts

    FAQs