# One candidate, three systems, and the questions none of them can answer A talent context graph example, walked through hire, ramp, and retention: the same candidate, told once by three disconnected systems and once by one connected graph. > By Saad Bin Shafiq, Founder of Nodes ยท Aug 13, 2026 > Canonical: https://www.nodes.inc/blog/talent-context-graph-example **Answer:** A talent context graph connects what a screening tool, an engagement platform, and a scheduling agent already produce about one candidate into a single record inside the company's VPC. None of the three systems is replaced. Each one's data becomes a node or edge the others can query, so a decision made in one system stays visible to the next. --- A screening tool scores a candidate against a job description. An engagement platform tracks how that candidate responds to outreach and how a new hire responds to onboarding nudges. A scheduling agent finds calendar slots and confirms interviews. Every one of those three systems does its job well, and every one of them answers only from its own database. Ask the scheduling agent why a candidate accepted an offer and it has nothing: it never saw the interview scores. Ask the engagement platform whether the candidate it nudged through onboarding is now a top performer and it has nothing either: it stopped watching the day the account went quiet. Three systems touched one person on the way from application to production, and none of them can tell you the whole story, because none of them were built to. ## Why three specialist systems make sense Nobody built it broken on purpose. A screening tool that also tried to run calendar logistics would be worse at screening. An engagement platform that also tried to score technical skill would be worse at engagement. The scheduling agent's entire value is that it is fast, narrow, and does not need to understand anything about the candidate except availability. Specialization is why each piece works well on its own. A recruiting stack assembled tool by tool, one specialist for each job, is not a mistake. It is the same discipline that puts a scheduling app next to a CRM next to an assessment platform in every other function of the business, and it produces better screening, better nudges, and better logistics than one system trying to do all three at once. The failure is not in any one system. It sits in what happens the moment a question needs an answer that spans two of them, and there is no shared record to draw on. That gap never shows up on a vendor scorecard, because no single vendor is responsible for it. ## What a talent context graph actually connects A [Talent Context Graph](/blog/what-is-a-context-graph) does not replace the screening tool, the engagement platform, or the scheduling agent. It reads what each one already produces and writes it into one connected record, inside the company's own VPC, so a question that spans all three systems has an actual place to be answered. The graph is built from nodes and edges, not tables. A candidate node carries every score, every interaction, and every scheduled and completed interview for that person, pulled from all three systems at once. A role node carries the success profile the candidate is being screened against and the performance history of everyone who has held that role before. A decision node captures who advanced or rejected the candidate at each stage, and why, including any override of the model's score. An edge connects the candidate to the pattern of behavior the model detected. Another edge connects that pattern to the role it predicts success in. A third connects the role to the employee record the candidate becomes if hired. Concretely: the screening tool's Fit Score becomes one property on the candidate node, held alongside everything else that node knows, rather than a number that lives and dies inside the screening tool's own dashboard. The engagement platform's response pattern, how quickly the candidate replied, which nudges worked, becomes an edge between the candidate node and a behavior pattern, held where the next query can reach it, rather than an engagement metric nobody outside that platform ever sees again. The scheduling agent's record of who rescheduled twice and who showed up early becomes part of the same candidate node, carried forward past the close of the requisition, rather than a logistics footnote that expires when the req closes. None of this requires the three systems to talk to each other directly. [Decision Traces](https://arxiv.org/abs/2604.19819), the methodology behind the graph, capture that context at decision time, inside the customer's own VPC, and write it once into a structure a human or a model can query later. The candidate's data never has to leave the environment it was collected in for the graph to connect it. A human approves, edits, or declines every decision the system proposes before it acts, the same control that governs everything else Nodes touches. The graph does not change who is accountable for the call. What changes is the question you can ask afterward. The graph already holds the answer to: which candidates the screening tool ranked lower than the panel did, and what happened to them six months later. Which onboarding nudges the engagement platform sent to people who are now top performers, and which ones it sent to people who left inside a year. Whether the candidates who rescheduled twice through the scheduling agent ramped slower than the ones who did not, once ramp is measured against the role node's success profile instead of guessed at from memory. ## One candidate, told two ways Follow one candidate, call him Alex, through a claims-operations role at a mid-size insurer, first through the disconnected stack, then through the graph. Disconnected: the screening tool scores Alex 72 out of 100, below the role's typical cutoff, because his resume shows two years of retail-claims-adjacent work rather than the specific line of business the requisition lists. A recruiter overrides the score and advances him anyway, on the strength of a phone screen, but that override lives in a note field nobody outside the ATS ever reads again. The engagement platform sends Alex the standard onboarding sequence for his level, the same one it sends everyone, because it has no way to know he came in as an exception. The scheduling agent books his ramp check-ins on the default cadence. Six months later Alex is a top performer, and the only system that could explain why is the recruiter's memory of one phone call, already fading into "I just had a good feeling about him." Connected: the same override gets written into the graph the moment the recruiter makes it, as a decision node linked to Alex's candidate node: score 72, recruiter override, stated reason, interviewer confidence. The engagement platform's onboarding data and the scheduling agent's ramp-cadence data both attach to that same candidate node instead of sitting in two systems that never compare notes. At six months, Alex's performance data closes the loop: this override was right. That decision trace, and the pattern behind it, becomes queryable against every other override the same recruiting team has made. A pattern emerges: adjacent-industry claims experience keeps outperforming a narrower resume match for this role, across a dozen candidates who all took the same kind of override to get hired. The connected version does not predict anything the disconnected version could not have predicted. Both stacks end up holding the same underlying facts. The difference is that one of them turns those facts into something the next recruiting decision can draw on, and the other lets them evaporate the moment the phone call ends. ## What to ask before you buy the words "talent context graph" Every vendor in this category will use the phrase. Not every graph is one you can inspect. Four questions separate an inspectable graph from a marketing label. Where does the connecting happen. If the answer involves the candidate's data leaving your environment to be joined in a vendor's cloud, ask what happens to that copy when the contract ends. A graph built on [architecture that keeps data resident in your own VPC](/architecture), with no data egress, does not raise that question, because there is nothing to unwind. Can you pull one decision, fully. Ask the vendor to show you a single override, from score to reasoning to outcome, on a live record. If the honest answer stops at "we log the score," the graph is a reporting layer wearing a graph's name. Who approves before anything acts. A graph that surfaces a pattern is intelligence. A graph that changes a workflow without a human signing off first is a different category of risk, sold too often under the same word. A human should approve, edit, or decline every action before it executes, on every workflow the graph touches. What happens to the graph if you leave. If the vendor's answer is that the connected history disappears with the subscription, you were renting a report. Ask what you keep, and in what form, if the relationship ends. None of these four questions requires a technical background to ask, and none of them has a good answer from a vendor selling a dashboard with a new name. ## The second telling is the point Three well-built systems watching one candidate will always produce three separate stories, because none of them was built to remember the others. That is not a flaw in any of the three, and it is not a reason to replace them. The screening tool still screens. The engagement platform still engages. The scheduling agent still schedules. The graph is the fourth thing: the one that only listens and connects, so a recruiter's good instinct about Alex becomes something the next recruiter can query, instead of a phone call nobody wrote down. [The mechanism behind that connecting](/blog/how-decision-traces-turn-your-ats-exhaust-into-a-talent-context-graph) is its own piece; this one was just Alex's version of it. ## Sources - [Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring](https://arxiv.org/abs/2604.19819) --- *Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: [Decision Traces](https://arxiv.org/abs/2604.19819).*