Dynamic-Workers Agent Composition — outline

A composable agent + tool library deployed as Cloudflare dynamic workers, optimized in KYM, and published to a NANDA node so on-demand agents can be summoned from any Nexartis web app. Runtime-capability categorization prefers dynamic workers over containers; containers land via HB3 only when a workload requires them.

Premise

1. Every published agent is a composable unit: a KYM Agent Card + a bundle of skill packages (per /research/scripts-as-tools) + a runtime-capability declaration.
2. The default deployment shape is a Cloudflare dynamic worker: sub-second isolate spin-up, capability-based bindings, deny-by-default sandbox, no container cold-start.
3. The variant matrix (model × harness × skill-set × skill-versions) is tuned inside KYM using the same receipts-and-bandit substrate as the harness-bandit study.
4. Winning variants publish to a Nexartis-operated NANDA node, making them discoverable by any Nexartis web app that needs an on-demand agent — the app requests capability X, NANDA returns candidate agents ranked by receipt-scored reputation, the app spins one up.
5. Runtime-capability categorization is explicit: dynamic worker → container → local host, in that order of preference. Containers only when the capability requires them (long-lived process, non-Workers runtime, container-only dependency). Containers ship via HB3 (the Nexartis container runtime, defined outside this paper).

Composition surface

• KYM Agent Card — The manifest. Names model, harness, skills (name + version-range per package), MCP allowlist, runtime-capability class, and the NANDA endpoint the winning variant is published to. Signed and versioned in KYM; every completed turn writes a receipt back.
• Skill packages — From /research/scripts-as-tools: pnpm-monorepo packages, tri-runtime portable (WinterTC min-common-api target with node-only / workers-only opt-outs declared in frontmatter). ChunkHound-indexed frontmatter provides progressive-disclosure discovery inside the agent.
• Runtime-capability class — Explicit categorization on the Agent Card: workers-only · workers-preferred · container-required · local-host-required. The dispatcher reads this field to pick the deployment shape without guessing.
• Cubicle adapter — @nexartis/cubicle-adapter-cloudflare-dynamic-worker — The canonical adapter for the dynamic-worker deployment path. Compiles the Cubicle spec into a dynamic-worker bundle with the capability-based bindings the skills declare. Already a link: dep of ozzydev; the source of truth is the SDK package under _NEXARTIS-SDKs/nexartis-cubicle-sdk/packages/adapter-cloudflare-dynamic-worker/.
• HB3 container adapter (out of scope for this paper) — When runtime-capability = container-required, the same Agent Card + skill bundle deploys via HB3 instead. HB3 is defined outside this paper; the point here is that the composition contract is identical — only the runtime host swaps.
• NANDA publication — Winning variants get an entry on the Nexartis NANDA node with capability tags, reputation from the receipt store, endpoint URL, and pricing (NP or Base USDC where applicable, in a later wave). Any Nexartis web app queries NANDA, picks a candidate, and invokes it.

KYM optimization loop

1. Author variants: same Agent Card + skill set, permute across (model, harness, skill-versions, memory-stack) — same substrate as the harness-bandit study, wider projection.
2. Run under the parallel-waves harness (nexartis-parallel-waves-agent-harness) — each variant is an arm.
3. Score via the shared rubric + Ed25519 receipts (see /research/harness-bandit-experiments); bandit picks the winner per task class.
4. Publish the winner to the Nexartis NANDA node with its reputation carried forward as a signed attestation. Reputation is the receipt trail, not a self-claim.
5. Web apps consume: query NANDA for capability X → get ranked candidates → invoke the winner as a dynamic worker on demand.

Runtime-capability categorization

Explicit rubric on the Agent Card. The dispatcher reads the class and picks the deployment shape without guessing. No silent fallback across classes — a class change is a receipt-visible event.

• workers-only — Skill set is entirely within WinterTC min-common-api + Cloudflare Workers APIs. No node:fs, no long-lived process, no container-only dependency.
  Deployment: Cloudflare dynamic worker. First-choice deployment shape.
• workers-preferred — Primary path runs on Workers; some capabilities may need a fallback for edge cases. NB: "fallback" here means an explicitly-declared alternate deployment path, not a silent runtime fallback — the workspace no-defense-in-depth principle still applies. If the workers path fails, a classified error propagates.
  Deployment: Cloudflare dynamic worker with a documented alternate deployment path for the declared edge cases.
• container-required — Skill set requires a long-lived process, a non-Workers runtime (Python, Rust binary), or a container-only dependency. Declared explicitly on the Agent Card.
  Deployment: HB3 container (out of scope for this paper). Same Agent Card + skill bundle, different runtime host.
• local-host-required — Skill set needs on-machine capabilities (desktop control, local filesystem, OS keychain) that no cloud runtime provides.
  Deployment: Ozzy Dev local-mac / local-windows / local-linux host, via the corresponding cubicle adapter. Never remotely dispatchable.

Open questions

• What is the exact NANDA publication contract? — Agent Card + reputation attestation + endpoint + capability tags — but the field-level schema, signing envelope, and discovery-query semantics remain to be specified.
• How does a web app choose between candidates? — Ranked by receipt-scored reputation is the baseline. The app also needs latency budget, pricing preference, and possibly per-app trust lists. UX question: is the choice explicit, or does NANDA pick and the app just consumes?
• Dynamic-worker cold-start vs long-running warm pool? — V8 isolates spin up in tens of milliseconds; for high-QPS capabilities the tradeoff between fresh isolates and warm pools is a receipt-benchable question, not an architecture decision.
• Container fallback (HB3) — SLA and cost model — When a capability escalates from workers-preferred to container-required at runtime (e.g. workload grew a native dep), what is the practitioner experience? Manual re-classification is the safe default; automated re-classification is a separate research question.
• How do skill versions on an already-published NANDA agent get upgraded? — A skill version bump is a KYM event; whether it triggers a new NANDA publication or an in-place attestation update is a policy question that touches consumer contracts.
• Payment integration (NANDA Points / Base USDC) — Later-wave territory. Composition must not require payment to work; payment must be additive on the publication side.

Positioning

1. Cubicle SDK contract per docs/sdk-architecture.md remains the canonical runtime interface: this paper adds the composition + publication layer on top, it does not re-specify the runtime host / harness split.
2. @nexartis/cubicle-adapter-cloudflare-dynamic-worker is the workers-only / workers-preferred deployment path; HB3 is the container-required path; local-mac / local-windows / local-linux adapters are the local-host-required path.
3. nexartis-agent-scripts (see /research/scripts-as-tools) is the skill-package library; skill+version is a first-class variant dimension in KYM tuning.
4. nexartis-parallel-waves-agent-harness is the runner for the variant bakeoff; harness-bandit-experiments is the methodology.
5. NANDA publication + web-app consumption is the delivery surface. On-demand agents are a summoning primitive, not a monolith.
6. Sequencing: current outline. The next revision incorporates composition-pattern field results — publication schema, deployment picker, cold-start-vs-warm-pool experiment plan.

How this page stays current

Living outline. The current revision covers premise, surface, and open questions. Later revisions incorporate composition-pattern field results: publication schema, deployment picker, first cold-start-vs-warm-pool numbers. Later still: NANDA-consumer UX findings and first receipt-scored reputation data. Numbers replace claims as they arrive; the version at the top bumps on every material change.