Hold the write-static-code guardrail at the 98 percent it actually buys - concede the escape case publicly and still refuse to mandate replacing third-party MCPs

September 2, 2026 at 11:57 PMtechnicalhigh

Situation

At the 9/2 engineering all-hands Peter clarified the missive he had sent two weeks earlier about writing static code rather than pointing Claude at an MCP server. He gave the concrete failure it came from: someone stood up a Claude skill pointed straight at the HubSpot MCP server, and it deleted an org worth of data and 14 customers. The rule he wants: have the AI write Python or JavaScript, scope the token to exactly what that script needs, and let the skill know only that the script exists - not that the MCP server does. Jamin Collins pushed back hard and correctly - an over-helpful agent will eventually route around any tool that is not an actual guard, and once it learns it can, it will stop using the guard entirely. Peter conceded it in front of the whole org twice - he is right, he is completely right - and then held the line anyway: I do not think it is worth throwing out a pattern that works 98 percent of the time because of the 2 percent. If there is a better pattern you want to pitch, I am all for it. He named the tradeoff explicitly: the full fix is replacing each third-party MCP, which means an admin approval process per service, and I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then it is worth investing in doing exactly that. He framed it as accepting a little bit of risk so that we can experiment as a team, and set the target as getting rid of the 100 percent failure case, not solving every edge case.

Reasoning

Peter is optimising for the shape of the loss, not its probability. The catastrophic case - an unmediated agent with write scope on a system of record - is a total loss and is already happening about twenty times a quarter by his count. The residual case is an agent occasionally escaping a soft boundary, which is recoverable. Buying the first with a cheap pattern is worth leaving the second on the table. The alternative Jamin named is correct and unaffordable right now: per-service admin approval would gate exactly the experimentation Peter has spent six months trying to get the org to do. He also deliberately conceded the technical point in public rather than defending the pattern as complete - the guardrail survives on its cost-benefit, not on being airtight, and saying so is what keeps engineers arguing with him honestly.

Additional Context

This was the second of two topics at a 45-minute engineering all-hands Peter called specifically because the written missive had generated confusion and pushback rather than compliance. He opened by saying it was not a scolding call.

Observed Evidence

Fathom transcript of the 9/2 engineering all-hands; the 8/31 #eng-management message setting the agenda.

Matching Patterns

60%
Constrain the Mechanism, Not the Access(human-in-the-loop split, optimize for adoption where a person drives, same category)

Confidence Breakdown

34/35
Evidence
26/30
Pattern
20/20
Source
14/15
Corroboration

Reasoning Depth Analysis

Org Signal:You can win the technical argument with Peter in public and the policy still stands - and he will say out loud that you won it. It also tells engineers the guardrail is a cost-benefit judgment they may re-open with a better proposal, not a decree.
Who Affected:Every engineer running agents against third-party MCPs; IT and security, who do not get the per-service approval regime Jamin described; the RevOps codebase, which is the live instance of the failure mode.
Precedent:Sets the standard for how CIQ prices AI risk generally - kill the total-loss case cheaply, tolerate the recoverable one, and revisit only when a tool proves valuable enough to justify the friction.
Consequences:Real but bounded. Nobody is required to replace an MCP server, and the 2 percent escape case is knowingly accepted rather than mitigated.
Timing:Two weeks after the written missive, once it was clear the written form had produced confusion rather than behaviour change.

Source

reflection

AI Confidence

94%

Related Context

🎥
Being smart with AI - engineering all-hands 9/2

fathom

No, he is right. He is completely right. ... I do not think it is worth throwing out something, a pattern that I would argue works 98 percent of the time. I do not think it is worth throwing that away because of the 2 percent. If there is a better pattern that you want to pitch, I am all for it.

🎥
Being smart with AI - engineering all-hands 9/2

fathom

I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then I think it is worth investing in doing exactly what you just said, Jamin. But I do not want to block people out of the gate from going and poking and learning.

💬
#eng-management

slack

I have gotten lots of questions about my write static code rather than just pointing claude at an MCP missive.

Outcome

No outcome recorded yet.

Decision ID: 44891fb7-2d72-4c9a-9e9a-64f382ed99e5