A vast old tree shelters a lit workshop under a blue night sky — the Broken Branch lab.

Capability dossier · updated August 2026

Ben Schippers Put me on the hard problem.

I turn frontier capability into accountable organizational leverage. I define the problem, design the operating system around it, direct agent execution, and hold the release decision.

Microsoft cloud engineer · AI product and platform · technical program leadership · Atlanta, Georgia

Claims stay bounded. Public work carries receipts. Client-sensitive work and private repositories stay private on purpose.

open the file

The mandate

Execution is becoming abundant. Accountability is not.

Frontier models changed what one person can build. They did not remove the need to choose the right problem, design the system around it, recognize the lie, preserve the miss, and decide what earns release.

That is the leverage I create: more useful work can happen in parallel without outsourcing judgment or responsibility.

Judgment
Find the load-bearing problem and define what good means before execution begins.
Orchestration
Give people and agents the context, boundaries, interfaces, and quality gates to move in parallel.
Release judgment
Make outcomes inspectable, keep claims bounded, and stop the release when the check fails.

Assignment fit

Where the leverage compounds.

These are not three different professional identities. They are three mandates where the same operating model can change the scale and quality of the outcome.

AI product & platform

Set the product thesis and quality bar, then turn model capability into a coherent platform surface or developer workflow with a credible path to production.

Mandate: Head / Director · agents, developer tools, applied AI, enterprise platforms

Technical program leadership

Design the operating mechanisms for broad, parallel technical portfolios without losing the critical path, ownership, risk, or executive decision quality.

Mandate: Director / Principal · infrastructure, cloud, security, multi-team delivery

Forward-deployed & special projects

Enter an evolving problem space, learn directly from users and operators, and own the complete solution from first framing through the production handoff.

Mandate: Head / founding operator · high-consequence deployments, zero-to-one systems, field work

Selected work

Four kinds of leverage.

One changed an organization, one is an open-source tool anyone can install and audit, one is a live product where every change since launch went through the same gate, and one is the operating model the lab itself runs on.

Case 01 · organizational leverage

Microsoft · from silos to signal

Organizational leverage: turn fragmented customer signal into a shared system that changes engineering priorities.

Problem
A major enterprise AI rollout was accelerating across product lines with no shared view of the adoption walls customers were hitting.
My decisions
Assemble the cross-functional forum, deploy real-time case analytics, and turn fragmented support signal into a durable engineering-priority loop.
Direct result
The system surfaced 76 blockers and directly unblocked 7,380 users.
Program outcome
The broader work helped the organization add approximately 94,000 seats. That is a shared program result; my lever was the pipeline and the forum that ran on it.

Case 02 · open-source artifact

Career Compass MCP

Artifact leverage: publish the tool where a stranger can install it, then aim the audit at what they would actually receive.

Problem
A local-first tool that holds a person's contact details and salary expectations also has to read job postings written by strangers. Both end up in the same context window.
My decisions
Ship it publicly as a TypeScript MCP server on Anthropic's Model Context Protocol, installable in one command, and point the audit at the published package rather than the repository — driving it over the wire the way an installing stranger would.
Quality gate
In a July 2026 audit pass, 57 agents ran five independent lenses over it, and every non-speculative finding went to a verifier prompted to refute by default. 52 findings were raised, 36 survived that verifier, and 16 were killed.
What the audit changed
Silent data loss on the happy path, measured against the published server: 8 of 8 runs dropped records before the fix, 8 of 8 kept them after. Untrusted posting text now sits behind a nonce fence at all 10 interpolation sites. Each guard test was checked to go red when the thing it guards is broken.
In use
Its one external user to date, a laid-off job seeker, ran it through an active interview process. She reported that its value was a fit verdict that contradicted the job board's own labels in both directions, and she used it to project an interviewer's remaining questions mid-process — a use it was not designed for, which redirected the roadmap. Shared with her consent.

Case 03 · production gate

Visual Inventory · every change through one gate

Production leverage: run a live, billing-enabled product where nothing reaches users except through the same gate.

Problem
A product that catalogues what is inside people's homes has to keep one household's data out of another household's reach while still shipping changes.
My decisions
Launch with billing enabled, then route every change after it the same way: a numbered pull request with CI gating, including my own.
Quality gate
Since the 2026-06-19 launch, every one of the 64 commits merged arrived as a numbered pull request with CI gating, and none as a direct push. 622 pull requests have merged to date, against a suite of 2,268 tests, 2,266 of them passing on 2026-08-08.
What an audit found
A post-launch pass found a cross-household exposure in the database policy layer: the profiles UPDATE policy carried no WITH CHECK, so an authenticated user could reassign their own household and read another household's inventory. It was closed with a guard trigger proven across all five caller contexts. The product's readiness contract, clauses S1 through S6, holds that it does not call itself ready until a fresh production pass flips them.

Case 04 · inspectable method

The lab's operating system

Method leverage: put the operating rules into programs that refuse, and let them report where the record and the system disagree.

Problem
A fleet of agents produces more work than one person can review by reading all of it.
My decisions
Sort every action an agent might take into three tiers: work it may merge unsupervised, work it must surface and wait on, and work it never takes in any mode. Nine conditions have to hold at once for the first tier, and eleven actions are always held. The default under ambiguity is to hold, and every unsupervised merge is logged in the response. The rule is written as “no surprise merges.”
Quality gate
The agent doing the work is never the one grading it. Two of the four verification rungs are programs that refuse: the ledger tool will not mark an item done without an attached commit, pull request, or URL, and a session-end gate blocks the wrap while today's session record fails its linter. That linter is wired a second time into the automatic commit, which unstages a failing record and leaves it visibly in-flight. Both of those gates fail open on their own breakage. The other two rungs are written contract.
Evidence
442 session records over 101 days as of 2026-08-08, each required to name what shipped and what is still open. An inventory of 228 entries carries intent and provenance on every one, and a scanner re-derives the live facts and may only report disagreement, never edit the record: 6 flags on 2026-08-08, about 2.6%. A drift report regenerates at 07:00 daily, from a scheduled task running since 2026-04-26, acts on nothing it finds, and refuses to emit a clean report it could not substantiate; silences are named files that can carry an expiry. The machinery currently reports warnings and drift against itself. The claim is not that the lab is clean, but that the disagreements between the record and the system surface on a schedule, whether or not anyone wants to see them. These figures are measured by the lab's own instruments and are not externally verifiable.

Operating model

The fleet is not the accountable party.

Agents get enough rope to search, branch, build, test, and challenge in parallel. Accountability stays legible from the first framing decision to the final merge.

  1. 01Frame

    Find the load-bearing problem and define the change that would matter.

    Human-owned
  2. 02Bound

    Set context, interfaces, evidence requirements, and refusal conditions.

    Human-authored
  3. 03Run

    Let agents search, implement, test, and report through parallel branches.

    Agent-executed
  4. 04Challenge

    Use adversarial review, counterexamples, and independent checks against the claim.

    Shared scrutiny
  5. 05Release

    Merge, publish, narrow the claim, or refuse the result. Preserve the miss.

    Human decision

The line I hold

The fleet can propose, build, test, and run through the night. It cannot decide what deserves to be true in public. That decision stays mine.
More on how the lab runs

Record

Organizational scale. Frontier velocity.

The Microsoft record shows I can move systems and teams. The public lab shows how I now multiply execution without lowering the bar.

Enterprise operating record

5 yearsas a Microsoft Senior Program Manager across Copilot, Graph, Windows 365, and Teams Devices

8product lines in an internal platform portfolio spanning signal, routing, self-service, and quality measurement

95+features shipped through a rebuilt signal-to-engineering pipeline

433Kusers in a crisis transition led with near-zero churn

3 → 150agents in the Premier Engineering program built from pilot to scaled operation

60K/yrincidents handled by that scaled program

Self-reported career figures; not publicly verified. Supporting detail is available in conversation.

Inspect the full career cross-section

Fleet pulse

Git-derived, timestamped, and linked to public evidence. Hidden when older than 45 days.

Inspect the public work

Accountable restraint

Some work does not belong in public.

Accountability is not radical disclosure. This site does not carry credentials, client-sensitive information, or customer operational detail.

For public-sector, security, or other high-consequence work, ask me directly. Knowing what not to publish is part of the operating model.

Bring me the hard problem.

If you are searching for someone to lead an ambitious AI product, technical portfolio, or special project beyond the playbook, I would like to hear what success has to change. If you are already pushing frontier models hard enough to find their edges, compare notes.