AGENTIC SYSTEMS · BUILDER RECORD

A GTM leader who is also an AI operator.

Seven agents run the operating work of my GTM job: reporting, chief-of-staff tasks, marketing and social-selling content, and the internal tooling (wikis, dashboards, the "revenue brain" I operate from) that Emma, my principal engineer agent, builds and maintains under my direction. When something breaks, diagnosing the real problem and directing the fix is my job. Writing the code is hers.

7
Agents in production, each its own cloud service
8
Packages in the monorepo, each with its own tests
4
Production bugs caught in my own review loop
0
Autonomous sends: every draft waits for approval

01:The differentiator: governance and judgment, not "I used AI"

Seven agents can look empty on their own. What sets the work apart is the discipline around it: CI gates that enforce cost and model-routing policy, a security review that caught and fixed a real injection bug, incident postmortems (including a cron pipeline that had gone silently dead), and a record of rejecting work that wasn't good enough, including my own AI's.

02:Flagship: the Rocks dashboard

Built by Emma, my principal engineer agent, under my direction: I made the architecture calls, she wrote the code. That's what directing engineering looks like as an operator, not a coder. I run my quarterly goals off it, and twice a week it drafts the standup report to leadership. It replaced an unreliable tool I couldn't fix. I chose to replace it rather than patch it.

  • Spec before code. The architecture-decisions table chose relational SQL over key-value and over direct Postgres, with the reasoning written down, not improvised after the fact. "Show me all blocked actions across all rocks" is one query against a real schema.
  • Killed complexity on purpose. Removed a Box-note sync and a spreadsheet so there was no external sync to maintain. Choosing to remove a feature to protect one source of truth is a judgment call, and I made it deliberately.
  • Rejected a false "done." An early build looked finished but hid broken states behind a clean screen. I sent it back for a full rebuild. A demo that hides broken states isn't a working system, and knowing the difference is the whole point.
  • Real safety engineering. Optimistic concurrency after a data-safety review, idempotency guards so a cron can't double-fire, and a nightly pipeline that had 404'd silently for weeks, root-caused and fixed. Catching what fails quietly is the harder skill.

03:The systems case: a governed agent fleet

Seven agents, each its own cloud service with its own repo and CI, later migrated into a monorepo with a documented rollback plan and a health-gated cutover. This is the shape of the actual job.

  • Governance over count. A written rule for when to stand up a new agent versus extend one, so the fleet doesn't sprawl.
  • Cost as policy, not preference. The build fails if an unannotated top-tier model call appears on a mechanical or cron path.
  • One comms voice. Only one agent talks to people. Integration ownership follows the home system, so five services don't end up holding the same credential.
  • Security that found real bugs. A SQL injection patched with an ID guard at every call site, and a token-refresh blind spot that had left monitoring falsely healthy. Both closed.

04:The stack, for the technically curious

Turborepo and Bun workspaces, TypeScript 7 RC on the native Go compiler, and Effect Schema enforced at every trust boundary: LLM output, external APIs, HTTP bodies, and the shared memory engine's write path. Oxlint runs correctness-only and blocks CI; Oxfmt handles formatting locally, deliberately not a gate. A supply-chain control sets a seven-day minimum publish age on new dependencies, so a same-day-published, potentially compromised package can't be pulled in by accident.

  • Tests exist, not just claims. Every one of the eight packages in the monorepo ships its own test suite.
  • Real, incremental commit history in the monorepo, each message explaining the reasoning, not one squashed dump.
  • CI beyond lint and build. Separate workflows for deploy and post-deploy safety checks, not just a green checkmark on merge.

The shared memory engine every agent builds on is public. Real git history, 75 tests, and it never touched business data to begin with, so there was nothing to redact: severs-agent-shared on GitHub. The rest of the fleet, including the Rocks dashboard and each agent's business logic, stays private.

05:What I actually do: diagnose, direct, hold the bar

The fleet shows I can direct engineering, and direction is the real skill. I don't write the code myself, my agents do. What I do is diagnose the actual problem, give clear direction, and hold the line on quality until the fix is real, not just claimed. That's what being AI-forward means: not writing the code, knowing exactly what needs fixing and directing it correctly.

  • Diagnosed a data-layer constraint and directed the fix to the correct HTTP API. The reasoning is in the commit message.
  • Directed optimistic concurrency and idempotency guards after a self-initiated data-safety review, closing a double-fire risk in a scheduled job before it caused a production incident.
  • Root-caused a nightly pipeline that had been failing silently for weeks. The monitoring said healthy, the data said otherwise. Directed the fix to the pipeline and the monitoring gap that hid it.

06:Early days, not a finished system

This is the beginning, not a finished portfolio piece: from ad hoc scripts to a documented, cost-governed, security-reviewed system with a real rollback plan, built while running go-to-market full time, not instead of it. There's a lot more to learn and build from here.