The pattern shows up everywhere I work: a probabilistic model in the middle, and a deterministic control layer around it that makes it safe to run — tenancy, evaluation, governance, observability, capability boundaries, state, provider abstraction, and a human accountability model. Go-to-market is my proving ground, not the point: it's a demanding, real-money domain where I've built and now run this stack across ~35 client workspaces. The architecture generalizes past it.

My differentiator isn't that I automate tasks. It's that I build the production layer around them — the part most agent projects skip — and I lead the function that operates it.

The portfolio is one body of work with two faces — the systems, and the function that runs them. Start with whichever you're here for:

• 🏛 ai-native-gtm-architecture — the systems view. How the control planes compose and the invariant each one enforces. The reference implementations sit under it.
• 🧭 gtm-engineering-operating-model — the leadership view. How you set up and lead a team whose real work is directing agents. The organizational half most portfolios never show.

The repositories aren't scattered tools; they're one line of inquiry into the same question — what deterministic layer does a probabilistic model need around it to run in production? — answered one control plane at a time.

Maturity legend — Production-used: I run it against my own live agent workflows. Component of callusguard: still standalone and still works, but the maintained loop is callusguard, which ships all five stages as one install. Reference implementation · production-derived: the pattern is extracted from a system in production; the public repo isolates the reusable architecture, with tenant data, provider adapters, and company-specific policy kept private.

The same repositories, grouped by where they sit in the stack:

AI-native platform  (proving ground: go-to-market)
│
├── Intelligence & targeting     gtm-research · gtm-pipeline
├── Channel infrastructure       gtm-deliverability
├── Runtime observability        cc-logger · codex-logger      ┐
├── Execution controls           agent-guard · codex-guard     ├─ all five merged
├── Scope verification           wroteonly                     ┘  into callusguard
├── Human approval gates         abeyance
├── Quality & policy enforcement model-eval-gate
├── Knowledge governance         knowledge-graph-governance
└── Platform architecture        agent-tenancy
        │
        └── operated by a team, per → gtm-engineering-operating-model

The through-line: observe what agents actually do → promote recurring failures into runtime controls → verify each run stayed inside what it declared, and retire the rules that stopped earning their place → gate model economics with evals → gate durable memory → isolate tenants structurally → run the motion on top → hold the irreversible parts in abeyance until a human who wasn't there says yes → and lead the humans who own all of it.

Published essays on what leadership becomes when a team's real work is directing agents. These are the arguments the operating model is distilled from.

• The Layer Question — where leaders belong when teams run AI
• The Expertise Need Is Dissolving — Protection Is What Leaders Provision Now
• Leadership in the Age of AI Agents (The Leader as Friction)
• Developing Taste — the only leadership skill that survives the agent
• The Taste Famine — transferring judgment when agents have eaten the reps
• Permission for Inarticulate Doubt
• The Builder's Trap — why the faster leader should give the build away

Some production adapters, company-specific policy layers, client datasets, and the end-to-end orchestration system remain private. The public repositories deliberately isolate the reusable architectural patterns and reference implementations — the architecture contract, not the proprietary implementation. That's the intended boundary, not a gap.

• GitHub: @kkrlstrm