Technical Decisions
6 recent decisions
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
Sep 2, 2026 · technical · high94% confidence
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.
People: Jamin Collins, Andrew Jorgensen, Stephen Moody, Nathan Blackham
Judge the Atlas code on its engineering merits alone - keep it, port it off the laptop, and stop building skills with direct data access
Sep 2, 2026 · technical · high94% confidence
After a deep dive through the revops-motherbrain repo and a walkthrough with Karl Lowenbjer, Tabatha Wilmot and Chris Baek, Peter delivered a written verdict on 8/31. He opened by refusing the question he was not asked: I am making ZERO statements about whether what this code was written to do is something we need at CIQ - that is a discussion for others. On the code itself: keep the bulk of it. API, frontend, warehouse and agents are independently separable with no cross dependencies. Data access is SQL direct rather than through hallucination-prone skill paths, read-only is enforced at the right layers, the MCP server sits above those layers, test-to-code ratio is roughly 2:3 and the documentation has not drifted. Fixes named: pull the business logic out of the code into a human-readable rule set (he called it the most valuable part of the project), delete the dead Trust Anchor, remove a write token that should be read-only, de-duplicate the mql LLM screen defined in two codebases. The real problem is what runs on the contractor laptop - Claude skills against the claude.ai MCP connector with direct HubSpot write scope, running without asking permission, bypassing the pipeline-approval and closed-edit rules HubSpot enforces on humans. Verdict on the open PRs: approve the move to a consolidated server, do NOT proceed with the interim laptop-resident lead router, fix it properly instead. And a standing instruction: the process of building out skills with direct access to data should stop immediately. In the 8/31 sync with Bjorn and Chris Baek he also confirmed he could pick up and make good use of the code if the contractor who wrote it did not stay - separating the keep-the-code question from the keep-the-person question.
People: Karl Lowenbjer, Chris Baek, Bjorn Hovland, Tabatha Wilmot
Scope the Atlas review to how it works, not whether it is worth it - and restate the rule that Claude must call a script, never an MCP directly
Aug 28, 2026 · technical · medium90% confidence
In the Motherbrain / Atlas sync with Tabatha Wilmot, Karl Lowenbjer and Chris Baek, Peter set the terms of his own code review. He told them outright that he would not wade into whether Atlas is valuable - that is a Tabatha-and-sales question - and that what he wants to answer is how it works, how it is architected, how it stores and persists data, how it does security protections, what should run on a laptop versus centralized, and what the scheduler should be. He asked for the scripts and skills that still live only on Tabatha laptop to be pushed into the repo first so he can read both ends of the system, asked for half-sentence direct answers to Marlon open questions rather than more narrative, and committed to a four-to-five-hour deep dive by Saturday evening with a follow-up the middle of next week. When Tabatha described reps closing deals wrongly through the HubSpot MCP, Peter named the cause - Claude writing code at runtime against a system of record - and restated the standing rule that Claude should never call an MCP directly, it should call a script that structurally cannot do that.
People: Tabatha Wilmot, Karl Lowenbjer, Chris Baek
Fuzzball Substrate can be an option for the Kubernetes engine, never the only runtime - ship on existing rails or nobody buys the train
Aug 24, 2026 · technical · medium73% confidence
In the Aug 24 Kubernetes Weekly Sync, Jonathon Anderson raised whether the new CIQ Kubernetes engine should use Fuzzball Substrate as its default or its only container runtime, framing it as the question that would drive whether Substrate gets open-sourced - a Substrate-by-default engine would put Substrate in far more places and let CIQ target the same worker nodes with both Fuzzball Orchestrate and the Kubernetes engine. Bjorn Hovland split it immediately: default yes, only no, on the grounds that forcing one runtime reduces the usefulness of Kubernetes and CIQ products should be independently viable with value-add tie-ins. Peter argued against both halves from the buyer side, taking the position of a hyperscaler already running Kubernetes and evaluating a switch to CIQ: either CIQ sits on the same Kubernetes they already sit on, which is an easy sale to reason about, or CIQ hands them a pile of validation hoops to clear before a contract can be signed. He compressed it to a rule - it has to include existing rail widths, otherwise nobody is going to buy our trains - and then kept the door open rather than closing it, noting defaults can change over time as Fuzzball starts getting traction. Jonathon withdrew the framing as overstated. Chris Wolford then supplied the decisive fact, that Substrate cannot be the Kubernetes default because the engine would fail Kubernetes conformance testing and lose certification, and proposed it as a user-selectable option in the Pro tier instead. Jonathon concluded the open-source question is therefore deferred, since it only mattered if Substrate were the shipping default.
People: Jonathon Anderson, Bjorn Hovland, Chris Wolford, Brian Dawson
Extend the existing Claude PII policy unchanged to the new AI systems - and settle that HubSpot data is not restricted customer data
Aug 18, 2026 · technical · medium83% confidence
Brady Dibble raised a data-access question about additional AI systems on 2026-08-15, treating the data he had lost access to as uniformly restricted. Peter refused to answer it per-system. He ruled that (1) the things you lost are not all the same - some are restricted and some are not, (2) Hubspot data is not customer data, and a list of customers is just fine while PII is not, (3) as far as I am concerned the same rules can apply to the two systems you just listed, and (4) there should be no barrier to moving approved data to them, but they should not open the door to more data than we currently allow to Claude. He pointed Brady at the existing policy, noting Michelle has it.
People: Brady Dibble, Michelle Novicio
Endura scope for CIQs own pipelines - include Fuzzball, Warewulf, Ascender and Depot; exclude Apptainer
Jul 28, 2026 · technical · medium79% confidence
Eric Sheridan of Infrared Security updated Peter on the Endura proposal for securing CIQ build pipelines, noting Nathan and Justin had reviewed the Koji integration strategy positively and that Bjorn was excited about using Endura to protect Rocky core packages. Eric asked whether scope should extend beyond Rocky to Fuzzball, Warewulf, Apptainer and Ascender. Peter replied to include Fuzzball, Warewulf and Ascender, said Apptainer should not be necessary, and added a product Eric had not asked about - Depot - on the grounds that projects which serve CIQ products to customers should be included as well. Pricing follows this scope, and a call with Greg and Bjorn was set for Wednesday.
People: Eric Sheridan, Nathan Blackham, Justin Haynes, Bjorn Hovland, Greg Kurtzer