The Connected Tissue: Who Else Gets Touched When You Deploy an Agent? (Part 1 of 2)

Part 6 of 7 · Agentic SaaS Blueprint series

A refund gets issued. A discount gets applied. A loan gets declined. Three weeks later, someone asks why, and the honest answer ist hat nobody can say cleanly whether a person made that call or an agent did. Not because anyone hid it.Because the workflow was never built to tell the difference.

That gap is this article's real subject. Pricing (Article 3) treated attribution as a billing problem: can you prove what the agent did well enough to charge for it? This piece treats it as a trust problem: can the next person in the chain see what happened well enough to be accountable for it, before they act on it, not after?

Architecture told you what's possible. GTM told you who buys it. Pricing told you what to charge.This one is about who lives with the decision, every day, long after the deal closes.

The Impact Spectrum: Replace, Assist, Compress

An agent's effect on a role isn't one thing. I think about it as three distinct patterns, and they carry three different trust profiles with the people affected.

Replace - the role goes away. IBM's AskHR agent now automates 94% of routine HR tasks, and CEO Arvind Krishna confirmed to the Wall Street Journal that AI took over the work of hundreds of HR employees, with savings redirected into hiring elsewhere. (Entrepreneur, reporting the WSJ interview) Worth being precise here: a widely circulated claim that IBM replaced 8,000 HR workers is an exaggeration. 8,000 was Krishna's five-year hiring-pause estimate for automatable roles, not an actual layoff count. Precision matters more, not less, when the topic is people's jobs.

Assist - the role stays, output per person rises. A GitHub- and Accenture-backed controlled study of 4,800 developers found 55% faster task completion with Copilot. (Quantumrun) Nobody’s job disappeared; the ceiling on what one person produces moved.

Compress - same role, fewer people or hours doing the same work. Salesforce CEO Marc Benioff said the company's support headcount dropped from roughly 9,000 to 5,000 as Agent force absorbed 30-50% of the workload. (Tech.co) The role still exists. Fewer people hold it, or hold it at reduced hours.

Assist is the easiest sell internally; nobody's position is at stake; the story is pure upside. Replace and Compress are where resistance concentrates, and conflating all three into one undifferentiated "AI impact on jobs" conversation is itself a source of distrust: people can tell when the category they're actually in is being obscured. There's also a reason Replace and Compress are harder to execute cleanly than they look on a roadmap; a role is rarely just a task list, and the next section is about why.

Who Decided vs. Who Lives With It

The person who approves an agent deployment is rarely the person whose daily work changes because of it. A department head or CFO signs off on the business case; the practitioners downstream absorb the consequences. That split is worth making explicit, because it's the mechanism behind almost everything in this article: it's why resistance concentrates in specific roles rather than spreading evenly, and why accountability tends to default to nobody unless someone deliberately assigns it.

A simple RACI mapping makes the default failure visible. Take a common real deployment: an agent that auto-approves customer refunds under a dollar threshold:

The gaps in that table aren't hypothetical; they're the default state of most agent deployments today. Someone is accountable for the threshold. Almost nobody is accountable, by default, for the individual action the agent takes inside that threshold, or for auditing the pattern of those actions later. RACI isn't a governance formality here; it's the difference between a deployment with a name attached to each row and one where the answer to "who's accountable" is whoever happens to be in the room when something goes wrong.

The Connected Tissue: Ripple Effects Across Roles

An agent deployed in one role touches roles that never approved the deployment. This is the point I've made on the CSM track for a while, and it's worth making concrete rather than abstract: take a Customer Success agent, built for a single job-to-be-done: retain and grow the account.

That one JTBD sits on top of four functions the CS org doesn't own. RevOps owns the CRM data the agent reads and the pipeline it writes back to. Finance owns the renewal approval the agent's recommendation feeds into. Product owns the usage signals the agent's health score is built from. Legal owns the contract terms the agent has to stay inside of, and can't contradict. None of those four teams signed off on the CS deployment. All four are now load-bearing for whether it works.

This is exactly why you cannot automate a CSM, or any persona, overnight. It isn't one job to-be-done wrapped in a model; it's four negotiated relationships, each with its own data owner, its own approval gate, and its own definition of what "done well" looks like. Replacing or compressing the role means renegotiating all four at once, not shipping a single well-trained agent. Teams that treat this as a one-role automation project discover the other four stakeholders the hard way, usually after launch.

Deterministic vs. Non-Deterministic: Why Visibility Has to Come Before the Fact

Not every agent action carries the same risk, and the dividing line is whether the action is deterministic or not. A deterministic action applies this discount code, routes this ticket by category, and has a fixed rule behind it: same input, same output, every time. It's auditable by inspecting the rule. A non-deterministic action, such as - should this loan be approved or should this claim be escalated - involves the agent exercising judgment under ambiguity, the same kind of day-to-day judgment call a human employee used to make alone. Outcomes vary, and you can't fully audit them by inspecting a rule, because there isn't one in the same sense.

This distinction is what should set the level of oversight, and most organizations don't make it explicit that they apply the same light-touch monitoring to both.

Which brings up the deeper design question: does the system need to reconstruct who did what after the fact, or does it need to show, before the nextstep happens, that a given action was agent-driven and how severe the call was? I'd argue the second is the actual target, and most systems today are built for the first. Forensic traceability answers "what happened" for a post-mortem. Upfront visibility answers "should I proceed, validate, or escalate this" for the person about to act on the agent's output: a claims adjuster deciding whether to countersign a payout, a sales manager deciding whether to approve a proposal the agent drafted. Gated by severity, not logged for later.That's a different design goal, and it's the one that actually protects the next stakeholder in the chain rather than just explaining what happened to them afterwards.

Bias, Fairness, and the Limits of Explainability

There's a category of risk that neither post-mortem attribution nor upfront visibility fully catches on their own: a pattern that's invisible in any single transaction and only shows up in aggregate. Bias is the clearest version of this.

In July 2025, the Massachusetts Attorney General reached a $2.5 million settlement with student loan lender Earnest Operations over its AI underwriting model. (Debevoise Data Blog) The model used a “Cohort Default Rate” the average default rate of applicants from a given school as a scoring input, which disproportionately penalised Black and Hispanic applicants, and an automated "Knockout Rule" that denied noncitizen applicants outright. No single denial looked wrong on its face.The pattern only became visible when someone looked at outcomes across the whole applicant population, and it isn't an isolated case: Navy Federal Credit Union is fighting similar disparate-impact claims in federal court over a documented racial gap in approval rates.

This is why explainability and upfront visibility aren't the same tool. Visibility tells the next stakeholder that an action was agent-driven and how severe it is. Explainability tells you why the agent decided what it decided, and fairness auditing requires a third layer on top of both: looking at the agent's decisions in aggregate, across a population, for a pattern no individual case would reveal. A lending agent, a hiring agent, an eligibility agent anywhere an agent is making a non-deterministic judgment call about a person at scale - needs that population-level audit built in from day one, not bolted on after a regulator asks for it.

Agent-to-Agent Collaboration and Compounding Risk

The risk surface changes shape again once agents start handing work to other agents across team and department boundaries. A sales agent's output feeds a finance agent's forecast, which feeds an operations agent's resourcing call, which feeds a reporting agent's summary a leadership team uses to decide strategy. Each handoff can compound the last agent's error without a human checkpoint in between.

A single misjudged classification early in that chain doesn't stay a single misjudged classification; it becomes an input into three more decisions before anyone with the authority to question it ever sees it. It's worth naming, if only briefly, that the people affected by where that chain ends aren't always inside the org chart at all: a facilities team whose staffing plan came from that resourcing call, a community whose services depend on the funding decision it informed. That's the shape of the risk surface: one deployment, a widening circle of people who never approved it, and errors that travel faster than anyone's ability to catch them. Which raises the harder question: not how to make agents safer inside that surface, but where the surface should have edges. Where an agent shouldn't goat all, and what it takes to earn back trust when one goes wrong.