SMYS 7 | Your Reps Should Never Meet Your Agents
Why rep adoption, not agent capability, is the real constraint on GTM automation, and how Angelo Quiambao hides seven layers of agents behind a checkbox reps click without knowing what fires
Hi, it’s Rick Koleta. Welcome to GTM Vault, a breakdown of how high-growth companies design, test, and scale revenue architecture. Read inside OpenAI, Anthropic, Meta, and Google, and by 26,000+ operators across 140+ countries building GTM systems that compound.
The hard part of agentic outbound is not building the agent. Anyone can wire an LLM to Apollo and get a list. The hard part is that the rep does not use it. The demo lands, adoption stalls at the handful of people who enjoy tinkering, and six months later the build is a line item nobody defends. Most teams respond by training reps harder on the tool, which treats an adoption problem as an education problem.
In episode seven of Show Me Your Stack, Angelo Quiambao runs the opposite play. He is a GTM engineer at Intellistack, two months into rebuilding an outbound architecture he first proved at Qualified, where the agents went from an opt-in productivity boost to mandatory, with every BDR required to send fifty agent-generated emails a day. For twenty minutes he shares his screen and runs the live system, terminal on the left, agent workforce on the right. The design principle underneath all of it is one line: the best use of AI is the indirect use of AI.
His stack is Claude Code as the terminal, Relevance AI as the agent host, and MCP as the connective tissue, sitting on Databricks, Salesforce, Gong, and Apollo. The tool list is not the story. The story is that a rep triggers this entire architecture by checking a box, and is never told what happens next.
Watch now: Angelo Quiambao - AI GTM Engineer
The Context Layer: What Gets Built Before Any Agent Exists
Angelo’s first move on any build is not a build. Before a single agent exists, he maps account tiering definitions, ICP definitions, product information, and buying teams, then takes them to RevOps, marketing, and sales until the definitions are uniform across all three. Those definitions live in knowledge bases the agents pull from, refreshed daily.
His reasoning is blunt. Hand an agent zero context and the outputs are, in his word, horrendous. Teams skip this part because it looks like documentation rather than engineering, and it is the input that decides whether everything downstream is usable. His line for the market condition: companies are very data rich, because AI can pull data from anywhere, but no one is context rich. That gap separates working agents from cut-and-paste templates that may or may not fire.
The Architecture: One Orchestrator, Four Single-Job Agents
The build is hub and spoke. Prospecting, account research, contact research, and emailing are separate agents, and each one does a single process. That constraint is deliberate. An agent that makes multiple decisions creates too many areas for error, so no agent makes two.
One orchestrator sits in front of them. Its only job is to take a request, route it to the right agent, and assemble what comes back. It also holds the memory. Ask it to research an account the system already covered and it answers with what it found sixty days ago and asks whether to run it again. It tracks errors. It logs which sequence a contact is in and how many days since last touch. It writes back to the CRM as the run progresses. Deduplication is not a cleanup job at the end. It is a gate enforced before work happens twice.
The agents also outrank a plain MCP connection. He wrapped the Apollo API into an agent rather than calling it from Claude directly, which gives it decision-making power plus read and write access to Salesforce, Gong, and Databricks, instead of prompting a model and hoping it handles the response correctly.
The Live Run: Internal Data Before External Signal
Angelo types “find me some hot leads” into the terminal. The command travels over MCP to Relevance, the orchestrator wakes the workforce, and account research starts running against three accounts at once.
What the research agent does first is the decision worth copying. It checks internal data before it touches anything external. Is this an open opportunity. Is there a closed-lost history worth re-engaging. Is there first-party intent, are they on our site. Are there MQL or MQA personas on the account. Only then does it reach for third-party intent and external signal. This is exactly the work that takes a human a long time, which is why it is the work worth handing over.
Then the gates. ICP gate, duplicate check, and a pre-check for accounts already in a deal cycle. Anything that fails is blocked and logged rather than emailed. The expensive mistake in outbound is not a weak email. It is an agent emailing an account your own team is mid-deal with, at forty-rep scale, every day.
Outputs error, and Angelo treats that as normal rather than as failure. Errors get tracked, logged, and reviewed in evals at the end of the week, the same cadence a manager would run on a human rep. Personalization carries a fallback so nothing ships as AI slop when the agent finds nothing real to say. The run on screen finishes with four contacts, no flags, sequence assigned, CRM updated. He mentions in passing that it was the first live run on the new build.
The Translation Layer: Ten Words or the Build Is Wrong
Angelo reports to the CRO, historically to a VP of RevOps, and he weights the enablement half of his job equal to the build half.
His test for a build is a sentence. If he cannot describe to leadership in five to ten words what an agent does, the build is too intricate and has too many places to fail. Translation runs both directions from there. Up the org chart it becomes goals and results, down the chart it becomes process.
For the rep it collapses to a single instruction. Click this checkbox and an email to your top prospect will be in your drafts, ready to send. They do not need to know they are activating a seven-layer agent architecture, that it is deduping, that it is running Databricks research. Where reps live in Slack instead, the trigger is a natural-language message to a query agent. Same rule either way: put the trigger where they already are.
This is why rep adoption is the number one thing Angelo measures, ahead of any measure of agent capability. Agents nobody uses are useless, and occasional tinkering wastes his time and theirs. The framing he gives leadership is five times the output of one person rather than the replacement of one person, which is also the version reps can hear without going defensive.
The Numbers, and What Happens If They Go the Other Way
At Qualified the adoption curve only ran one direction. Early on the agents were a productivity boost BDRs could opt into. At peak they were mandatory, with every BDR required to send fifty agent-generated emails a day, anchoring the team’s push into enterprise accounts. The system carried its own quota, set at four times a standard BDR target, was paired with AEs like any rep, and was held to the same performance standards as the human team. On screen, four contacts were researched, gated, enriched, and queued in the time it took to explain the architecture.
The cost side is real. Scale this to a forty-rep enterprise sales team running daily and Angelo estimates burning something like ten million credits a day across Relevance and Claude. He is unsentimental about it: it generates revenue, so it is worth it, and his job is keeping the error rate low enough that it stays true. He is equally direct about the inverse. At enterprise scale, agents that do not work do not merely waste money, they generate errors that cost the team more time than they saved. That is why he keeps returning to context, and why he says you cannot automate something you have not done yourself.
Where This Goes by the End of September
Angelo is two months into the role and calls the current architecture a first version. He expects it to look different by the end of September, and floats the possibility that the whole thing collapses into one agent. That is not a walk-back. It is what happens when the underlying models absorb the orchestration you had to hand-build a quarter earlier.
His prompting rule survives that shift, because it is architectural rather than tooling-specific. If you want lazy prompts, the system needs to be intricate, and not the other way around. Lazy prompt plus no context gives you bad output. Lazy prompt plus an intricate, context-loaded system is the entire point. Nobody wants to write structured prompts, so the structure has to live somewhere else.
The Pattern
Every team building GTM agents is solving for capability. Angelo is solving for who has to understand the thing.
That reframes the whole build. If the rep has to learn your agent, you have shipped another tool into a stack they already resent, and adoption decides the outcome no matter how good the architecture is. If the rep never meets your agent, the complexity budget moves entirely to you, which is where it belongs, and the only thing they experience is a draft appearing in their inbox after a click they already knew how to make.
The measure of a GTM agent is not what it can do. It is how little the person triggering it needs to know. If your reps need training to use your AI, the architecture is backwards.
Seven Things Worth Stealing
The best use of AI is the indirect use of AI. Reps do not operate agents, they trigger them from wherever they already work. Every hour you spend teaching a rep your interface is an hour that says the interface is wrong.
If you cannot describe an agent in ten words, the build is wrong. Angelo’s test is for leadership, not for engineers. An agent that needs a paragraph to explain has too many decision points and too many places to fail silently.
No agent should make two decisions. One process each, one orchestrator in front. Multi-decision agents feel efficient to build and become impossible to debug once they are running against live pipeline.
Deduplication is a gate, not a cleanup task. The orchestrator remembers what it researched sixty days ago and asks before repeating it. Systems that dedupe after the fact have already spent the money and, worse, already sent the email.
Internal data before external signal. Open opportunities, closed-lost history, first-party intent, and MQL personas get checked before any third-party source is called. Reversing that order is how an agent emails an account your team is mid-deal with.
Agents get managed like reps, evals included. Errors are expected, so they are tracked, logged, and reviewed weekly on the same cadence a manager reviews a human. Personalization carries a fallback so nothing ships as slop when there is nothing real to say.
Lazy prompts require intricate systems. Nobody wants to write structured prompts, so the structure has to live somewhere else. Lazy prompt plus no context gives you garbage. Lazy prompt plus a context-loaded system is the entire point.
Timestamps
(0:00) Meet Angelo Quiambao
(0:38) The stack: Claude Code, Relevance AI, MCP
(3:10) Context before agents: tiering, ICP, buying teams
(4:28) The orchestrator and its 60 day memory
(6:01) Why rep adoption is the number one metric
(7:54) Seven layers behind one checkbox
(9:46) Live run: internal data before external signal
(11:30) Wrapping the Apollo API into an agent
(15:05) Credits versus revenue at enterprise scale
(16:24) Data rich versus context rich
Links
Follow Rick on LinkedIn - https://www.linkedin.com/in/rickkoleta/
Follow Angelo on LinkedIn - https://www.linkedin.com/in/angelo-quiambao
Try Intellistack - https://www.intellistack.com/
Previous episodes include
If this was useful, hit like and restack at the top of the post.
Show Me Your Stack is a GTM Vault series. Each episode features one operator walking through the system behind their outbound, their prioritization, or their pipeline motion. No slides. Just the stack.