Platform Solutions Architect · field notes · 20+ years

Every platform demos beautifully. I work the layer where it has to survive.

Data, identity, and the decisions that run on them — the substrate under the feature set, where things actually break and actually get fixed. Twenty-plus years across CRM, CDP, and marketing automation taught me one durable thing: a stack will tell you the truth if you know where it keeps it. Learning where has been the whole career.

I'm a tinkerer by wiring. The same instinct that reads an identity graph also solders jewelry, keeps a small flock of chickens with an internally consistent naming convention, and builds AI agents on my own domains to see what holds. One practice, a lot of materials.

Fig. 01 — the stack, in cross-section · survey of record

How I read a stack

A portfolio is judgment, not a gallery. Here's mine, in the order I actually use it.

Start at the data model and the identity graph, not the dashboard. The dashboard is downstream of every real problem it will ever show you.

Name the failure mode before naming the fix. Brittle orchestration, email-keyed identity, deletes that suppress instead of transition — a problem you can't name is a problem you're about to migrate.

Fit beats hype, and declining a tool is a deliverable. The right platform fits the substrate, not the loudest demo. Some of the best calls I've made were the word "no" with receipts attached.

Build for the bad day. If there's no safe way to test it or reverse it, it isn't a system yet — it's a wager wearing a system's clothes.

Selected work · sheet index

Exhibits

Anthropic ClaudeMCP · agent designCDP

agent layer · reasoning modeled from senior-architect judgment

The Surveyor Agent — a stack-diagnostic agent, built rather than prompted

Problem: Platform audits happen after scoping — by the time anyone actually reads the configuration, the misconfigurations are already load-bearing.
Read: The reasoning that catches a broken stack isn't magic. It's pattern recognition that lives in senior architects' heads and gets rationed out one meeting at a time. Anything that consistent can be modeled.
Call: So I built a Surveyor Agent: a reasoning agent that reads a stack's configuration integrity before scoping begins. Platform-agnostic, evidence-first, and polite about it — every verdict arrives with receipts, and anything irreversible waits for a human hand.
Outcome: Named a standout in a field of ~250 agents from 35 partner agencies. He lives at codedrovers.com, in production.

Dynamics 365Dataverse · Power PlatformCopilot Studio

14 roles · 5 functional areas · headcount assigned: 1

An enterprise Dynamics 365 migration, staffed to the standard model

Problem: A 24-month enterprise Dynamics 365 migration. The standard implementation staffing model for an engagement this shape defines fourteen distinct roles across five functional areas.
Read: The roles are real — every one of them had to be performed. The timeline was indifferent to whether fourteen people performed them, or one.
Call: Headcount assigned: 1. Governance, architecture, development, AI & quality, security — worked as a single practice instead of fourteen hand-offs.
Outcome: Delivered. The resourcing record survives below, drawn to the house convention: the stack in cross-section.

Fig. 02 — the staffing model, in cross-section · resourcing record · 2024–2026

UnicaAcousticAmazon Pinpoint / AWSdeliverability · identity

on-prem (Unica) → SaaS (Acoustic) → cloud-native (AWS)

Re-platforming an enterprise messaging engine

Problem: A Fortune-100 telecom on aging on-prem messaging (Unica, then Acoustic), dragging deliverability and identity debt through every migration attempt.
Read: The blocker was never the send engine. It was the identity resolution and deliverability posture underneath it — move those first, or the shiny new platform just inherits the old debt on day one.
Call: Re-platform onto Amazon Pinpoint / AWS, with identity and deliverability re-architected as the foundation rather than a follow-on. The last move was downward — into the cloud substrate — not sideways to something louder.
Outcome: A messaging platform that scaled without carrying the old failure modes forward. The migration nobody wanted to attempt twice, attempted once, correctly.

Snowflake · SQLMessageGearswarehouse-native

cloud data warehouse (Snowflake) → SaaS execution (MessageGears)

Warehouse-native decisioning at scale

Problem: A Fortune-500 quick-service brand needed decisioning that could run against the real system of record — at a scale most ESPs quietly can't hold.
Read: Copying the data into the messaging tool just recreates the staleness problem one layer over. Evaluate the logic against the warehouse, where the truth already lives.
Call: A SQL-to-MessageGears blueprint — warehouse-native decisioning evaluated directly against Snowflake, and weighed honestly against a pricier alternative that demoed better and would have aged worse.
Outcome: Decisioning that reads the source of record instead of a lagging copy of it.

enterprise · internal

Decision-engine architecture review

One exhibit is held. An enterprise-level internal engagement — an architecture and identity-semantics review of a decision engine at scale — is under review and stays off a public page until it clears. The short version travels fine in conversation, de-identified. Available on request.

Range

Marketing is one domain in the range — not the range.

The through-line is data and platform architecture. CRM outscopes marketing; the substrate outlasts the feature set.

Platforms

Dynamics 365 Customer InsightsPower PlatformAdobe WorkfrontMessageGearsBloomreachSegmentmParticleAmperityBrazeKlaviyoZetaMoEngageAmazon PinpointAcousticUnicaMicrosoft CopilotAnthropic Claude

Specialties

Identity resolutionDeliverabilityData governanceJourney orchestrationWarehouse-native architectureMigration & re-platformingAPI integration

37+ platform certifications · Dynamics 365 (all modules), MB-910 · Claude Certified Architect — Foundations (in progress).

The newest platform in the range

I build on AI. I don't just use it.

AI is the newest platform I architect on, and I treat it like any platform: build on it, evaluate it honestly, know when to decline it. The Surveyor Agent is a reasoning agent I built, not a chatbot I prompted.

Deep on Microsoft Copilot and Claude; I've built agents on OpenAI and Glean too, and formed a preference by building rather than by reading the brochure. The tool choice is the expertise.

Selected AI-engineering work · sheet index

Anthropic Claudeverificationreasoning integrity

verification layer · knowing when the machine is wrong

How I know an agent works — before I trust it

Problem: A confident agent and a correct agent look identical from the outside. Most AI tooling ships on the first and hopes for the second.
Read: Confidence isn't calibration. The only way to trust a reasoning system is to build the test designed to fool it, and watch whether it holds.
Call: So I build the harness before I trust the agent: adversarial "cry-wolf" bait cases planted to trip a false alarm, run in repetition, behind an explicit false-positive gate that has to close on evidence before anything ships. When one of my own prior diagnoses turned out wrong, I reopened it against the original transcript and logged the correction rather than overwriting it — the superseded reasoning kept as audit trail.
Outcome: Agents that degrade honestly instead of failing silently. A false-positive rate closed at zero across six runs — and a verdict I can hand over with the receipts attached.

Pythonprivacy engineeringdeterministic

raw content → content-free flags → agentic triage

A privacy boundary the model never crosses

Problem: To let an AI audit a system, you usually have to show it the system — including the parts that must never leave the building.
Read: The agent doesn't need the sensitive value. It needs to know a value is there and what kind. Those are different, and the difference is the whole safety case.
Call: A deterministic scanner that emits content-free flags — never the raw value, never the matched name. The scout sees cells; the agent sees only flags, and triages them. Nothing content-bearing crosses the model boundary.
Outcome: An AI that can reason about sensitive data without ever being handed it. The boundary is the feature.

TypeScriptModel Context Protocoldeployed

Anthropic Messages API → live, auth-gated MCP server

A production MCP server, built on both sides of the protocol

Problem: Most "AI integration" is a wrapper around someone else's endpoint. The protocol underneath stays a black box.
Read: If MCP is going to be how agents reach tools, I want to have built it — server and client — against the wire format, not a framework's idea of it.
Call: A deployed, auth-gated Model Context Protocol server (TypeScript, Anthropic Messages API), plus an agent that consumes MCP as a client. Agentic tool-use loops written directly against the wire format, no SDK between me and the protocol.
Outcome: MCP as something I've operated from both ends in production — not a checkbox, a build.

Pythonimage generationschema'd JSON · CI/CD

generation function → schema'd JSON → 100+ artifacts, live

A generative content pipeline at collection scale

Problem: One-off AI generation is a demo. A system that produces a coherent catalog is an engineering problem — schema, storage, render, deploy.
Read: The interesting part isn't the model call. It's everything around it: a stable schema, versioned output, a render layer, and a deploy that doesn't break when the catalog grows.
Call: Python-and-image-model pipelines that generate to a consolidated JSON schema and render 100+ artifacts served live, with CI/CD deployment across my own domains.
Outcome: Generative content operated as a pipeline, not a party trick. The plumbing is the point.

multi-agentgovernanceADR · provenance

Claude · Copilot · OpenAI, coordinated under written compacts

Coordinating a multi-model ensemble, on the record

Problem: Run several AI systems on real work and the failure mode isn't any one model — it's drift, lost context, and no accountability for who decided what.
Read: If AI systems are collaborators, they need what human collaborators need: scoped roles, written agreements, and a record of how a decision changed over time.
Call: A human-coordinated pattern across Claude, Copilot, and OpenAI surfaces — run under written working compacts, an ADR/spec/register documentation system, and provenance rules: attribution locked to its source, inferences flagged, nothing invented.
Outcome: Several AI systems doing real work without dissolving into one confident voice — governed, traceable, and honest about who did what.

Off the clock · same hands

The range isn't a sidebar. It's the same practice in other materials.

I write long-form fiction — mysteries, a Wodehouse-flavored Holmes crossover, and historical nonfiction; one published, three more in progress. Claude works the editor's desk: continuity, historical accuracy, a second read. The writing is mine; the fact-checking is shared. Me with the pen, Claude with the ~~strikethrough~~ — never the eraser. Which is to say I was scoping AI to bounded, named roles before that had a job title.

I make jewelry rooted in fantasy and Celtic mythology at Lore Faire, by hand — please feel free to explore the gallery.