Using an AI Agent to Monitor Customer Job Changes: A Sales Team Automation Case Study

An MCP + Claude + HubSpot agent that monitors job changes for sales leads — the hard part is defining what counts as a valuable signal.
A B2B sales team member shared on Reddit how he built a job change monitoring agent: it automatically pulls role change data for ~400 contacts via Coresignal's MCP interface, has Claude evaluate each change against ICP criteria, and creates follow-up tasks in HubSpot when there's a match. The technical build was straightforward — the real effort went into defining what makes a job change worth acting on. A lateral move and a promotion to VP at a new company carry very different sales value, and getting Claude to distinguish them reliably took multiple rounds of iteration. The key lesson: in agent deployments, judgment quality depends entirely on how clearly you define your criteria.
A Simple But Powerful Sales Use Case
In B2B sales, when a contact changes jobs, it often signals a new opportunity. A familiar face moving to a new company or getting promoted can reopen a sales channel you thought was closed. The challenge: manually tracking job changes across hundreds of contacts is simply not practical.
A Reddit user shared the "job change monitoring agent" he built for his sales team — a clean, low-cost solution. The agent runs automatically every morning, pulls job change data from a data source, cross-references roughly 400 historical contacts and target accounts, and automatically creates follow-up tasks in the CRM whenever it detects a role change that fits the ICP (Ideal Customer Profile).

Tech Stack: MCP + Claude + HubSpot
The system's architecture is straightforward. The data layer uses Coresignal's MCP (Model Context Protocol) interface to fetch job change signals — one of the most common ways today to connect LLMs to external data sources. The reasoning layer is handled by Claude, which reads the role changes and decides whether they're worth acting on. The execution layer connects to HubSpot, automatically generating task cards that include the contact's name, previous role, new role, and suggested outreach angle.
The author admits that building the agent itself "wasn't that hard." This reflects a broader trend: as standardized protocols like MCP become more widespread, the engineering effort required to connect LLMs to business systems is dropping fast. The real challenge isn't getting things connected — it's getting the judgments right.
What is MCP? Model Context Protocol is an open standard introduced by Anthropic in late 2024, designed to give large language models a unified way to connect to external tools. Before MCP, every company integrating an LLM with a database, API, or business system had to write custom integration code from scratch — expensive to build and hard to maintain. MCP works like a USB standard: as long as a data source exposes an MCP-compliant server, any MCP-compatible client (like Claude) can read and write to it directly, without custom glue code. Coresignal, a provider of professional data including LinkedIn-mirrored records and job change signals, exposes an MCP interface so Claude can query it directly — no manual API auth or data formatting required. This is exactly why the author described the build as low-effort: the protocol layer has already eliminated most of the plumbing work.
The Hard Part Is Defining Standards, Not Writing Code
What actually consumed the most effort was defining what counts as a meaningful job change.
This matters a lot. The same "job change" label can mean very different things:
- Lateral move: Staying at the same seniority level within a company — usually low sales value.
- Joining a new company as a VP: Typically signals new budget authority and decision-making power — a high-value signal.
Getting Claude to consistently distinguish between these two cases required several rounds of iteration before it was production-ready. This points to a core lesson in deploying agents today: the quality of an LLM's judgment depends heavily on how clearly you define the criteria. Vague rules produce inconsistent outputs, and once a sales team starts receiving a flood of false-positive tasks, they lose trust in the system fast.
Why Defining Criteria Is So Difficult
The "value" of a job change is fundamentally a business judgment — it involves company size, seniority level, industry, and fit with your product, all at once. Translating this kind of implicit sales intuition into rules that an LLM can understand and apply consistently requires repeated testing and calibration. This is why the author ended his post by asking the community: what does your criteria-definition process look like when building systems like this?
What is ICP? Ideal Customer Profile is a B2B sales framework that describes the characteristics of prospects most likely to convert into high-value customers. It typically includes dimensions like company size, industry, tech stack, geography, budget range, and the seniority of key decision-makers. Unlike consumer persona work, ICP focuses on organizational-level fit rather than individual attributes. In the context of job change monitoring, ICP criteria directly determine whether a given role change warrants outreach. For example, a contact who was an engineer at a small startup and just joined a 500-person company as VP of Engineering might simultaneously satisfy "target industry," "decision-maker level," and "budget potential" — making it a high-value signal. Translating this multi-dimensional judgment into a prompt that Claude can apply reliably is precisely where most of the iteration cost lives in this case.
Takeaways for Building Similar Systems
A few practical lessons from this case:
- Start with a small dataset: 400 contacts is enough to validate the value without letting noise overwhelm the results.
- Make your logic explicit: Rather than hoping the model will "figure it out," break down your ICP criteria into describable, example-driven rules and guide the model with few-shot prompting.
- Close the loop into existing workflows: Writing results directly into HubSpot — rather than generating a report someone has to process manually — is what actually reduces the sales team's workload.
- Build in room to iterate: Criteria won't be right the first time. Treat human review and feedback correction as a permanent part of the workflow, not a temporary fix.
Conclusion
The value of this case isn't in the sophistication of the technology — it's in the practical AI application pattern it demonstrates: use off-the-shelf protocols and a capable LLM to solve a specific, high-frequency business problem with a clear ROI. When the cost to build is low enough, the competitive advantage shifts to how well you understand your own business rules. For sales and operations teams exploring AI in the real world, this "light on tech, heavy on logic" approach is well worth taking seriously.
Related articles

OpenCode Complete Guide: Installation, Configuration & Practical Usage
A complete guide to OpenCode, an open-source AI coding tool: desktop and WSL installation, model and rule configuration, agent types, custom commands, MCP integration, and Agent SQL reuse.

Can Multi-LLM Dialogue Really Improve Task Performance? Lessons from a Rigorous Experimental Design
A researcher designed rigorous controlled experiments to isolate whether multi-LLM back-and-forth dialogue genuinely outperforms simpler baselines like self-refinement and one-way sharing.

Which $10 AI Coding Plan Should You Choose? Go vs. Code Credit Breakdown
After DeepSeek's price hike, should you pick Go or Code for your $10 AI coding plan? We break down credit allocations for Mimo, Qwen, DeepSeek V4, Kimi, and more.