Working with me
I design the systems that turn a team’s knowledge into action — the data models, the workflows, the narrative layer that lets information become a decision, the verification that keeps it honest. For most of my career these systems lived in SQL, dbt, Looker, and slide decks. They’re moving into agent architectures now. The architecture hasn’t changed; the substrate has.
The pattern I keep seeing
Across the teams shipping reliable AI work in production, the same shape keeps showing up. Four parts:
- 1.
A durable substrate. Files. Plain text where possible. Version-controlled. This is what survives a tool change, a team turnover, a model swap.
- 2.
Declarative units of capability. The work, written down. In the BI era these were dbt models and LookML measures. In the agent era they are skills (
SKILL.md) and prompts. Same artifact: a specification of how a piece of work gets done, written so both a person and a machine can read it. - 3.
Lightweight orchestration. The scripts, jobs, hooks, and tools that wire the substrate to the units of capability. This layer is disposable; every six months something better ships.
- 4.
Continuous verification. Evaluations, tests, observability. The work isn’t done when it runs — it’s done when you can show it ran correctly.
The bet underneath: the first two compound, the last two are infrastructure. The temptation is to invert this — to invest heavily in orchestration tools because they’re visible, and to skip the substrate work and the verification work because they’re not. Systems built that way look strong in a demo and fall apart in production.
Claude Code is built this way
The most capable agent product currently shipping is Claude Code itself. Look at how Anthropic built it: the agent reads from and writes to a filesystem (substrate), executes plain-text skill files and slash commands (declarative capability), runs hook scripts and shell tools (orchestration), and is governed by tests and output evals (verification). It is not a complex framework. The agent reads plain-text files and runs plain-text instructions.
That isn’t a coincidence. The teams shipping reliable AI — Anthropic itself, the better internal tooling teams at the frontier labs, the open-source superpowers and agentskills communities — are converging on the same shape. The shape itself is older than the agent era; it’s just newly visible because text is now the universal interchange format for both people and models.
The same architecture works for any generalized workflow. Customer support, financial close, content production, sales operations, retail category management — every one has a substrate (the data and policies), units of capability (the standard operating procedures), orchestration (the systems that wire them together), and verification (the checks). The agent era doesn’t change the architecture. It changes who can implement it, and how fast.
Where I’m useful
Three places this shows up in actual engagements:
- 1.
Designing the substrate. Most teams have their data and process scattered across tools — Notion, Slack, Drive, six BI dashboards no one quite trusts. Before any of this gets automated, the substrate needs to be readable, by people now and by models later. I help teams consolidate, name, and structure their work in ways that survive whatever tool ships next.
- 2.
Authoring the capability layer. Skills, prompts, dbt models, SOPs — the written instructions that say “this is how this piece of work gets done.” The deliverable is a library, not a one-time engagement, and I author at that level so the work outlives me.
- 3.
Standing up the verification layer. Evals, tests, the simple observability that lets you know whether the systems are doing what they’re supposed to. Most teams skip this and pay for it in production.
I do the orchestration work too, but I don’t lead with it. Orchestration is the part that gets thrown away.
What an engagement usually looks like
Two weeks of listening — to the operators, the engineers, the executives, whoever owns the budget. A short written diagnosis at the end of that, plus a recommended next move sized to what’s actually possible. Then either a scoped build (typically six to twelve weeks) or a longer embedded role (typically a quarter or two), depending on what fits.
I work alone or alongside an existing team. I am not a staffing firm; if the right answer is to add headcount, I’ll help write the spec and run the search.