TinyClaw

TinyClaw is an active Spawnfile runtime and the strongest native team target among the supported runtimes. It is a multi-agent, multi-team runtime where settings contain both agents and teams, and each agent gets its own working directory.

Status: Active

Config Shape

TinyClaw stores settings that include both agent definitions and team definitions. Each agent has its own configuration including provider, model, and working directory.

runtime: tinyclaw

TinyClaw does not currently use a complex options structure in the Spawnfile. The adapter maps execution intent directly to TinyClaw’s native per-agent settings.

Workspace Layout

Each agent in TinyClaw gets its own working directory. The adapter places docs into the agent’s directory and handles skill placement:

Spawnfile Role	TinyClaw Location
identity	Agent working directory
soul	Agent working directory
system	Agent working directory
memory	Agent working directory
heartbeat	Agent working directory

Skills are copied into .agents/skills and then mirrored into .claude/skills by the runtime.

Model Mapping

TinyClaw supports per-agent provider and model settings as well as global provider/model switching. The adapter maps:

• execution.model.primary.provider to the agent’s provider setting
• execution.model.primary.name to the agent’s model setting

Channel auth is channel-specific and handled separately from model configuration.

MCP Handling

TinyClaw does not have a clear first-class MCP authoring or config surface. MCP declarations in Spawnfile manifests targeting TinyClaw will be reported as degraded or unsupported depending on the policy settings.

This is an area under ongoing research. See the runtime notes for updates.

Schedule Handling

TinyClaw supports Spawnfile schedule.kind: cron through its native scheduler. The adapter emits a schedules.json file in the TinyClaw home directory, and spawnfile up starts TinyClaw with that file in place. schedule.kind: every is validated but reported as degraded for TinyClaw in v0.1.

Workspace and Sandbox

Each agent has:

• Its own working directory
• Separate config and history
• Explicit workspace layout

The adapter maps workspace.docs, workspace.resources, and execution.sandbox.mode cleanly since each TinyClaw agent already has its own runtime workspace.

Native Team Support

TinyClaw is the strongest native team target in the Spawnfile ecosystem. Its native team shape includes:

• id — team identifier
• name — team display name
• agents — list of member agents
• leader_agent — the designated team leader

Native team interaction:

• @team_id messages go to the leader in the native runtime
• Agents mention teammates to collaborate
• Fan-out exists in the prompt protocol

How Spawnfile Teams Map to TinyClaw

The adapter maps Spawnfile team concepts directly:

Spawnfile Concept	TinyClaw Native
lead	leader_agent when it resolves to one concrete delegate
members[*].id	Agent entries in the team
external	Representative intent (recorded)

One TinyClaw runtime process can host all compiled agents plus the compiled team object.

Nested teams likely need flattening or degradation reporting, as TinyClaw’s team model is flat.

Surfaces

TinyClaw supports Discord, Telegram, and WhatsApp as pairing-gated DM surfaces. Spawnfile lowers each into TinyClaw’s channel client config and starts the corresponding worker process in the generated container. TinyClaw does not support Slack. Portable HTTP is not part of the v0.1 alpha surface contract; TinyClaw’s native API remains runtime-specific.

Discord

Mode	Support
pairing	Supported
allowlist	Not supported
open	Not supported

Telegram

Mode	Support
pairing	Supported
allowlist	Not supported
open	Not supported

WhatsApp

Mode	Support
pairing	Supported
allowlist	Not supported
open	Not supported

Slack

TinyClaw does not support Slack in Spawnfile v0.1. The compiler rejects Slack surface declarations targeting TinyClaw.

The upstream runtime behavior for Discord, Telegram, and WhatsApp is pairing-based and DM-oriented. Spawnfile rejects richer access shapes for TinyClaw at compile time.

What The Adapter Emits

For a single agent:

• TinyClaw agent settings
• Workspace files in the agent’s working directory
• Skill directories

For a team:

• Native team object with agent list and leader
• Per-agent settings and workspace files
• Compiled team configuration

For container compilation:

• Base image metadata
• Settings and workspace pre-placed into final container paths
• Start command
• Runtime-specific port configuration when needed

Container Notes

• TinyClaw is the strongest native team target: one runtime process hosts compiled agents plus the team object.
• Host-side verification may use TinyClaw’s native API, but that API is not a portable Spawnfile surface.
• Compiled output pre-places runtime settings and workspace into final container paths. The entrypoint only needs minimal validation and startup.

Example

From the multi-runtime-team fixture, the writer agent targets TinyClaw:

spawnfile_version: "0.1"
kind: agent
name: writer

runtime: tinyclaw

execution:
  model:
    primary:
      provider: anthropic
      name: claude-sonnet-4-5
  sandbox:
    mode: workspace

workspace:
  docs:
    soul: SOUL.md

And the team manifest that includes this agent:

spawnfile_version: "0.1"
kind: team
name: research-cell

members:
  - id: orchestrator
    ref: ./agents/orchestrator    # openclaw
  - id: researcher
    ref: ./agents/researcher      # picoclaw
  - id: writer
    ref: ./agents/writer          # tinyclaw

mode: hierarchical
lead: orchestrator

In this multi-runtime team, TinyClaw compiles the writer agent while OpenClaw and PicoClaw handle the other members. The team-level structure is preserved in the compile report.