Harness patterns: what ports from Ray to the phData work-agent, and what gets rebuilt

The question

RDCO is, for the first time, deploying a second agent: the phData work-agent, air-gapped from Ray, running on the founder's locked-down corporate machine. This is a live natural experiment in the agent-deployer / fractional-FDE thesis. Which harness layers port cleanly from Ray to agent #2, and which carry a bespoke per-deployment rebuild tail? The honest version of this question is the falsifiable test of the positioning: if "deploy a 2nd agent" is genuinely fast and repeatable, the FDE/HaaS pitch holds; if each deployment is a long bespoke slog, it doesn't.

What we already know (from the vault)

The two-layer portability model is already codified. [[2026-05-10-harness-moat-two-layers-portability]] (written in answer to the founder's own "how much is portable to the next one?" question) splits the harness into:

• Layer 1 — Universal harness discipline (PORTABLE). ~90% of what makes Ray work: the ratchet pattern (/improve), hooks-as-enforcement, subagent routing for context rot, splits-for-evaluation (fresh-eyes critics), the skill format, the generative-UI return channel, vault-as-nervous-system, the Notion-board / todo+loop distinction, and the memory file format. "Portable as-is."
• Layer 1.5 — Adaptable integrations (CONFIG-SWAP). ~50% adapter work: MCP server choices (Gmail vs other), deploy targets, bets.json rows, skill ON/OFF. Mechanical, not earned.
• Layer 2 — Personal-fit accumulation (EARNED, NOT PORTABLE). ~10%: the CLAUDE.md hard rules (each traces to a specific founder failure), failure-driven memory files, vault content, voice match. "Operating-time IS the moat, full stop" — only at this layer.

The model has already been operationalized once, as a templatization artifact. [[2026-05-13-ai-demo-day]] / the Ray-Starter-Kit ("coo-in-a-box") scope proves the layers are real by separating them mechanically: it ships SOUL/CLAUDE templates with [[OPERATOR]]/[[PRIMARY_CHANNEL]] placeholders, 12 sanitized skills, a generalized audit script, a scheduled-jobs.template.txt, and an empty MEMORY.md index — while deliberately shipping zero actual memory files or vault content (Layer 2). The per-file sanitization map and the grep pre-publish gate are the concrete evidence of where Layer-1 ends and Layer-2 begins. Estimated build: ~10-13h to package the universal layer for a stranger.

The phData deployment's actual shape is documented and is deliberately simpler than Ray. [[2026-05-30-phdata-work-agent-setup-plan]]:

• Air-gapped, confirmed — the two agents never share context (client confidentiality is phData's business).
• Session-based, NOT always-on. Claude Code launched per work session on the work box; no LaunchAgent, no 4am restart, no tmux daemon. This drops a whole infra layer rather than porting it.
• MVP = email-draft-triage: Gmail create_draft into drafts, human-gated send (same rule Ray runs, [[feedback_no_autonomous_external_email]]).
• The work machine is locked down: auto mode unavailable; Atlassian/Zoom/Slack connectors blocked; Gdrive connector blocked; Gmail connector uncertain; Bitbucket not GitHub; LastPass not 1Password, and LastPass CLI breaks on federated SSO.
• The load-bearing discovered pattern: connectors die, filesystem survives. Gdrive-for-Desktop is read as a normal filesystem; "filesystem is the universal escape hatch for blocked connectors."

Ray's own topology is the thing being NOT-ported. [[project_channels_agent_setup]]: Mac Mini, LaunchAgent (com.claude.channels.plist), tmux session claude-channels, daily 4am restart with claude update, acceptEdits + expanding allowlist, Full Disk Access for iMessage chat.db. [[2026-05-15-nateherk-3-ways-to-deploy-claude-agents]] confirms RDCO is "Method 1, hardened" — 13 active crons in tmux under a supervising LaunchAgent. Almost none of this boot-persistent daemon stack transfers to a session-scoped agent.

The verification layer is a portable pattern with locally-rebuilt rubrics. [[2026-05-19-verification-as-independent-worker-pattern]]: the structural rule (a producer can't verify its own work; route through a fresh-eyes subagent that reads the rubric fresh and scores mechanically) is universal Layer-1 discipline. But the rubrics it scores against (/verify-vault-write, /verify-strategic-output, /verify-dispatch) are RDCO-surface-specific; a phData agent would inherit the pattern and the skill shape, then author its own client-appropriate rubrics. [[2026-06-01-garry-tan-stop-building-foxconn-factories-for-agents]] stress-tests whether the verification layer is even worth porting — Tan calls heavy verification a "Foxconn factory / cage" — but RDCO's counter is that the gates exist because the parent loop fabricated 12x in one morning (2026-05-31), so the lean version ports; the cruft doesn't.

What the web says

External 2026 commentary converges on the same split, in different vocabulary:

• The FDE "learning loop" maps exactly onto the two-layer model. Mature forward-deployed-engineering orgs run three phases — artisan (solve high-value bespoke problems on-site), industrial (standardize what works into repeatable assets), orchestration (scale via partners/ecosystem). The discipline is: "field work exists to generate the product, not just revenue" — when the same structural problem (e.g. entity resolution) shows up across customers "with different surface characteristics but the same structural core," it gets abstracted into a reusable primitive and pulled upstream into the platform. This is RDCO's Layer-1-extraction loop described from the outside. (Palantir model analysis; ServiceNow/Accenture FDE program; TSIA.)
• "Custom-per-customer vs platform" is the explicit named tension. A custom-solutions model rebuilds for each customer; a platform model "continuously encodes deployment knowledge into reusable tooling that improves every future engagement." The differentiator is whether each deployment feeds back a reusable component.
• Harness portability is an active product category. OpenHarness.ai positions as a "write-once, deploy-across-runtimes" interoperability SDK (Anthropic SDK, Goose, LangChain, Letta, Claude Code) defining a standard interface for tools/memory/execution contexts. The Open Agent Spec (arXiv) pushes framework-agnostic, component-based reusability. The Epsilla "12 reusable agentic harness design patterns from Claude Code" piece catalogs the exact primitives (skills, hooks, memory, subagents, orchestration) RDCO treats as Layer 1. Translation: the universal layer is commoditizing into standards — which is precisely the harness-moat doc's claim that Layer 1 has "no time-arbitrage advantage."

Convergences and contradictions

Convergences:

• Vault (Layer 1 / Layer 2) and web (artisan→industrial→orchestration; custom-vs-platform) agree the pattern/discipline is portable and the accumulated personal-fit is not. Independent arrival, same structure.
• Both agree the moat lives in being the discipline-bearer / loop-runner, not in any single deployed instance. RDCO: "RDCO has a moat as the discipline-bearer." FDE lit: "FDE's future is about learning, not deployment."
• The phData experiment confirms a vault prediction in advance: the setup plan reaches for templates + filesystem-universality and explicitly declines to clone Ray's daemon stack — i.e. it instinctively ported Layer 1 and dropped the non-portable infra.

Contradictions / tensions:

• The "90% portable" figure is optimistic for this deployment. The harness-moat doc's 90/10 split was framed for "a fresh Ray for another solo founder running the same architecture." phData violates two of those assumptions at once: it's a different deployment shape (session vs always-on) AND a hostile environment (locked-down corp box). The portable share holds at the pattern level, but the integration tail (Layer 1.5) is bigger than the "trivial config swap" the doc implies — federated SSO breaking the secrets CLI, every connector blocked, no auto mode. Layer 1.5 is doing more work here than advertised.
• Tan vs the verification SOP is a genuine unresolved tension about whether part of Layer 1 is worth porting at all. The vault's own resolution ("scalpel, not bonfire — audit which checks earn their keep") is the honest answer, but it means the verification layer is not a clean copy-paste; it needs a per-deployment earns-its-keep audit.

Synthesis for RDCO

PORTS-CLEANLY vs NEEDS-REBUILD ledger (the load-bearing artifact)

What this implies for the agent-deployer / FDE positioning

The honest verdict: "deploy a 2nd agent" is fast and repeatable at the pattern layer, but each deployment carries a real (bounded) bespoke tail — and the tail is dominated by the environment, not the agent.

• The optimistic read (90% ports) is true about the harness discipline and is corroborated by both the starter-kit's ~2-day package estimate and the external FDE "extract-reusable-primitive" loop. The skill library, memory format, verification pattern, secrets principle, and loop concept all genuinely transfer. RDCO is not rebuilding the agent each time.
• But phData reveals the falsifiable cost lives in Layer 1.5 + the perimeter, and it's larger than "trivial config swap" when the target environment is hostile. The deployment-shape change (always-on → session) and the lockdown (blocked connectors, federated-SSO-breaks-secrets-CLI, no auto mode) are exactly the kind of per-customer surface variation the FDE literature says you expect and learn from. The right framing isn't "is there a tail?" (there always is) but "does each tail feed a reusable primitive back upstream?"
• The agent-deployer thesis survives this test, with one correction to the pitch. The sellable moat is RDCO-as-discipline-bearer (the loop-runner who knows which rules accumulate in what order), exactly as the harness-moat doc claims and the FDE lit independently confirms. But RDCO should stop quoting "90% portable" as a deployment-speed promise. The accurate promise is: the universal harness ports in days; the perimeter integration is the engagement. phData's perimeter work (the filesystem-escape-hatch discovery, the secrets-CLI workaround, the connector-blocked map) is itself the reusable primitive — a "locked-down corporate deployment" playbook RDCO didn't have before and should now extract upstream. That extraction loop is the industrial-phase move the FDE model describes, and it's the difference between bespoke-per-customer and platform.

In one line: agent #2 confirms the harness is portable and the environment is the product. The FDE positioning is sound; the pitch should sell perimeter-mastery, not a portability percentage.

Open follow-ups

1. Extract a "locked-down corporate deployment" playbook upstream from the phData constraint map (filesystem-escape-hatch, federated-SSO secrets workaround, connector-blocked fallbacks). This is the first reusable primitive the 2nd deployment generated — does it get pulled into the starter-kit / a new SOP?
2. Re-measure the Layer-1.5 adapter cost honestly post-phData: the harness-moat doc estimates "~50% adapter work, mechanical." Was that accurate for a hostile environment, or does Layer 1.5 need a sub-tier for "hostile-perimeter integration" that's closer to bespoke?
3. Does the verification layer port at all into a client-confidential context? Per Tan, audit which /verify-* checks earn their keep for a read+draft-only agent with no public surface — possibly a much thinner gate than Ray's.
4. Comms-surface decision for phData (terminal-direct vs a channel) determines whether channel-as-state / open-threads is even rebuilt or dropped entirely. Still open in the setup plan.
5. Should the phData experiment be written up as the FDE-positioning proof point — the first time RDCO deployed a 2nd agent and measured the port-vs-rebuild ledger — for the agent-deployer / Ray-as-a-Service candidate bet?

Related

• [[2026-05-10-harness-moat-two-layers-portability]] — the canonical two-layer (portable vs earned) model this brief operationalizes against a real 2nd deployment
• [[2026-05-30-phdata-work-agent-setup-plan]] — the actual constraint map and shape of agent #2
• [[2026-05-19-verification-as-independent-worker-pattern]] — the verification pattern (ports) vs rubrics (rebuild) row of the ledger
• [[project_channels_agent_setup]] — Ray's always-on topology, the thing deliberately NOT ported
• [[2026-05-15-nateherk-3-ways-to-deploy-claude-agents]] — RDCO as "Method 1 hardened" + the 13-cron manifest
• [[2026-06-01-garry-tan-stop-building-foxconn-factories-for-agents]] — the stress-test on whether the verification layer is worth porting

Sources

• Vault: harness-moat two-layers, phData work-agent setup plan, verification-as-independent-worker SOP, channels-agent setup, Ray-Starter-Kit scope, Nate Herk deploy-methods note, Garry Tan "Foxconn factories" note (all cited above)
• Forward Deployed Engineer (FDE): The Essential 2026 Guide — Rocketlane
• A Comprehensive Analysis of Palantir's Forward Deployed Engineering Model — Medium
• ServiceNow and Accenture Launch Forward Deployed Engineering Program — Accenture Newsroom
• What Is Forward Deployed Engineering? — TSIA
• Deep Dive: 12 Reusable Agentic Harness Design Patterns from Claude Code — Epsilla
• Top AI Agent Harness Tools and Frameworks 2026 — Atlan
• Open Agent Specification (Agent Spec) — arXiv