Agents behind the rep

Built from the system Angelo Quiambao, GTM engineer at Intellistack, described on GTM Vault SMYS 7 (https://pro.gtmvault.co/episodes/smys-07). Published free by GTM Vault. Numbers below are the operator's own, from the episode; your results will differ.

When to use this

Use this when a sales team has agents or AI tools that only a few reps touch, or when a GTM engineer is about to build an outbound agent system and wants adoption designed in from the start. The premise, from the episode title, is that your reps should never meet your agents. The output is a build spec: context definitions, an agent map, gates, a rep trigger and an eval log.

The system on the record

Angelo measures rep adoption first. If reps are not using the agents, to him they are useless, and occasional tinkering wastes everyone's time (SMYS 7, 5:44). His operating line is that "the best use of AI is the indirect use of AI" (SMYS 7, 6:48).

The system, as he ran it live:

1. Context before agents. Before any agent exists, account tiering, ICP definitions, product information and buying teams are mapped and aligned with RevOps, marketing and sales so they are uniform (SMYS 7, 2:46). Curated lists and knowledge bases update daily and the agents pull from them (SMYS 7, 1:00).
2. Claude Code as the terminal, Relevance AI as the agent host, connected over MCP (SMYS 7, 1:43).
3. One orchestrator. Its only job is to take a request, pass it to the right agent and assemble the result (SMYS 7, 3:42). It keeps a record of accounts already researched and will say research was done 60 days ago and ask whether to rerun it. It tracks errors and updates the CRM with sequence and days since last touch (SMYS 7, 3:42 and 4:42).
4. Single-job agents behind it: prospecting, account research, contact research and emailing (SMYS 7, 4:42). His rule is that no agent makes multiple decisions, because that creates too many areas for error (SMYS 7, 16:57 and 17:57).
5. Internal data before external. The research agent first asks whether there is an open opportunity, closed-lost history, first-party intent or MQL and MQA personas, then looks at third-party intent (SMYS 7, 9:49).
6. Gates. ICP gates, duplicate checks and pre-checks block accounts that should not be contacted, such as those already in a deal cycle, and the result is logged with the CRM updated in real time (SMYS 7, 9:49 and 10:52).
7. Tool agents, not raw connections. He wrapped the Apollo API and its docs into an agent that can read and write Salesforce, Gong and Databricks, instead of prompting Claude through an MCP (SMYS 7, 10:52). A Relevance agent also queries a Genie agent inside Databricks (SMYS 7, 12:57).
8. Fallback and evals. When there is nothing real to personalize, a fallback stops "AI slop" from going out (SMYS 7, 14:00). Errors are tracked, logged and evaluated like a human rep (SMYS 7, 9:49).
9. The rep surface. In Salesforce, a webhook sits behind a checkbox. Reps do not need to know they are activating a seven layer agent architecture; they need to know an email to their top prospect will be in their drafts (SMYS 7, 7:42). In his previous role, reps also queried agents in natural language through Slack (SMYS 7, 8:47).
10. The ten word test. If he cannot describe to leadership in five to 10 words what an agent does, the build is too intricate (SMYS 7, 6:48).

The result

1. At Qualified, the agents became around 60% of the BDR workflow daily (SMYS 7, 5:44).
2. He frames the aim as 5x the output of one person rather than replacing one person (SMYS 7, 4:42).
3. The live run, which he says was the first on the new build, finished four contacts with no flags (SMYS 7, 14:00).
4. For a 40 rep enterprise team running this every day, he estimates maybe 10 million credits a day across Relevance and Claude, justified because it generates revenue (SMYS 7, 14:50).

Run it on your company

1. Ask once, in one message, for: where reps spend their day (CRM, Slack, inbox); the CRM and data warehouse in use; current tiering, ICP and buying team definitions, and who owns each; the data sources for opportunities, closed-lost, first-party intent and MQL or MQA; the prospecting and enrichment providers; the agent host or orchestration tool available; team size; and the one outcome a rep should get from a single action.
2. Write the context sheet: one table with columns Definition, Current wording, Owner (RevOps, marketing, sales), Agreed (yes or no), Refresh cadence. Flag every row where the three teams disagree. Nothing gets built until those rows are resolved.
3. Write the ten word statement for the whole system and for each agent. If any statement runs past 10 words, split that agent.
4. Draw the agent map as a table: Agent, Single job, Reads from, Writes to, Output, Fails to. One orchestrator row plus one row per job (prospecting, account research, contact research, email drafting, and any tool agents such as an enrichment provider wrapped with read and write access). Reject any row whose job needs the word and to describe it.
5. Write the orchestrator spec: routing rules, the memory lookback window (default to the 60 days from the episode, adjustable), the question it asks before rerunning research, and the CRM fields it writes after each step.
6. Write the research order and gates as a checklist the account research agent runs: internal checks first (open opportunity, closed-lost, first-party intent, MQL or MQA personas), then external signal, then the ICP gate, duplicate check and active deal check. Each gate names its data source and what it logs on a block.
7. Write the drafting rules, including the fallback: what the email agent writes when no real personalization is found.
8. Design the rep trigger: one action in the place named in step 1. Specify the checkbox field and webhook, or the Slack command, and the single sentence reps will be told. Include nothing else for the rep.
9. Set up the eval log as a table: Date, Account, Agent, Error type, Gate that should have caught it, Fix. Review it weekly.
10. Set the scorecard with rep adoption as metric one (share of reps triggering the system each day, share of drafts sent) and a credit budget per day.
11. Deliver one Markdown build spec containing all of the above in order.

Tools on the record

1. Claude Code: terminal layer the agent infrastructure is built and run from.
2. Relevance AI: hosts the multi-agent system behind the rep-facing checkbox.
3. Databricks: data platform the agent layer reads and writes.
4. Salesforce: CRM the agents read from and write back to.
5. Gong: read and written by agents, including historical checks.
6. Apollo: prospecting data wrapped as an agent via its API.
7. Slack: natural-language trigger for the query agent where reps work in Slack.

Any tool doing the same job works; the method is the point. Full stack: https://pro.gtmvault.co/stack/operator/angelo-quiambao

Where it breaks

1. No context, bad output. With zero context he calls the outputs horrendous (SMYS 7, 2:46), and lazy prompts only work if the system is intricate (SMYS 7, 16:57).
2. Automating work nobody has done by hand. He says you cannot automate something you have not done (SMYS 7, 15:53).
3. Failure at scale costs more than it saves. If the agents do not work at enterprise scale, they create more errors and time for the team (SMYS 7, 15:53).
4. Multi-decision agents. Agents with several decision layers multiply the areas for error (SMYS 7, 16:57 and 17:57).
5. Credit burn. Daily runs across a large team consume credits at volume, so the error rate has to stay low for the spend to hold up (SMYS 7, 14:50).