Karl
Apr 17, 2026 - Oct 30, 2026
10
Decisions
0
Active Todos
12
Patterns
Categories
Decisions (10)
Sensitive Decision
Karl browser tool must run on CIQ infrastructure - licensing it from him is fine, depending on a third-party service is not
Karl proposed CIQ pay about 20 dollars a month for a browser tool he wrote (reportedly 3.7x cheaper and 3x faster than Claude for agent browsing). Steve declined to decide because Karl was recommending his own product. Peter said the money is irrelevant; what matters is that CIQ runs it on its own infrastructure. CIQ is open to licensing or buying it from Karl if it tests well, but will not take a dependency on an external service. Steve to find out whether the tool predates Karl at CIQ.
Tell Bjorn the Wallace org is not over-staffed and may still need to grow - and hold the security-engineer ask for a couple of months
Bjorn asked Peter two deliberately separated questions: is Steve org rightly sized, and is Steve the right person to lead it. On sizing Peter answered that it is rightly sized, meaning it does not need to get smaller - he was ruling out shrinking, not ruling out growth. He brought numbers to the answer: ticket volume, growth in volume, and average life of tickets, which show the team getting swamped. He noted that Karl may help once he is in, spending time on the Mother Brain and Atlas work and also automating some things in that area, but this was named as possible relief rather than as a plan that removes the need for headcount - the org may also need to grow. Peter then flagged that at some point, and by someday he meant the next couple of months, he wants to talk to Bjorn and Greg about a security engineer under Steve again.
Require archival and backup for anything in the Mother Brain warehouse that is not reconstructable from source
While Karl demoed the customer-journey view built on the data warehouse - 15 million events and growing, hosted on GCP - Peter asked how much of it is reconstructable if it is all destroyed. Karl said everything should be recreatable. Peter said he expects that is true and kept the instruction anyway: when Ian is slotted under Wallace, have Ian run archival and backup against anything that is not recreatable. He explicitly excused Karl from doing the work himself.
Slot Karl under Wallace rather than take a new direct report - with a stated escape hatch and a three-month contract extension
Peter told Karl the HR paperwork was signed and moving, encouraged him to meet Steve Wallace whenever he wants, and confirmed the intent for Karl to report to Wallace. He named his own constraint plainly - he does not want to add direct reports right now - and in the same breath acknowledged Karl will be a different animal from anything else under Wallace, told him to reach out directly if he is not getting what he needs, and pre-committed to changing the arrangement if the fit does not work. In parallel over Slack, Peter asked Chris Baek who to talk to about extending Karl contract by three months and offered to do it himself. Karl is evaluating one other option and will confirm Monday morning.
Extend Karl Lowenbjer under Wallace and land Atlas and Motherbrain in Engineering
After spending the prior week reading the Motherbrain and Atlas code Karl Lowenbjer built under Tabatha, Peter concluded it was quite good - really well architected and thought through. Chris Baek did not want to keep Karl on the Operations side. In the Thursday 1:1 Peter pitched Wallace directly on taking both the contractor and the applications, telling him he is pretty sure Wallace ends up being the one asked to maintain things like Motherbrain and Atlas anyway. Wallace agreed the same call, having independently run a compliance and security read of the code and landed in the same place. On Saturday Peter DMed Karl himself, told him his contract ends in about a week and a half, and asked whether he wanted to let it end or extend it under Peter - then asked Sarah for 30 minutes with Karl on Tuesday or Wednesday to work it out.
Judge the Atlas code on its engineering merits alone - keep it, port it off the laptop, and stop building skills with direct data access
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.
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
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.
Require all agent/LLM access to systems of record to go through inspectable static code, never direct LLM access
Peter opened the 7/24 Jira Automation call with Karl Lowenbjer by setting a condition before taking Karls agenda. The rule: no LLM gets direct access to a system of record. In every instance the LLM writes code that accesses the system, and that code is inspectable by a human or by another LLM. He stated he wants this true for everything Karls team builds, and that as long as it is true he is comfortable. He explicitly accepted that the filters themselves may be wrong - we might make a mistake in terms of what we pull in and out and that is fine, I do not mind mistakes - but the mechanism is non-negotiable. Karl confirmed Atlas already works this way. Peter then closed the topic without further discussion.
Reframe Azure relationship — CIQ supports RLC, not all of RESF
Directed Justin to align with Kelly on Azure messaging, clarifying that CIQ supports its own RLC offering (not the entire RESF ecosystem). Protects Nathans team from unbounded support burden while preserving the January 2027 contract renewal opportunity.
Related Patterns (12)
Executive Sponsorship for Strategic Partnerships
Strategic cross-company initiatives and major client partnerships require executive-level accountability to move at the right pace and ensure proper prioritization.
Protect Engineering Capacity
When external demands threaten to overload engineering capacity, protect capacity by either requiring the demand to come with additional resources, or forcing hard prioritization choices upstream.
Small Circle for Sensitive Operations
When executing sensitive strategic operations, keep the circle of informed people as small as possible to prevent leaks that could accelerate hostile action or undermine the initiative.
Reclassify to Route - Decide Who Owns It, Then Give a Criterion Not a Verdict
When a question arrives at Peter framed in one domain, he often does not answer it in that framing. He reclassifies it into the domain that actually governs the outcome, which relocates ownership to whoever owns that lane, and then hands down a decision criterion rather than a verdict. The reclassification IS the decision - it determines who decides. He does this rather than adjudicating on the merits himself, even when he was explicitly cc-ed and even when a direct report challenges him on the substance.
Route Non-Differentiating FTE Classes to Partners
When CIQ would otherwise need to staff a function whose work does not differentiate the company — compliance bureaucracy, audit/cert paperwork, ongoing regulatory attestation, etc. — Peter routes the load to a partner who already owns adjacent capability rather than adding the FTE class internally. Org-shape decision dressed as a partnership decision.
Decide on the Precedent, Not the Case
When a request arrives framed as a one-off, Peter does not evaluate the one-off. He evaluates the rule that granting it would write, and answers that instead. Peter generalized this himself on 2026-08-11: it is always about understanding precedent - whether it is a comp change or anything that structurally affects the company. It is therefore NOT a compensation pattern; the domain of the presenting request is incidental. The tell that this pattern is live is that the stated reason for the answer refers to future cases rather than to the merits of the present one.
Redesign Conditions Over Policing Symptoms
When a direct report names a vulnerability and proposes surveillance-style verification mechanisms (breathalyzers, daily check-ins, monitoring rituals), Peter accepts the disclosure but pushes back on the surveillance model. Treats the verification proposal as a signal that the underlying environment needs redesign — and offers to change the conditions that produced the vulnerability rather than instrument the symptom. Costs Peter optionality (e.g., committing to broker work-hour expectations directly with the partner/spouse) — the asymmetry signals genuine retention vs transactional.
Name It Without Staffing It
Applies when a structural change is directionally clear but the specific person, budget or reporting line is not settled. Peter names the structure - the role, the reorg, the governance reform, the ladder - and deliberately does not attach a name, a req or a commitment to it. The 2026-05-21 observation states the economics plainly: cost of naming is near-zero, cost of premature commitment is high, and he consistently chooses naming. The 2026-08-24 observation adds the sequencing reason: once a specific person is attached to a framework, the framework stops being the subject. Mined from 6 independent observations between 2026-01-12 and 2026-08-24.
Different Diagnosis, Different Remedy
Applies when a directive or a problem spans several people or cases that superficially look alike. Peter refuses a uniform answer and sorts by diagnosis first, then applies the remedy that diagnosis calls for. The 2026-08-28 observation states the consequence for recording his decisions: when he gives a directive spanning several cases, the decision is almost never any single remedy - it is the rule that produces DIFFERENT remedies, and four cases with four different answers under one rule means the rule is the decision. The 2026-04-17 observation confirms he holds this as an explicit framework rather than an instinct. Related to Three-Lever Talent Management but distinct: that pattern runs hire, develop and exit in parallel, this one is about diagnosis determining which lever a given case gets. Mined from 6 independent observations between 2026-02-03 and 2026-08-28.
Install the Criterion Before the Argument
Applies to a contested question that has not been argued yet - a meeting about to start, a test about to run, an escalation just received, a proposal about to be written. Peter moves first to fix the criterion, the boundary or the posture, before anyone argues the substance. The consistent effect, named explicitly in the 2026-07-29 observation, is that the other party cannot win by being more persuasive on the merits, because the merits are no longer the axis. Distinct from Reclassify to Route in mechanism: that pattern reassigns who owns a question, this one controls WHEN the criterion lands relative to the debate. The two frequently co-occur. Mined from 7 independent observations between 2026-01-20 and 2026-08-31.
Constrain the Mechanism, Not the Access
When AI or automation raises a governance concern, Peter does not restrict who or what may reach the data. He constrains HOW the reach happens, so the pathway becomes auditable and deterministic. The failure mode he designs against is non-determinism, not leakage - a wrong filter in inspectable static code is a bug you fix once, while a model that sometimes pulls the wrong field is an unbounded, unauditable liability. He will therefore accept imperfect filtering and eventual leakage as the price of adoption speed, but will not accept a non-inspectable pathway.
Conscious Tech Debt for Execution Speed
When facing time pressure, explicitly acknowledge and accept technical debt rather than blocking progress. The key is making the trade-off consciously and visibly so it can be addressed later.