Three projects that show how I work: a live-event IT build with an immovable deadline, AI tooling that lets a small team run a managed service provider, and this site, which AI harnesses maintain under my rules.
I have 23 years at the same MSP, and these are the three pieces of work that say the most: what it takes to deliver a trade show every November, what it takes to make automation safe enough for production, and what it takes to let several AI agents change one site without losing track of anything.
At a glance
| Project | What it is | Why it matters |
|---|---|---|
| American Film Market IT operation | The entire IT operation for a major international trade show, 23 consecutive years | A whole hotel becomes a show floor on a deadline that never moves |
| AI tooling for the MSP team | MCP servers, agent skills and n8n pipelines for a four-person technical team | Automation a small team can trust with production systems |
| This AI-managed WordPress site | A WordPress site maintained by several AI harnesses under one shared rulebook | Every change is tracked in Git and one command away from undo |
American Film Market IT operation
The American Film Market is one of the largest film business events in the world. Every November, thousands of producers, distributors, sales agents and financiers from more than 70 countries come together to finance, license and sell independent films. It was founded in 1981 and is run by IFTA, the trade association for independent film and television. I have been the sole architect, planner and on-site lead of its IT operation for 23 consecutive years.
It is not a festival, it is a marketplace, and the whole hotel converts into staff and exhibitor offices, plus a rented theater for screenings. The deadline never moves. Moving three times in three years was the toughest stretch of the project, and budgets have tightened at the same time: on-site prep has been cut, overtime is limited and the crew is smaller, so the same build has to be delivered in less time.
What I did
- Own the annual IT plan: inventory, timeline, staffing, vendors and the full runbook
- Size and stage equipment for about 20 year-round staff and 50 to 60 peak users, with the seasonal ramp starting in July
- Coordinate the whole-hotel conversion, guest rooms becoming staff and exhibitor offices alongside a rented theater
- Define network requirements with hotel and theater IT in facilities I do not own, engineering around a ballroom and third-floor staff rooms that share one subnet
- Author the annual golden laptop image the rental vendor clones, so each user deploys in minutes
- Lead the office-to-hotel cutover, run systems through the show, and direct a team of three across the Admin and Production departments without formal authority
Tools and technology
- Mass imaging and deployment: one golden laptop image a year, cloned by the rental vendor for every user
- Network architecture in buildings I do not own: hotel and theater IT, shared subnets, fixed requirements written down in advance
- The runbook: inventory, timeline, staffing and vendors, planned, documented and executed end to end every year
- Vendor and venue coordination: three venue moves in three years against the same November deadline
Why it matters. 23 consecutive shows on a deadline that never moves, including three venue moves in three years. When the prep window shrinks and the crew gets smaller, the plan is what carries the work: every hour on site counts, so the runbook is written to make it count.
AI tooling for the MSP team
I am the technical lead for a four-person team at a managed service provider running roughly 400 to 500 endpoints, and I led the rollout of Claude to the tech team, including every MCP server, skill and integration behind it.
The problem behind the work: my techs live in ticketing, RMM, endpoint security, Microsoft 365 and backups all day. A team that small cannot re-answer the same questions by hand, and an AI with API access is only safe if it is scoped. So I build the plumbing that lets Claude do real work across that stack, mostly read-only by design.
What I built
- Five production MCP servers: Microsoft 365 Management with preview-then-execute changes, M365 Security Investigation for read-only sign-in, audit and mailbox forensics, N-sight RMM for device, check, patch and backup data, WatchGuard EPDR for endpoint posture, and Freshdesk for tickets
- Agent skills, led by Freshdesk ticket triage, the team’s most-used: it investigates alerts across M365, endpoints, EDR and RMM, writes a clean private note and closes informational tickets
- An M365 breach report skill that turns an affected account and a rough timeframe into a structured compromise investigation
- n8n pipelines for phishing triage from Freshdesk webhooks, and a weekly backup review that collects the week’s backup alert tickets, generates a report and flags the jobs that need a closer look
- A vendor assessment engine that drafts answers to security questionnaires from a knowledge base of 300+ controls, cites the evidence behind each answer and flags anything unsupported for a person to review
Tools and technology
- Claude, Model Context Protocol and agent skills
- n8n, Freshdesk webhooks, AppSheet and the Composio integration that gives each tech’s Claude account API access across the tool stack
- N-able N-sight, WatchGuard EPDR, Microsoft 365 and Entra ID
- R with local sentence embeddings for the assessment engine, so client data never leaves the machine
- A self-hosted agent lab on a Linux host reachable over Tailscale: seven scheduled jobs, plus local models with LM Studio, Ollama and CUDA builds of llama.cpp
Design rule for every agent I build: read-only by default, and nothing changes without a way to undo it.
Why it matters. Routine tickets get investigated and closed by the team’s most-used skill, backup jobs get reviewed every week and flagged when they need a closer look, and security questionnaires get answered from cited evidence instead of memory. That is the point of the plumbing: a four-person team gets coverage across the whole stack without handing an AI the keys.
This AI-managed WordPress site
This site is my lab: WordPress in Docker on my Linux box, published only to my tailnet so it is never exposed to the public internet. Claude, Codex and OpenCode maintain it through SSH and WP-CLI or the WordPress MCP Adapter, and every harness reads the same rules file before it touches anything.
The interesting project is not the website, it is the control plane behind it: a way for several harnesses to change one site, with every change visible, attributed and reversible.
What I set up
- A snapshot before every change, plus a restorable database dump with users and passwords stripped out
- A private GitHub repo: every sync exports pages, posts, templates, menus and settings to readable files, commits them under the harness name and pushes
- Two rollback paths: restore any commit or an exact local snapshot, with every rollback recorded as its own commit and history never rewritten
- One shared rules file (AGENTS.md and the full guidelines in the repo) that every harness reads, with the same rules served to harnesses that only have the MCP
- Numbered Lab Notes: every session that changes the site publishes what changed, how and what failed, closed by an automatic change record
- A 15-minute auto-capture for changes made through the MCP or wp-admin, and a Harness Scoreboard computed from Git history that nobody edits by hand
Tools and technology
- Docker: WordPress, MariaDB and WP-CLI containers on one Linux host
- Tailscale Serve: the site stays inside my tailnet, no public tunnel
- SSH and WP-CLI for full control, the WordPress MCP Adapter for MCP-only harnesses
- Git and GitHub with snapshot, sync, rollback and lab note scripts on the host
Why it matters. The whole loop has been tested end to end: change, commit, roll back to an earlier commit, verify, with users, theme and the MCP connection intact. That is what lets the harnesses move quickly. Every change is one command away from undo, and every session leaves a Lab Note explaining what happened.
The detail, including what broke and what was rolled back, is in the lab notes. For the wider picture, see my experience and the AI and automation work.
Every fact on this page comes from the site itself: the Experience and AI & Automation pages, the Lab Notes and the repository that tracks them.