OPEN TO FORWARD-DEPLOYED AI ROLESPRINCIPAL-LEVEL ENTERPRISE DELIVERYFORT LAUDERDALE, FL · US EASTERNREMOTE · TRAVELDIRECT LINE: PETER@PETERCBENNETT.COM

AI that works has to fit the business, the people, and the systems already running.

Most AI work dies between the demo and the workflow. Closing that gap takes someone who learns how your operation works first, then builds the version your team can absorb and operate. I do that work, with two years of forward-deployed AI engineering and a decade of customer-embedded delivery behind it.

Discuss a role or project Read the résumé

THE WORK

Selected work.

five cases, problem first

Each case runs in the same order: the problem it started from, what I did about it, and what came of it. Two of them, CaseFlow and Local Workspace MCP, publish their source for any engineer who wants to read it.

Technical illustration of a processing line in cutaway: documents travel through an intake tray, an open machinery bay, a small chamber, and a raised checkpoint booth staffed by a standing figure, ending in a filed archive — How the system runs: intake, deterministic machinery, a bounded model chamber, a human decision at the gate, and an auditable archive.

Reference implementation · public repo

CaseFlow

A claims workflow where a model does bounded work and people keep authority over the outcome. The problem: AI output that affects real decisions needs human authority and a recorded trail. My answer keeps evidence handling, narrowly scoped model tasks, human approval gates, and recorded state deliberately separate. It runs on a synthetic workload, so it shows the control design and nothing about live traffic.

21-node workflow · 4 scoped AI tasks · 3 human-review gates · public repository

Read the CaseFlow case study Read the source (opens in a new tab)

Technical illustration of an instrumented cabinet of latched document compartments, one drawer opened beneath a brass-armed magnifying lens, a separate fixed-position cam selector beside it, and a narrow channel carrying a single sheet to a collection tray — Declared roots open for reading, every other compartment stays latched by default, and a small fixed set of named tasks is the only actuator.

Open-source release · npm + MCP Registry

Local Workspace MCP

An AI assistant gets useful access to the workspaces an operator declares, and nothing else by default. The problem: assistants need real context to be useful, and a home directory is too much to hand over. The MCP server behind it has twenty-three read-oriented tools behind declared-root containment, including bounded inspection of images, archives, PDFs, and Office documents, with a published threat model. The one execution path is a named task the operator allowlisted: a real command run as the user, not a sandbox.

23 read-oriented tools · default-deny containment · 276 tests · public threat model

Read the MCP case study Read the source (opens in a new tab)

Technical illustration of a large routing board where sixteen cord clusters converge on one ordered central spine — Sixteen specialized agents feeding one deterministic spine: agents handle bounded tasks; the spine owns state, scheduling, and approvals.

Independent project · 2025–26

LeadsON

A long-running business workflow run by agents a person can still trust. The problem: multi-agent systems lose accountability when models own the state. I kept generation and classification in the models, and state, scheduling, and approvals in deterministic code: 16 specialized agents coordinated through 25+ queues and an 18-state workflow. Sole engineer; the numbers describe engineering scope and validation, not commercial traction.

16 specialized agents · 25+ queues · 18-state workflow · 1,700+ tests

Read the LeadsON case study

Technical illustration of a large analog meter with its needle pointing low on a descending scale, beside a stable instrumented structure — The program's shape: recurring spend falling toward a new baseline while the platform stayed standing and kept shipping.

Director of Technology · 2018–25

TTAC Publishing

Cloud cost and launch-day reliability had to improve together across three commerce properties. As the executive team's technical owner for architecture, governance, and hands-on delivery over seven years, I ran a multi-year modernization. Recurring AWS spend fell by more than 90% while uptime held at 99.97% and release cadence roughly tripled, results accumulated across a program of work.

>90% lower recurring AWS spend · 99.97% uptime · ~3× release cadence

Read the TTAC case study

Technical illustration of two differently built structures joined across a gap by a newly built truss, with pipes continuing through the join — Post-acquisition integration: a deliberate connection between two working systems, built only after the existing one was understood.

Embedded delivery · 2007–18

Hearst Magazines

After a $10M+ acquisition, a live social platform had to be connected to Hearst's systems. I embedded onsite with the acquired company's executives and engineers, learned the unfamiliar production platform first, then defined and personally implemented the integration path. It was customer-embedded delivery years before the forward-deployed title existed, with the same pattern: understand first, then build.

APIs tied to $50M+ recurring revenue · 1M+ monthly visitors

Read the Hearst case study

THE PLAN

What working together looks like.

six chapters, each ending with something you can see

The same sequence sits behind every case above, in the order the work happens. Each chapter says what I'm trying to understand at that stage, what I do, what you see from me, and how we both know it's time to move on.

Read the method in full

Technical illustration of an observer's chair and open notebook beside a working bench, with sight lines drawn from the notebook to specific objects in mid-use — Watching the work as it runs before anything gets written into a requirement.

CHAPTER 01

Understand the real work

What I'm trying to understand: Who does the work today, which decision the system must support, and what a wrong answer costs, named before anyone writes a requirement.
What I do: A written discovery record, not a proposal: the real workflow and its workarounds, the systems of record, the trust boundaries, and a consequence table that prices each kind of wrong answer. Missing evidence becomes a labeled question or an owned assumption, never an invented fact.
What you see from me: The discovery record itself, open to your team's corrections: what triggers the work, who it serves, the one path that must demonstrably work, and the explicit no-gos.
What tells us we're ready to move: The people doing the work recognize the description, the constraints are named, and observation has outranked stakeholder preference.

Technical illustration of a weighing station where rejected proposal sheets fill a bin while one surviving sheet rests on a raised platform beside a wax seal — Most candidate changes get rejected on paper; the one that survives gets recorded.

CHAPTER 02

Figure out what needs to change

What I'm trying to understand: Which change would matter to the owner of the outcome, and whether it should be built at all.
What I do: The request gets red-teamed in writing: is it a real workflow failure or an elegant abstraction, what would make users not adopt it, where could the builder falsely declare success. Then the outcome is stated in your terms, with the promises not made written beside it.
What you see from me: A plain-language outcome agreement: what changes, for whom, what success looks like, and what is explicitly not promised.
What tells us we're ready to move: The owner signs the description of success, in terms a non-engineer can check.

Technical illustration of a large complex machine in faint linework with one small subsection lifted out and mounted alone on a pedestal under a spotlight — The smallest piece that still crosses the real path gets pulled out and proved on its own.

CHAPTER 03

Shape the smallest change that can prove something

What I'm trying to understand: The thinnest piece of work that exercises the riskiest assumption end to end.
What I do: I cut scope until what remains still crosses the production path: real input, a real decision, a real consequence. The slice gets a named owner, explicit failure paths, and a definition of done agreed before implementation.
What you see from me: One scoped piece of work that either runs or tells us specifically why not, learned in weeks, not months.
What tells us we're ready to move: The slice fits inside the existing workflow, and its failure would teach us something we don't already know.

Technical illustration of a junction bench where a half-assembled instrument is being joined to heavy cables and pipes arriving from the edges of the scene — The work gets joined to the systems it has to live inside, not a stand-in for them.

CHAPTER 04

Build it against reality

What I'm trying to understand: Whether the design survives live data, latency, and edge cases rather than demo conditions.
What I do: I build against the actual sources of truth, in the environment the work has to live in. Model output is bounded: typed in, structured out, validated before it can change anything. Where the call is consequential, a human keeps authority over it.
What you see from me: Working software early, exercised on ugly inputs, plus a written boundary of what the system may and may not decide.
What tells us we're ready to move: It runs on the real path, with a person able to inspect and override it.

Technical illustration of a stress-test rig where gauges, a micrometer arm, and a chart recorder press against a clamped component while a paper tape of results spools out — Results come from load. The tape keeps what the rig found.

CHAPTER 05

Prove it before calling it done

What I'm trying to understand: Whether it does the thing under conditions that could embarrass it.
What I do: Changes start with a failing test, and uncertainty gets researched before it gets invented. After two failed fixes, patching stops for a written diagnosis, not a third guess. Where the work is consequential, someone who didn't build it tries to break it.
What you see from me: Test runs, regression counts, what failed and what changed because of it.
What tells us we're ready to move: The proof answers the question the slice was shaped to ask, and the failure modes are documented.

Technical illustration of an installed unit on a concrete pad in open ground with a thin line drawn from its sensor back to an open logbook on a field table — Once it's in the field, the readings flow back into the record and shape the next round.

CHAPTER 06

Put it into production and learn from what happens

What I'm trying to understand: What happens when the people who own the work depend on it.
What I do: It ships where it has to hold, then the field record starts: activation, time-to-value, confusion, adoption, failures, cost. When production contradicts the plan, the plan loses.
What you see from me: The system in use, a written record of what the field taught, and what the next change should be.
What tells us we're ready to move: There is no finish line here. What the field teaches feeds the next round of understanding.

THE RULES THAT DO NOT BEND

Local green is not release proof: A passing build on a workstation is a claim. Remote CI on the exact commit is the proof.
The builder does not certify the build: Consequential work ships through a reviewer who did not write it.
Model reasoning is not policy: What a model proposes and what the system may do are decided by different machinery.
No document outranks the field: When production behavior contradicts the plan, the plan loses.

THE MACHINERY

How the work gets built.

a change's path from request to proof

The method says what happens. The machinery makes it happen the same way every time, so your budget goes to your problem and not to rebuilding plumbing. Work starts at the smallest profile that satisfies the contract (a deterministic service, a bounded AI task, a durable workflow, or a human-in-the-loop product), and every change passes through the same gates.

Read the engineering foundation

Write the request down

What was asked for, on whose authority, and what evidence sits behind it. Nothing starts until the request is written down: the outcome, the owner, the no-gos.

Technical illustration of an intake desk where a request sheet is stamped and entered into a bound register, queued sheets waiting in a tray

Sort the task by what it could break

Every task is classified by what it could break before work begins. A cosmetic change and a consequential one get different machinery around them; risk decides the rigor, and the classification routes the work to its discipline.

Technical illustration of a sorting arm directing document sheets into three graded bins, the heaviest armored and strapped

Let the right discipline do the reasoning

Each task class routes to its own discipline. A database change gets tenant and concurrency proof. An auth change gets a threat model. An AI task gets typed input, a validator, and an eval suite.

Technical illustration of a long workbench with five distinct tool stations, one component traveling station to station

Stand checks at the boundary

Automated gates stand at the edges: strict typing, architecture boundaries, security and secrets scans, requirement traceability. What can be written as a rule is a check, not a reminder.

Technical illustration of a conveyor path of document sheets guarded by inspection arches with catch trays beneath

Test the exact change, not the idea of it

Remote CI exercises the exact candidate commit, not the system in general. A green local build is a claim; the remote run on that commit is the proof.

Technical illustration of a component sealed inside a glass test chamber ringed by analog gauges and measurement arms

Let someone else read it first

When the work is consequential, a reviewer who did not build it certifies it, bound to the same commit.

Technical illustration of an inspector's desk set apart, a finished component under a loupe beside a certificate being pressed with a wax seal

WHAT EVERY PROJECT INHERITS

The method governs: Customer truth, risk, and release decisions live in one written method. Sessions are caches; the repository is the authority.
Structure is durable: Every change carries a spec, a plan, and a task list as committed artifacts, auditable months later.
Specialists reason: Each task class routes to its own discipline and its own review.
Machinery enforces: Typing, boundaries, secrets, traceability, and fitness checks run as gates, not reminders.
Proof is external: Remote CI on the exact commit, then a second reader for consequential work.

THE PERSON

Off the clock.

who you'd be working with

A boyhood on St. Croix left him with salt water, heat, and the habit of starting early. The decades since kept the same shape: iron before the desk, long walks where the hard problems get walked into shape, a small table and good company at the end of the day. A Fort Lauderdale base now, with the beach still close enough to matter: Muscle Beach on training mornings down in Miami Beach, South Pointe when the boardwalk is empty. And a standing question about Rio de Janeiro he intends to answer in person.