Discuss a requirementContact

Lab

What I’ve engineered, tested and put to work.

The Lab brings together selected CRM, AI, GTM and cloud systems I have designed and developed. Each project shows the problem, the engineering approach, how the parts connect and what that work makes possible.

Open the drawingsWhat this makes possible

The drawings

Eight builds, drawn as they work.

Show builds for

Eight drawings and the bench.

Plate01

Trigebra: a HubSpot AI-readiness diagnostic

An application that assesses a HubSpot environment and turns complex CRM information into a structured, traceable picture of readiness for AI-enabled operations.

With
React · Vercel functions · Supabase · HubSpot OAuth · Claude
1HubSpot portalOAuth, read-only2Discoverydeterministic, chain idsAI3Assess × 5one call per capabilityAI4Synthesischain-id gateAI5Recommendationsprovenance enforced6Assemblydeterministic7Cost ceilinghard stop per run8Run stateleased, append-only

Choose a part of the drawing to see what it does.

Drawing of how Trigebra: a HubSpot AI-readiness diagnostic works, part by part.

  1. The owner connects their portal with read-only permissions.

  2. Ordinary software collects configuration and data evidence, each piece tagged with a chain id.

  3. Five separate model calls, one per capability, each given only its evidence.

  4. Cross-capability synthesis may cite only chain ids it received; anything else is rejected.

  5. The opening and recommendations must trace to evidence, checked before the report is assembled.

  6. The report is assembled without a model, so its structure and numbers are exactly what the evidence gave.

  7. Every model call is costed; a run stops before it can exceed its ceiling.

  8. A scheduled driver advances runs one lease at a time, and nothing written is overwritten.

The problem

A HubSpot owner wants to know whether their portal is ready for AI tools, and why, from the evidence in their own system rather than a questionnaire.

What I engineered

A five-stage pipeline. Deterministic discovery collects evidence and gives each piece a chain id; five model calls assess one capability each; a synthesis stage may cite only chain ids it was given; recommendations pass a provenance check; a final deterministic stage assembles the report. Runs advance through leased, append-only state.

Key decisions

  • The model synthesises evidence it is given; it never states what the portal contains.
  • Each run has a cost ceiling and a hard stop.
  • Early feedback showed that a correct report is not necessarily a useful one, so the engine was redesigned to assess capabilities rather than run checks.

What the work demonstrated

  • Turns raw portal evidence into findings that each trace back to their source.
  • Keeps AI synthesis inside the evidence it is given, with a cost ceiling on every run.

Where it could be applied

Portal diagnostics that combine deterministic evidence with bounded AI synthesis, for audits and readiness reviews.

CRM diagnosticsHubSpot workflows

Plate02

Account intelligence with verifiable evidence

Combines public-source research, AI interpretation and source checks to produce account intelligence that people can examine and use.

With
Python · Claude · Public registers and job boards · SHA-256 sealing
1Public sourcessite, registry, job boards2Collectorsbounded, loggedAI3AI investigatorfixed schema4Quote re-checkin code5Briefadvisory6A person decides7Sealed answershashed before runs8Scorerafter outputs freeze

Choose a part of the drawing to see what it does.

Drawing of how Account intelligence with verifiable evidence works, part by part.

  1. Only public evidence: the company’s site, its official registry entry and its job postings across eleven applicant-tracking systems.

  2. Ordinary software fetches and stores each source with its address and time, so every later claim can point back to it.

  3. A model reads the evidence and fills a fixed structure: who the company is, what changed, why it may matter, and what is uncertain.

  4. Every quote the model relies on must appear in the stored source. A claim that fails is removed, not softened.

  5. An advisory brief with its evidence attached and a gate marked pending: it recommends, it does not decide.

  6. Whether to act, watch or ignore is a human call, recorded against the brief.

  7. The right answers for each test case, written down and sealed with a hash before the workflow ran, so they could not drift towards its output.

  8. Outputs are frozen first, then compared with the sealed answers: identity, events found, unsupported statements, unjustified dismissals.

The problem

Research that a seller can act on has to be traceable, and it has to be measured: does it find what matters, and does it ever say something the source does not?

What I engineered

Collectors gather public evidence: the company’s own site, its registry entry and a scan of eleven job-board systems. An AI investigator writes a structured assessment; code then re-checks every quote against its source before an advisory brief reaches a person.

Key decisions

  • Verification is done by code, not by the model checking itself.
  • The method was evaluated against answers fixed in advance, so results could not be tuned after the fact.
  • An extra newsroom check can run before anything is dismissed, and paid enrichment sits behind a credit guard.

What the work demonstrated

  • Checks research claims against their original sources before anyone relies on them.
  • In evaluation, identified companies more accurately than research without the workflow, and made no statement its sources did not support.
  • Shows where it still misses relevant events, which sets the next improvement.

Where it could be applied

GTM research agents that assemble account evidence a team can verify, and say plainly what they could not find.

GTM intelligence

Plate03

Turning account signals into coordinated CRM follow-up

Connects AI recommendations, business rules, human approval and CRM workflows so relevant information can lead to a controlled next action.

With
n8n · HubSpot API · Claude · Signed approval links
1Signaluntrusted inputAI2AI readsrecommends only3Rulespolicy, duplicates4Owner approvessigned link5Claim tableone per signal6Kill switchread before each write7HubSpotcompany and task

Choose a part of the drawing to see what it does.

Drawing of how Turning account signals into coordinated CRM follow-up works, part by part.

  1. An account event arrives as text from outside. It is treated as untrusted: nothing in it can instruct the system.

  2. A model reads the signal and returns pursue, watch or reject, with verbatim quotes and its doubts. It has no tools, and an answer outside the format goes no further.

  3. Ordinary software stops customers, duplicates and incomplete signals, some before the model is ever called. The display score is set by rules, not by the model.

  4. The owner sees the reason and the evidence and approves or rejects through a signed, expiring link.

  5. The first approval claims the signal. A second approval, even arriving at the same instant, finds it taken.

  6. A published flag read before every write. Switch it off and the next write is blocked, with the reason recorded.

  7. The one consequential action: the company is found or created and a task is given to its owner, read back by record id to avoid search lag.

The problem

When something happens at an account that matters, the owner should hear about it with a reason, and act on it if they agree. Never without their say, never twice, and stoppable mid-flight.

What I engineered

Two n8n workflows connected to HubSpot. An AI step reads the signal and recommends; rules check policy and duplicates; the owner approves through a signed link; a claim table lets each signal produce exactly one action; and a kill switch is read before every write.

Key decisions

  • The model holds no tools. It can recommend; it cannot act.
  • One action per signal is enforced by a claim table, not by hoping approvals arrive one at a time.
  • The kill switch is checked before each write, so switching off stops the very next one.
  • Approval links are signed and expire; the write window after opening one is two minutes.
  • n8n was chosen after running the same scenarios in n8n and in plain Python: it gives an operator something to see and a client something to host.

What the work demonstrated

  • Prevents duplicate follow-up when approvals happen together.
  • Stops the very next write as soon as the workflow is switched off.
  • Keeps the AI to recommending: only an approved action reaches the CRM.

Where it could be applied

Signal-to-action agents that turn account events into one controlled step in the CRM, Slack or a task queue.

Taken apart on the AI page

HubSpot workflowsOrchestration

Plate04

AI-assisted enquiry handling in HubSpot

Classifies incoming enquiries and connects them with clear routing decisions, oversight and recovery.

With
HubSpot workflows · Custom LLM action · Claude · Python
1Enquiryform or email2Guardfirst step3Exclusionsrules firstAI4AI classifiesfixed categories5Review queuea person approves6Handoverto the right queue7Recoveryretry flag

Choose a part of the drawing to see what it does.

Drawing of how AI-assisted enquiry handling in HubSpot works, part by part.

  1. The enquiry text is treated as untrusted: the AI step reads it as data, never as instruction.

  2. The workflow’s first step checks that the record belongs here. Manual enrolment bypasses triggers in HubSpot, so the guard catches it.

  3. Fixed rules decide eligibility before any model is called.

  4. HubSpot’s workflow action for a model you connect returns one category and a short reason.

  5. A segment of enquiries awaiting a decision. Approval is recorded on the record itself.

  6. An approved enquiry is handed to its queue by the second workflow.

  7. An interrupted handover is found by a recovery view and released with a retry flag, without re-running the AI.

The problem

Every enquiry should reach the right place quickly, without a model deciding anything that matters on its own.

What I engineered

Two HubSpot workflows. A guard admits only intended records; fixed rules exclude first; an AI action sorts the enquiry into fixed categories with a reason; a review queue holds it for a person; approved enquiries are handed over; a retry flag recovers anything interrupted.

Key decisions

  • Exclusions run before the model, so the AI never sees what a rule can settle.
  • The AI writes a category and a reason; branches and rules decide what follows.
  • Turning the AI off was tested: enquiries fall back to manual review.

What the work demonstrated

  • Sorted every graded test enquiry correctly, including one written to trick it into approving itself.
  • Falls back to manual review when the AI step is switched off.
  • Recovers interrupted handovers without repeating them.

Where it could be applied

Intake and routing assistants inside a client’s HubSpot, scoped to their categories, queues and approvals.

See it run, case by case

HubSpot workflowsCampaign operations

Plate05

Understanding HubSpot revenue flows before making changes

Examines lifecycle rules, unexpected automation behaviour and the wider consequences of CRM changes.

With
Claude Skill · HubSpot API · Read-only hook · Python
1HubSpotlead flow2Read-only capturehook allows reads3Evidence analysisdeterministicAI4Reasoning14 rules, 5 in code5Findingsobserved · inferred · not established6Change recordplan and stop rules7Staged writeone record, then the next8Re-readuntil readings agree

Choose a part of the drawing to see what it does.

Drawing of how Understanding HubSpot revenue flows before making changes works, part by part.

  1. A HubSpot environment with a small lead flow built to contain deliberate faults.

  2. A hook in front of the HubSpot tools permits read calls only. A write is refused before it leaves the machine.

  3. Ordinary software turns records and their history into evidence the reasoning can cite.

  4. The Skill reasons over the evidence under written rules; the five that matter most are checked mechanically.

  5. Each finding states its level of certainty and the evidence behind it.

  6. Before any write: what changes, what is watched, how it would be reversed, and three reasons to stop.

  7. The first record is changed and checked before the second is touched.

  8. HubSpot recalculates some values in the background, so checks repeat until three readings agree.

The problem

Find what is wrong in a HubSpot lead flow without touching it, and know what a fix would cost before anyone makes it.

What I engineered

An inspection Skill with a ten-part plan and fourteen reasoning rules, five of them enforced in code. Capture runs through a hook that allows only read tools; deterministic analysis prepares the evidence; findings are labelled observed, inferred or not established. A separate exercise changed and restored two test records under a written change record.

Key decisions

  • Read-only is enforced by the tooling, not by instruction.
  • Trap cases and a deliberately bad reference output prove the scorer can tell good findings from plausible ones.
  • The repair was rehearsed before it was recommended, and its cost reported in full.

What the work demonstrated

  • Inspects a CRM without changing it, and says how each finding is known.
  • Showed that restoring a lifecycle stage can leave its historical reporting values changed.

Where it could be applied

CRM diagnostic agents that inspect without writing, explain how each finding is known, and price a repair before it is made.

The change, worked through on the HubSpot page

CRM diagnosticsHubSpot workflowsSkills & tooling

Plate06

Operations Control Tower: coordinating connected GTM workflows

Brings together activity records, exception checks and oversight across connected workflows, helping teams spot duplication and prevent avoidable mistakes.

With
Python · HubSpot API · Microsoft Graph · launchd
1CRM, mail, jobsand DNS, files2Allowlist guardendpoints, paths3Collectorsread only4Activity recordevery touch and outcome5Pre-send checkpass · warn · block6Founder releases7Morning viewone page8Pause filestops everything

Choose a part of the drawing to see what it does.

Drawing of how Operations Control Tower: coordinating connected GTM workflows works, part by part.

  1. Every system that records what the operation did.

  2. The tool may reach only the endpoints, commands and paths it names, and no redirect is followed.

  3. Each collector reads and records; none can write to the systems it reads.

  4. One reconciled record across every workflow: what was sent, to whom, and what came back.

  5. Each planned recipient is checked against the activity record and suppressions before a send.

  6. The send goes only when a person releases it.

  7. What ran, what failed, what came back, on one page each morning.

  8. Creating one file stops every collector until it is removed.

The problem

When outreach runs across several markets and tools, someone needs to see each morning what happened everywhere, and a send that should not go needs stopping before it happens.

What I engineered

Collectors read the CRM, the mailbox, the scheduled jobs, DNS and shared files, read only. An activity record reconciles every touch and outcome across the workflows. A pre-send check gives each recipient pass, warn or block, and a morning view brings it together.

Key decisions

  • An allowlist guard names every endpoint, command and file path the tool may touch, and refuses redirects.
  • A rotated credential is discarded, never stored.
  • A single file pauses everything.

What the work demonstrated

  • Catches misaddressed sends before they leave.
  • Flags duplicates, repeat first contacts and follow-up limits across workflows.
  • Lets a person pause every workflow at once.

Where it could be applied

Campaign QA and assurance agents that check a send against history, suppression and policy before anything leaves.

Campaign operationsMonitoring & assurance

Plate07

Scheduled cloud research and monitoring

Runs information-collection and monitoring jobs on cloud infrastructure with controls for repeatability, failures and resource use.

With
Azure Container Apps Jobs · Azure Files · Python
1Schedulesthree each morning2Slot lockno double runs3Container jobcode read-only4Public sourcesboards, press, news5Digestdeduplicated, classified6To research7Watchdogchecks the runs8Cost guardapproved resources only

Choose a part of the drawing to see what it does.

Drawing of how Scheduled cloud research and monitoring works, part by part.

  1. Discovery, collection and watchdog run at fixed times, without any local machine.

  2. A run that finds its slot taken records itself as a skipped duplicate and stops.

  3. The job runs code from a read-only share; only its state share can be written.

  4. Job boards, press wires, agency news and company newsrooms, each recorded as full or partial.

  5. New items, deduplicated and classified, with the sources that answered only in part.

  6. What merits a look goes to the research workflow and a person.

  7. A later job checks that the others ran and completed, and records the result.

  8. Fails unless exactly the approved cloud resources exist.

The problem

Watching public sources every day should not depend on a laptop being open, and should never quietly cost money or run twice.

What I engineered

Three scheduled container jobs: discovery of new companies, daily collection from job boards, press and newsrooms, and a watchdog that checks the others ran. Code lives on a read-only share and state on a separate one; results are deduplicated, classified and handed to research.

Key decisions

  • A slot lock makes a second run in the same window record itself as skipped.
  • A cost guard passes only when exactly the approved resources exist; expected cost is under a dollar a month.
  • Code is uploaded only when its tests pass, and a container test runs before anything ships.

What the work demonstrated

  • Runs research jobs every morning without depending on a laptop.
  • Records a second run in the same window as skipped, instead of running twice.
  • Reports which sources answered in full, so gaps are visible.

Where it could be applied

Monitoring agents that watch markets, systems or data quality on a schedule and raise only what needs a person.

GTM intelligenceMonitoring & assurance

Plate08

Opportunity signals and follow-up orchestration

Combines signal evaluation, evidence checks and workflow coordination to support timely, relevant follow-up while keeping consequential actions controlled.

With
Python · Claude and Codex · launchd
1Signalsjobs, press, newsAI2AI judgefixed schema3Quote checkin code4Weekly queuea handful of cards5Founder decidespursue · watch · reject6Dated factsfrom records7Stage controllerfails closedAI8Drafting workerbounded evidence9Validatorschema and policy

Choose a part of the drawing to see what it does.

Drawing of how Opportunity signals and follow-up orchestration works, part by part.

  1. Public signal families, with context that never counts on its own.

  2. A model judges each signal in a fixed structure with quoted evidence.

  3. Every quote must appear in the source text.

  4. Only what passes reaches the queue.

  5. Every decision is a person’s, recorded with a command.

  6. What has happened with each contact, computed as of a date from the records.

  7. Deterministic rules decide whether a follow-up is due; anything unclear stops.

  8. A model drafts from a bounded packet of evidence, with a second model as fallback.

  9. Every draft is checked against structure and policy before anyone sees it.

The problem

Notice the few signals worth acting on, and prepare the right follow-up at the right time, without a model ever sending anything or spending without limit.

What I engineered

Two controlled pipelines. Signals: sources feed an AI judge with a fixed schema; quotes are verified; a weekly queue of a handful of cards reaches a person to decide. Follow-up: dated facts feed a stage controller that fails closed; bounded evidence goes to a drafting worker; a validator checks every draft against schema and policy before a digest reaches a person.

Key decisions

  • There is no write path from these pipelines to email or the CRM.
  • Reading the records moved from a model using tools to direct API calls: faster, and with no room for invented values.
  • Paid enrichment is blocked in code; other spend has a per-run and a total cap.
  • The shared Skills are deployed byte for byte and verified by hash; results are reused only when policy, prompts and evidence are unchanged.

What the work demonstrated

  • Keeps consequential actions controlled: nothing in these pipelines can send email or write to the CRM.
  • Brings only the few signals worth a decision to a person.

Where it could be applied

Lifecycle and follow-up orchestration that prepares the next step for a team, with the send and the judgement left where they belong.

OrchestrationCampaign operationsSkills & tooling

How things are built here

Four habits that run through every drawing.

  1. Seal the answers before the run

    Test cases and their right answers are written, and often hashed, before a build sees them, sometimes by an independent agent. The research workflow and the signal-to-action build were both scored this way.

  2. Test the failure, not just the path

    Kill switches switched off mid-run, a model key removed, two approvals at the same instant, a crash between writes. The interesting behaviour is what happens when something goes wrong.

  3. Keep the model’s authority small

    Models read, judge and draft. Software checks, records and stops. The consequential step sits behind a person, a rule or both, and no model in these builds holds a tool that can send or write on its own.

  4. Write down what did not work

    A diagnostic report that was correct but not yet useful, which led to a redesign; a restore that brought back a value but not its history; a research method whose recall is the next thing to improve. Each is kept, because it is what the next build learns from.

On the bench

Smaller builds, tools and prototypes.

  • Ask MarOps Lab, the assistant on this site

    A deterministic matcher over authored answers, chosen after a language model was evaluated for the job and judged not yet ready. A seam is in place for a model above the matcher.

    • No visitor text leaves the browser
    Why it uses no model yet

    Skills & tooling

  • Reusable AI Skills

    Research and messaging Skills with written rules and regression cases, shared by Claude and Codex and deployed byte for byte with hash checks.

    • Versioned at source
    • Regression-tested on change

    GTM intelligenceCampaign operationsSkills & tooling

  • Clay and AI agents: engineering GTM intelligence

    I used an AI agent to operate Clay directly, build a controlled company-data table and run enrichment, hiring-signal checks and Claygent research.

    The work connected Clay’s results with independent public-source and agentic research, exposing where useful intelligence emerged and where data or identity matches could mislead.

    I built a reusable verification workflow that checks company identity, source quotations and job-posting evidence before research findings enter an account evidence pack.

    What was demonstrated: A connected research workflow that brings together Clay enrichment, AI investigation and source verification before findings are used.

    GTM intelligenceSkills & tooling

  • Backups that check themselves

    Every runtime repository, its uncommitted work and its state bundled daily, with every file and the whole history scanned for credentials first, and a restore check that runs the tests on what it restored.

    • Daily, 14 days kept
    • Restore verified by tests

    Monitoring & assurance

  • This website

    Typed evidence classes the build enforces, a publication gate that keeps review material out of every public build, and a verification suite across devices, motion settings and no-script reading.

    • Accessibility checked on every page
    • Release check on every build

    Monitoring & assuranceSkills & tooling

Where these lead

What this engineering makes possible to build.

Not products on a shelf: the kinds of capability I can design and build for a client, combining software, APIs, automation, language models and human judgement, each scoped to the job and its risks. The drawings show where the engineering already exists.

What could we engineer? The full applications map HubSpot Engineering

Have a job you would like engineered?

Describe the work that piles up, the decision that waits, or the check that should never be skipped. We can work out what to build, what it should be allowed to do, and how to test it before it runs.

Discuss a requirement