Replicate (lab → live)

Replication is not authoring a new agent. It is a verbatim copy of an existing published agent from a source namespace into a target namespace — the classic case being lab → live. It composes nothing and changes nothing in transit; it re-creates the same identity elsewhere. But it keeps every gate, applied per agent.

Authoring vs replication

	Compose a new agent	Replicate
interview	yes (scope-agent-lite)	no — there’s nothing to shape
what it writes	a new, distinct identity	the same published identity, unchanged
scope	one new agent	a bounded, explicitly authorized set (source → target, named ids)
gates	grant · soul-first · authorized publish · verify	grant · soul-first · authorized publish · verify (per agent)

The flow

For each agent in the authorized set:

1. Read the source agent’s published soul, skills, and ADL v2 layouts from the source namespace;
2. Stage them locally (the same caller-writes-files discipline);
3. Re-upsert them unchanged into the target — soul first, then skills, then layouts;
4. Publish with direct_user_authorization=true — the publish validates the drafts and snapshots them, under its own authorization, per agent;
5. Verify installability on the target (agent_interface_validate / agent_interface_status).

Replicate these agents from theorycloud on lab.theorymcp.ai into theorycloud on
theorymcp.ai, verbatim: apptheory, tabletheory
For each, in order: read the source's published soul/skills/ADL layouts, stage them locally,
re-upsert them UNCHANGED into the target (soul first, then skills, then layouts), then publish with
direct_user_authorization=true (publish validates the drafts and snapshots them), then confirm
installability with agent_interface_validate/status — one explicit authorization per agent. Do not
edit any soul or skill in transit. Stop and report if a publish fails closed on incomplete drafts.

Verbatim, gated, per agent

Replication is a verbatim copy under an explicit, bounded authorization. It is never a license to edit the soul or skills in transit (that would be a separate, deliberate authoring change), and never a way to bulk-publish around per-publish human authorization. Each replicated agent is published under its own direct_user_authorization (which validates its drafts) and verified installable, soul-first.

Why a separate practice

Bundling a “read from source” and a “publish to target” into one unattended sweep is exactly what the gates exist to prevent. Replication keeps the pull and the push explicit and per-agent, so “the namespace is the source of truth” holds in both namespaces at once: you copy what source published, and target only reaches published through its own authorized publish.

Open the mode for replication

The scope grant for replication names the bounded set up front:

I want to replicate from theorycloud (lab) to theorycloud (live). Confirm the authoring tools are
present on the target route, then record an authoring-scope grant for a REPLICATION set: source
theorycloud on lab.theorymcp.ai, target theorycloud on theorymcp.ai, agent_ids [apptheory,
tabletheory]. State that this opens the draft
surface only and that each agent's publish needs its own authorization. Then begin, one agent at a
time.

Back to the authoring overview → Authoring & the gates. Or see the whole tool surface → MCP tool surface.