Library/Show Me Your Stack 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
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.
Figure 1. One checkbox, seven layers, one draft. The rep sees two surfaces, the trigger and the finished draft. The seven layers between them, webhook, orchestrator, four single-job agents, and the sequencing and logging step, are never surfaced. The complexity is not reduced, it is relocated.
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.
Figure 2. Internal data before external signal. Most research agents open with third-party intent. This one opens with what the company already knows, then gates on it, which turns research into a filter rather than a report. The system’s main job is deciding who not to contact.
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.
Full transcript
Machine-generated transcript from the episode video. Speaker labels are not included and some names and product terms may be transcribed phonetically.
[0:02] Welcome back to GTM Vault. Today we have Angelo Kimbao on the show. Experienced seasoned GTM engineer. He's going to be walking us through a couple different workflows he's built. So, Angelo, welcome. Thanks again. I mean, yeah, thank you for having me. Excited to be here. So, what do you want to show us first? We've built a number of systems. Definitely some end toend outbound workflows. I think it'd be nice to kind of dive into Outbound as a whole, but essentially how we've built agents to kind of speed this process up. So, let me share my screen here. So, we have the terminal on the left and then we have our full agent architecture. This lives within relevance AI, which is a agent hosting platform. Um, like any outbound rep, if I were to start my day and try and find some hot leads, that's the first thing I would probably tell the terminal, find me some hot leads.
[1:00] And what that's doing is sending a command here to relevant AI to run account research, contact research, um, integrated with data bricks, salesforce, all our go to market systems. I like to have curated list already built out whether you check a dashboard or report. um that lives within Salesforce. Um these live within here within our knowledge bases um and these get updated on a daily basis. You can you uh can you explain to our viewers what you mean by um by so you have cloud codes terminal open, right? Correct. And um and and can you break down how to use relevance AI within cloud code?
[1:43] Sure. Yeah, good question. It's all done via MCP. Um, cloud code is sort of the connector with all the MCP access, but these are where the agents live and get orchestrated. Um, I like this platform better than running the agents via cloud because well, the UI is a bit cooler, but also the integrations to more go to market systems. Um, and each agent can be hub and spoke do one singular process. Um, and all these knowledge bases don't have to live in a cloud project. they can live in knowledge bases within the platform and agents can pull and take what they need. Sweet. So, we ran our run here and it pulled from our curated list. You can see on the left, these are all people from defined tier one accounts um different companies that we've been looking at and then give it giving us the reasoning for why we should outreach to them, right? um if we want to run it and then I would just say run it run the full workforce which means every agent on the right here will
[2:46] be activated and we'll all get outputs on what that looks like and um how do we know what contact at those accounts to to to contact? Yeah, good question. Right, it's all about pre-nowledge, pre-context and definitions of what is good versus what you want. Um, if I were to tell this to an agent with zero context or nothing, like the outputs would be horrendous, right? Like before I build any of the agents, we make sure that one account tiering definitions, ICP definitions, the product information, our buying teams, these are all mapped out aligned with RevOps and marketing and sales so that it's uniform across and then we can build curated dashboards whether they live in data bricks or Salesforce and then send that over to the list here whether it's CRM GTM brain like this list right here gets updated daily then the agents will pull from here.
[3:42] And um where do these instructions live that are connected to uh cloud code in cloud or within relevance? Um I I I guess they they uh they're an input into relevance, right? Not correct. Yeah. So they would be here um in the operating procedures of we have one orchestrating sort of agent. Its only job is to take information, send it to the other agent, and then put everything together. Also acts as the mediary between Claude and relevant here. Uh when they speak through the MCP. So when I speak to the agent, I'm essentially speaking to the orchestrator. Like if I just want account research, this one will only give it to the account research, not the full agent run. Um, if we've already researched an account, this orchestrator has a knowledge base of the ones we've done, will tell me, hey, we already have research done like 60 days ago. This is what we got. Do you want to run it again? Um, it tracks for errors.
[4:42] Um, and then also updates CRM. Um, if it errored, what sequence, how many days since we've last reached out, and any other relevant information as uh the run goes along. So yeah, that is that lives here and then gets filtered down downwards to our prospecting agent, research agent, account research, and then our emailing. Awesome. Right. So we have this running in the background and most days it's a couple of these terminals up running different sorts of workflows. Um, and it's sort of like a new way to work as opposed to the traditional you build a list manually on sales nav or look in Apollo or make a filtered list and zoom info and then you have to research it, put them in a sequence and then manually research each of them. Um, I think the time that this saves is not more so to replace reps, but more so to um enhance and optimize the the outputs of them. Right? we can 5x the output of one person rather than replacing one person. That's a lot better. Um and that's what we did at
[5:44] qualified where we saw a lot a lot of success. Um I think it these agents became around 60% of the BDR workflow um daily. Um so yeah, it's big once these get integrated, right? And that's the key thing. If reps are not using your agents, then to me they are useless, right? Rep adoption is probably the number one thing that I measure. If people just kind of tinker with it here and there, it's a waste of your time, waste of their time, but everybody using it. High output, high value. And Angelo, tell me this. Uh, who's, let's say, you you who do you report to within the, uh, organization in most cases? Um, historically VP of revenue operations, anyone in GTM, but currently uh, R CRO CR. Okay, got it. So either um mo mostly the revenue in most cases it sounds like it's like the revenue leader um and so uh in that case is it then the revenue leader's responsibility to kind of
[6:48] mandate that all reps learn how to use uh the agents that you build them? Do you do you like onboard each rep or spend one-on-one time kind of showing them how to use it? So, how does that whole process work? Yeah, it's a good question. And I think that would I would say that's the other half of my job. It's setting expectations, setting processes, and obviously enabling the other members of the sales team. But I always like to say, and this is what I tell our leaders, it's like the best use of AI is the indirect use of AI. So, we want this fully integrated. We want every rep using it, but we don't want every rep knowing every in and out of this. Like, if I can't describe to our leadership in five to 10 words what this agent does or what the workforce does, it's not a good build. It's too intricate or has too many areas where it could fail, right?
[7:42] So, when describing it to AEES, we integrate this with the their daily workflow. So, if they're in Salesforce every single day, we'll create a web hook or I'll create a web hook within Salesforce where they just click a checkbox. They don't need to know they're activating a seven layer agent architecture and it's dduping and it's doing data bricks research and they don't need to know any of that. They need to know that once they click this checkbox, an email to their top prospect will be in their drafts ready to be sent. And that's essentially how we translate it. And there's multi layers to translating what I'm doing to whoever I'm speaking to, right? Like as we go up, it needs to be more goal focused measures and results. as we trickle down more process focused more quarterly and company focused like how are we going to hit our goals so yes enablement's a big thing but also setting expectations and then the reality of how to use it um needs to be as easy as possible I could see that yeah and tell me this how what kind of an interface does the rep get um to check the box
[8:47] um yeah this can be done a number of different ways right um I'm still in the V1 one versions of my new build as I just joined the team here at Intellis. But you know in my previous role we had it via Slack where you can chat interface um any of our query agents like our Salesforce agents, Apollo agents, Zoom info agents like you can query them with natural language via Slack or we had those Salesforce checkboxes for a sales team enterprise sales team that's most likely going to be Salesforce it sounds like. But as of now, I I would say Slack, right? Like I think Slack is becoming prominent in where everybody lives and everyone wants to stay in one platform. Um so we'll see. Um the easier the better I would say. So we ran these from terminal and we can see that it's running the account research at the same time. So we have Meridian, Acme, Starburst and if we can if we want to see the output of this um you can see here. So what it did was here we go. Yeah. The most important thing that I want the agent to do is to
[9:49] check our internal data and then find external data so that I can guide it. Right? That's what takes humans a long time to do is what do we know internally and then the external research. So is this an open opportunity? Nope. Do we have any closed lost opportunities with these? Can we re-engage these folks? Right? What are the signals externally? Third party intent. Do we have any firstparty intent? Right? Are they on our website? Do we have any MQL MQA personas here? And that's what this does. Then it creates um sort of an output here and sends that to the final one. If it errors, which is fine, like uh outputs will error. We track those. We log them and we do eval uh similar to like a human rep. But if they pass and we can see these have passed any of the ICP gates um duplicate checks or any other um pre-check gates that we have in um inputed that indicate that we should not reach out to this account. Maybe they're already in a deal cycle, right? We don't want to reach out
[10:52] to them. These will catch for that and then log it the next process. Got it. Yeah. And um so it would log it uh in it. It would log it and additionally update the CRM in real time. Exactly. Yes. Awesome. Yeah. So after account research, of course, we're going to build out an account. We use Apollo. So Apollo um also connected to Cloud via MCP, but also connected to relevance via API can run um building out a buying team. And essentially this agent, I'll just backtrack a little bit to show what this agent looks like. I've wrapped the Apollo API and resource docs into this agent essentially the MCP with decision-making power now and the benefits of having this agent as opposed to using cloud MCP is that this agent's connected to Salesforce Gong data bricks and can actually read and write within those systems um as opposed to prompting claude to do it. So that's powerful.
[11:54] Well, let me ask you this. Um, as as signals come in real time, how frequently are you pushing this uh these signals to the reps? How accessible is it to them? That's a good question. Um, these are accessible to the reps at any time of day. So, you know, with the screenshot example, it's more so like I'm looking on LinkedIn as a rep and like, oh my gosh, I should reach out to them. screenshot, boom, send or get some info and then use the agent, go send. But in good practice, you know, you want that pipeline generation motion always moving. So the lists that it's going after in the morning are always pre-curated the day before and then the follow-ups are also being sent throughout the morning throughout the day. Um, and then net new is being added as you go about your day, whether you're maybe you speak to someone internally or you're having a customer call. Those can be done at any point in the day. But the web hooks are the beginning and at the end of the day to prospect for the next day. These are all living within data bicks uh dashboards that we've made. Um
[12:57] can't show them necessarily, but like we have a genie agent that lives within data bricks. this um the relevance agent will then query the genie agent and I've prompted the genie agent to understand when it gets this prompt from relevance it needs to find xx next living within all of our other go to market systems before I would want a system that's AI enabled for humans to kind of tinker around in but as I continue to build for the future I only want systems that um that can prove agentto agent communication genie to relevance to Claude where we take only the human gates in the loop for my decision-m or these agents have my decision-m power so they know what is good what is bad in the form of context and skills um so yeah so basically all of that data lives within data bricks got it awesome yeah so let's go back here really quick we'll finish the run like Apollo the Apollo agent will build out the team um based
[14:00] upon our ICP and buying team for the account who's not from Salesforce who's been worked, see if we can find any net new contacts. From there, it'll enrich it. Um, add it to our curated list, and then we can see the final output right here. No flags. I make sure it kind of explains every single step. You know, reps won't live in this UI. It's mainly for me in case something goes wrong. So, yeah, four contacts done. It knows to now send these emails, put them in a sequence, log this, see, and we have different plays associated with it. Um, whether they're a new hire, um, let's see what the other one did. It's actually first live run I've done on this, right? And there's always going to be times where we can't find something to personalize, but it will, it has its fallback mechanism so that we don't just send AI slop out there into the world.
[14:50] But sure, just a lot of planning that goes into every single stage of the reiteration here. But yeah, this is done for four people. Now imagine a 40 rep enterprise sales team running this every single day. Um, you know, we're burning through maybe like 10 million credits a day. Um, this is within relevance claude millions and millions, right? But it generates revenue and I think that's like the most important thing, right? and it's my job to make sure that these errors stay very minimal and that the tasks continue to flow and everybody will be happy. Um but yeah, a lot a lot of work. Yeah. No, that's great. And the impact it has uh on the sales pipeline is is got to be immense. I mean, you could probably calculate the um influence that GTM engineering is having on uh the sales pipeline one way or the other,
[15:53] right? And it it could go the other way, right? Like if these don't work and we account for it on the enterprise scale, um it's a lot of money, a lot of money that would be lost, right? And a lot of time, right? it would actually create more errors in time for the team which is the opposite of what you want to do. That's why I always stress like it's very important to know the context, know who you're selling to, know the job like you can't automate something. I feel you can't automate something that you have not done right. Yeah, absolutely. It's all about the architecture. I think a lot of companies these days are are very data rich because of AI. So we can find and pull data from anywhere but no one is contextrich and those that's really what separates the working real agents versus like you know cut and paste templates that may or may not work right absolutely cool the way I think about it it's like I use the agents to one build list to research and then three outreach so it's like depending on how every organization does that like these agents can do
[16:57] the same thing right so if we can ask it something like, "Find me the best 50 contacts um that I can reach out to or or I should that I should reach out to and why." And these vague sort of prompts are like the whole like idea of it because no one wants to like structurally prompt it, right? And I'll tell every I'll tell all of them out there everyone out there like if you want to do lazy prompts, the system needs to be intricate and not the other way around. So you have lazy prompt, no context, you're going to get bad outputs. So yeah, that's a really good point. Our viewers should take note of that, right? And the way you orchestrate it and it's just I don't like making more time for myself than I have to, similar to everyone with AI agents, but that is a loop that people can go down in. Like I think the best agents that I've built while that's running in the background is lazy. I mean, they're all they all do one singular thing. Do not have agents that do multiple decision-making layers.
[17:57] um because there's there's too many errors areas for error. Um but this is just the first version of this because what I'm two months into my role right now and I think as you've known like the building has changed since the last time you know I was in a role actually building V1. So I'm also learning a lot of the new go to market techniques. Um but also incorporating what was good about my last builds. And I think if you check back in with me probably end of September, this whole architecture right here will probably look different. There'll probably be one agent or something. Who knows, right? I don't know. U but I think it would be fun to see. Yeah. Yeah. Yeah. Let's do that. Let's keep in touch. Angelo, thanks so much for coming on the show.
[18:39] My pleasure. Thanks for having me. All right.