pl8ypus

pl8ypus / Applied AI Systems

Applied AI systems. Build evidence. Operating model.

Production-shaped systems built for enterprise marketing operations, plus the build method and operating discipline behind them: an integrated workbench ecosystem with real constraints, review controls, protected surfaces, and deployment evidence.

Greg's take

Most AI portfolio pages show prototypes. This one shows systems - or at least what I believe qualifies as a system: a workflow problem, a control layer, evidence of what it does, and a review step before anything is trusted.

The question I keep returning to is not what the model can do. It is what the human operator needs to see, understand, and decide before the output goes anywhere useful.

These five builds each expose a real workflow failure in enterprise marketing. The systems do not just automate. They make the automation reviewable.

Applied AI Systems

Build 01

Tanya Build Cockpit

Operational
Structured prompts Project memory QA gates Agent roles Impl. packets

Problem

AI-assisted build sessions drift without structure, shared memory, or consistent QA checkpoints between sessions.

System built

AI-assisted build orchestration layer using structured prompts, project memory, implementation packets, QA gate patterns, and clear agent role separation. The operational scaffolding behind all other pl8ypus builds.

Why it matters

Shows the build discipline and AI collaboration layer that makes the other systems production-shaped rather than experimental one-offs.

View Tanya Build Cockpit →

Build 02

Translation AI

Planned
Anthropic API Protected terms QA gate Human review GitHub versioning

Problem

Marketing translation done manually and inconsistently, with no protected-term enforcement, review trail, or version control.

System built

Protected enterprise translation workflow with live translation, provider evidence, structured payloads, protected terminology, glossary handling, request logging, QA gates, and human review before outputs are final.

Why it matters

Proves repeatable AI workflow design with language-specific quality agents, control layer, evidence capture, and review discipline - not just a prompt wrapper.

View Translation AI →

Build 03

Campaign Copilot

In build
Historic emails Landing pages Outcomes Briefs

Problem

Campaign knowledge is scattered across emails, landing pages, outcomes, blog posts, project notes, and memory.

System emerging

A learning layer that turns historic campaign assets and project work into future campaign briefs, emails, LinkedIn posts, and reporting support.

Status

Emerging architecture, not finished production. The goal is a learning layer, not another generic content generator.

View Campaign Copilot →

Build 04

Marketing Form Protection

Enterprise used
Cloudflare Turnstile Workers KV storage Eloqua API Multi-form

Problem

Enterprise form spam does not just create bad submissions. It pollutes Eloqua data, damages campaign reporting, wastes sales time, and creates operational noise across marketing automation workflows.

System built

Cloudflare Turnstile and Eloqua protection layer with exception queue, direct forwarding, accept/reject handling, secured reviewer access, and multi-form architecture. Applied to a real enterprise Eloqua marketing environment.

Why it matters

Proves Greg can build applied AI-adjacent workflow protection around real marketing operations, with anonymised enterprise usage evidence.

View Marketing Form Protection →

Build 05

Lead Recovery AI

Concept build

Problem

High-intent prospects abandon marketing forms before becoming visible in Eloqua, Salesforce, or campaign reporting.

System built

A governed recovery layer for partial intent capture, consent-gated recovery journeys, AI-assisted completion, and CRM handoff.

Why it matters

Recovers demand that already reached a form while keeping compliance and human handoff controls visible.

View Lead Recovery AI →

Build 06

Audience Finder AI

Planned
Planned Worker Planned memory Accept/reject Scoring model Export ready

Problem

Audience targeting decisions made without structured evidence, scoring criteria, or human review controls at scale.

System planned

Planned AI-supported targeting workflow with scoring, evidence trails, manual accept/reject controls, queue management, export readiness, and a planned Cloudflare Worker backend with KV memory layer.

Why it matters

Planned human-in-the-loop design with evidence, scoring criteria, and operator review before any action.

View planned Audience Finder AI →

Build 07

Marketing Intelligence AI

Intelligence layer

Problem

Marketing teams need campaign, competitor, channel, and website intelligence pulled into one decision layer.

System built

A governed dashboard layer for turning scattered marketing signals into operator-ready insight.

Why it matters

Shows AI support for marketing strategy and evidence-led campaign decisions.

View Marketing Intelligence AI →

Build 08

Client Portal

Migration in progress
Cloudflare D1 Workers API Access/JWT Multi-client Request lifecycle Audit logging

Problem

Client support workflows managed across email, files, invoices, status updates, and memory - with no shared visibility, request tracking, or billing transparency.

System built

A lightweight client documentation and request portal with email PIN access, durable documentation storage, client-specific visibility, and Cloudflare-backed migration. Built around Greg's real support and retainer workflow without Jira or Confluence overhead.

Why it matters

Proves Greg can build the operational layer around client work, not just isolated prototypes. The kind of system that forward deployed engineers design inside real customer environments.

View Client Portal case study →

Build 09

Weekly Build Agent

Operational V0.1

Problem

Build progress disappears into chats, commits, and memory notes unless it is captured into reusable content.

System built

A local agent that turns Tanya memory and build records into draft-only weekly content packs.

Why it matters

Converts real build evidence into reusable marketing assets while keeping human review in the loop.

View Weekly Build Agent →

Pattern

Eloqua Visitor Identity Layer

Architecture pattern
Visitor GUID Hidden field SYSTEM - Eloqua ID CDO

Problem

Eloqua form submissions need a durable identity stitching key where the visitor GUID is available.

System built

Page JavaScript reads the Eloqua visitor GUID where available, injects it into a hidden form field, submits it with the form, and stores it in a SYSTEM - Eloqua ID CDO.

Why it matters

Supports CDO processing, CRM matching, campaign reporting, and visitor/contact stitching without blocking submissions when GUID is unavailable.

View Eloqua Visitor Identity Layer →

Build method

Controlled delivery from problem to deployed system.

The pattern is consistent across every build. Workflow first. Architecture second. AI-assisted implementation third. QA, deployment, and evidence documentation throughout - not as an afterthought.

01

Discovery and workflow mapping

Understand the existing workflow, the people in it, and where AI changes the decision point. Map data flows and review steps before writing a line of code.

02

System architecture

Design the smallest complete system: inputs, outputs, data model, review layer, error paths, and deployment shape. Choose infrastructure based on the constraints, not the trend.

03

AI-assisted implementation

Build with structured prompts, project memory, implementation packets, and clear agent role separation. No unreviewed AI output goes directly to production.

04

Human review and QA

QA gates, acceptance criteria, test auth flows, and edge case verification before each slice is considered done. The build log records what was checked and what passed.

05

Controlled deployment

Deploy slice by slice with verification at each step. No big-bang releases. Rollback path is always clear and documented before deployment begins.

06

Evidence capture

Document what was built, what decisions were made, and what the system does at a level operators and stakeholders can trust and audit.

07

Repeatable patterns

Every build produces reusable scaffolding: prompt patterns, QA checklists, architecture templates, and deployment scripts. Each new system starts from a higher floor than the last - which means the delivery accelerates without sacrificing quality control.

Operating principles

What makes a build production-shaped.

The model is one part of the system

The model call matters. The control layer around it - inputs, validation, review, error handling, audit - matters more for enterprise deployment.

Human review stays visible

Every AI output layer has a human-readable review step. Operators should not need to trust the AI blindly.

Inputs are validated before AI runs

Bad inputs produce bad outputs. Source validation, structure checks, and completeness gates run before the model call.

Rollback is always possible

Working versions and approved versions are separate. Recovery from a bad deployment is documented before deployment happens.

Build evidence is public

Progress, decisions, and architecture are documented in the open. Stakeholders can follow the build without needing a briefing document.

Claim nothing before it is done

Status labels reflect actual build state: prototype, migration-ready, production-hardened. No system is called production before it is.

Want to discuss an applied AI project?

For enterprise AI systems, marketing automation, or workflow integration projects. Also available for speaking and workshops.

About Greg