Skip to content

Latest commit

 

History

History
807 lines (660 loc) · 19.9 KB

File metadata and controls

807 lines (660 loc) · 19.9 KB

Tail / TailPack Spec v0.1b

Definitions

A Tail is the smallest complete portable unit of agent definition. It describes a single agent's identity, behavior, capabilities, interfaces, and runtime expectations. A Tail is the canonical source of truth for what an agent is, how it behaves, what it can do, and how it participates in systems — alone or in teams. External formats (SKILL.md, AGENTS.md, MCP configs) are adapter targets, not the source of truth.

A TailPack is a portable container for one or more Tails, plus optional shared assets, integration configs, compatibility metadata, and distribution information. A TailPack is the unit of packaging, sharing, remixing, and deployment handoff.

A TailPacker is the public surface for sharing, previewing, using, and remixing TailPacks.


1. Core Principles

1.1 Canonical truth

A Tail is the canonical source object. External formats are adapter targets, not the source of truth.

1.2 TailPack is a container

A TailPack packages one or more Tails for portability, sharing, remixing, and deployment handoff. A TailPack does not replace the Tail as the atomic unit.

1.3 Adapters are first-class

The base spec supports one-to-many adapters: TeamAgentix runtime, open zip export, SKILL.md, AGENTS.md, MCP, webhook/event, and future runtime/platform adapters.

1.4 Richer than current runtimes

The canonical Tail model should be richer than the lowest common denominator of current platforms. Adapters may degrade gracefully, flatten structure, drop unsupported fields, and annotate lossiness.

1.5 Open internals

Portable exports should use readable formats where possible: JSON or YAML for manifests, Markdown for prompts/skills/docs, standard media/assets, and optional adapter-specific files.

1.6 Relationship to other standards

TailPack is designed to complement, not replace, other emerging agent standards.

  • SKILL.md / Agent Skills — TailPack may export skills in SKILL.md format via adapters. SKILL.md is treated as a modular capability format, not a full Tail definition.
  • AGENTS.md — TailPack may emit or reference AGENTS.md artifacts via adapters for repo- or environment-oriented runtimes. AGENTS.md is treated as project or environment context, not a complete agent definition format.
  • MCP (Model Context Protocol) — TailPack uses MCP as an integration and tool-wiring target via adapters. TailPack does not attempt to replace MCP.
  • A2A / ACP — TailPack does not define inter-agent communication protocols. Teaming metadata may inform runtimes that use A2A/ACP or similar systems.
  • ADL / other agent definition formats — TailPack may interoperate with other declarative agent formats through adapters. TailPack's canonical model prioritizes full agent definition, packaging, portability, and lossy export/import awareness.

2. Object Model

2.1 Tail

A Tail is the smallest complete unit. It includes identity, persona and instructions, capabilities, skills, tool and integration definitions, model and voice preferences, inputs and outputs, environment assumptions, and optional team metadata.

A Tail may run alone, as part of a TailPack, in a runtime directly, or through an adapter into another platform.

2.2 TailPack

A TailPack is a container for one or more Tails. It may include shared assets, shared skills, shared integration configs, compatibility notes and adapters, packaging metadata, and remix/provenance info.

2.3 Remix

A TailPack may be remixed: modifying included Tails, changing assets or config, repackaging and redistributing as a new TailPack, and preserving provenance where applicable.


3. Canonical Tail Schema

3.1 Top-level shape

{
  "tail_version": "0.1b",
  "identity": {},
  "persona": {},
  "capabilities": {},
  "inputs": {},
  "outputs": {},
  "feeds": {},
  "memory": {},
  "interfaces": {},
  "integrations": {},
  "environment": {},
  "teaming": {},
  "economics": {},
  "trust": {},
  "lifecycle": {},
  "distribution": {},
  "extensions": {}
}

3.2 identity

Defines what the Tail is.

{
  "id": "strategist",
  "name": "Strategist",
  "role": "Brand Strategist",
  "description": "Helps define positioning, messaging, and strategic direction.",
  "tags": ["strategy", "positioning", "brand"],
  "icon": "assets/strategist.png",
  "author": {
    "name": "Your Name",
    "url": ""
  },
  "version": "0.1.0"
}

Notes:

  • id must be unique within the TailPack.
  • Global uniqueness is out of scope for v0.1b.
  • TailPack-level authorship is canonical for provenance; Tail-level authorship may be overridden later if remix workflows need it.

3.3 persona

Defines how the Tail should think and behave.

{
  "system_prompt": "You are a sharp, skeptical strategist...",
  "persona_prompt": "Act as a senior brand strategist...",
  "tone": ["clear", "strategic", "direct"],
  "goals": [
    "Clarify the strategic problem",
    "Surface tradeoffs",
    "Recommend coherent paths"
  ],
  "constraints": [
    "Do not invent facts",
    "Avoid vague marketing language"
  ],
  "style": {
    "verbosity": "medium",
    "reasoning_style": "structured",
    "response_style": "decisive"
  }
}

Rules:

  • system_prompt is the base instruction layer.
  • persona_prompt is an optional layered instruction/persona block applied on top.
  • If a runtime cannot preserve layered prompting, adapters may concatenate them.
  • In conflicts, system_prompt takes precedence.

3.4 capabilities

Defines what the Tail can do.

{
  "skills": ["skills/positioning", "skills/critique"],
  "modalities": {
    "text": true,
    "voice": true,
    "image": false,
    "code": false
  },
  "permissions": {
    "tool_use": true,
    "web_access": true,
    "file_access": true,
    "memory_read": true,
    "memory_write": true
  }
}

Rules:

  • Skill references are relative paths within the Tail's folder structure.
  • Shared TailPack-level skills may be referenced separately, such as from shared/skills/.
  • External URIs are out of scope for v0.1b.
  • Validation Rule: If permissions.tool_use is false but integrations.tools contains entries marked required: true, the Tail is invalid and must be rejected at authoring/validation time.

3.5 inputs

Defines what the Tail can receive directly in a single interaction.

{
  "accepted_types": [
    "text/plain",
    "text/markdown",
    "application/pdf",
    "application/json",
    "text/uri-list"
  ],
  "supports": {
    "conversation": true,
    "files": true,
    "urls": true,
    "structured_json": true,
    "images": false,
    "audio": true
  },
  "input_schema": null
}

Inputs are transactional.


3.6 outputs

Defines what the Tail can produce.

{
  "formats": [
    "text/markdown",
    "application/json"
  ],
  "supports": {
    "summaries": true,
    "reports": true,
    "recommendations": true,
    "tool_calls": true,
    "audio": true
  },
  "output_schema": null
}

3.7 feeds

Defines expected ongoing contextual streams.

{
  "supported": [
    "memory",
    "documents",
    "events",
    "repo",
    "webhooks"
  ],
  "subscriptions": {
    "memory": true,
    "documents": true,
    "events": false,
    "repo": false,
    "webhooks": false
  },
  "fallbacks": {
    "documents": "ephemeral_context_only"
  }
}

Rules:

  • Feeds are not flags and not abilities. Feeds are declared dependencies on contextual streams.
  • They tell the runtime what kinds of ongoing context the Tail expects to have access to. The runtime decides how to satisfy them.
  • subscriptions indicates which feed types the Tail actively wants wired up.
  • fallbacks is optional and may describe degradation behavior if a feed is unavailable.

Examples of feed types: memory feed, document corpus, repo stream, event stream, webhook/event feed.


3.8 memory

Defines memory expectations and strategy.

{
  "mode": "optional",
  "supports": {
    "ephemeral": true,
    "persistent": true,
    "retrieval": true,
    "summary_memory": true
  },
  "scope": "tail",
  "strategy": "store useful user preferences and recurring project context"
}

Rules:

  • scope: "tail" is the default for v0.1b.
  • pack, session, and global are reserved future values.
  • Shared memory across Tails is out of scope for now.

3.9 interfaces

Defines how a Tail can be interacted with.

{
  "chat": true,
  "voice": true,
  "api": true,
  "mcp": {
    "enabled": true,
    "required": false
  },
  "webhook_callbacks": {
    "enabled": true
  }
}

Interfaces describe modes of interaction, not external integrations themselves.


3.10 integrations

Defines external systems and tool/interoperability configs.

{
  "tools": [
    {
      "id": "web-search",
      "type": "tool",
      "required": false
    }
  ],
  "mcp": {
    "servers": [
      {
        "id": "docs-server",
        "transport": "stdio",
        "required": false
      }
    ],
    "tools": [],
    "resources": [],
    "prompts": []
  },
  "webhooks": {
    "inbound": [],
    "outbound": []
  }
}

Suggested webhook object:

{
  "id": "task-complete",
  "direction": "outbound",
  "event": "tail.task.completed",
  "method": "POST",
  "url": "https://example.com/webhook",
  "auth": {
    "type": "bearer",
    "token_ref": "env:WEBHOOK_TOKEN"
  }
}

Rules:

  • Tail-level tool declarations (integrations.tools) are capability claims ("I am allowed to use this tool").
  • Shared integration configs at the TailPack level provide the actual implementation details a runtime should wire up.
  • The spec defines reference patterns for secrets, not embedded credentials. token_ref, secret_ref, or credential_ref are acceptable reference forms.
  • Secret resolution is a runtime concern.

3.11 environment

Defines assumptions about the runtime environment.

{
  "requires": {
    "internet": true,
    "file_access": true,
    "voice_output": true,
    "mcp_support": false
  },
  "preferred_models": [
    {
      "provider": "openrouter",
      "model": "qwen/qwen-2.5-72b-instruct"
    }
  ],
  "preferred_voice": {
    "provider": "internal",
    "voice": "alloy"
  },
  "runtime_hints": {
    "local_model_supported": true,
    "browser_extension_supported": true
  }
}

These are preferences and hints unless explicitly marked required.


3.12 teaming

Defines how the Tail works in multi-agent contexts.

{
  "can_work_alone": true,
  "can_join_team": true,
  "default_role": "strategist",
  "communication_style": "structured",
  "handoff_targets": ["copy-chief", "judge"],
  "escalation_targets": ["judge"],
  "escalation_rules": [
    "Escalate final arbitration to judge roles when conflicts remain unresolved."
  ]
}

Rules:

  • handoff_targets and escalation_targets resolve only to Tail IDs inside the same TailPack.
  • Cross-pack handoffs are out of scope for v0.1b.
  • escalation_targets provide structured routing for runtimes, while escalation_rules provide natural-language context for the model.

3.13 economics

Defines optional economic and transaction-related metadata for a Tail.

{
  "enabled": false,
  "payment_capable": false,
  "spending_limits": {},
  "pricing": {},
  "settlement_hints": {}
}

Rules:

  • economics is reserved for future schema expansion in v0.1b.
  • v0.1b does not define a canonical transaction or blockchain/DAG model.
  • This block exists to reserve space for portable economic metadata such as spending authority, payment capability, pricing hints, settlement preferences, and royalty or remix economics.
  • Chain-specific, token-specific, and vendor-specific fields should not be standardized in v0.1b.
  • Implementations may use extensions for experimental economics-specific data.

3.14 trust

Defines optional trust, provenance, and attestation metadata for a Tail.

{
  "enabled": false,
  "credentials": [],
  "attestations": [],
  "verification_hints": {},
  "provenance_refs": []
}

Rules:

  • trust is reserved for future schema expansion in v0.1b.
  • v0.1b does not define a canonical trust or credential schema.
  • This block exists to reserve space for portable trust metadata such as verifiable credentials, attestation references, trust assertions, verification hints, and provenance bindings.
  • Runtime verification and trust resolution are out of scope for v0.1b.
  • Implementations may use extensions for experimental trust models.

3.15 lifecycle

Defines optional lifecycle metadata for a Tail.

{
  "state": "active",
  "previous_version": null,
  "supersedes": null,
  "migration_hints": {},
  "deprecated": false
}

Rules:

  • lifecycle is reserved for future schema expansion in v0.1b.
  • This block exists to reserve space for portable lifecycle metadata such as current state, migration continuity, deprecation, replacement lineage, and identity continuity during upgrades.
  • v0.1b does not define a full lifecycle state machine.
  • Additional lifecycle semantics may be added in later versions.

3.16 distribution

Defines portability, packaging, and provenance metadata.

{
  "license": "custom",
  "remixable": true,
  "attribution_required": true,
  "compatibility_targets": [
    "teamagentix",
    "open-tailpack",
    "mcp-compatible"
  ],
  "governance_hints": {
    "compliance_profile": null,
    "human_review_required": false
  },
  "provenance": {
    "derived_from": null
  }
}

Rules:

  • governance_hints is intentionally minimal in v0.1b.
  • It may express lightweight compliance or review expectations.
  • It does not define a policy engine or governance framework.
  • Formal governance semantics are out of scope for v0.1b.

3.17 extensions

Freeform namespace for future additions.

{
  "x-teamagentix": {},
  "x-openclaw": {},
  "x-custom-runtime": {}
}

Unknown extensions blocks should be ignored unless the runtime explicitly supports them.


4. Skill Structure

A Tail may contain or reference skills.

4.1 Canonical skill object

{
  "id": "positioning",
  "name": "Positioning",
  "description": "Framework for clarifying product positioning and category language.",
  "entrypoint": "SKILL.md",
  "assets": [],
  "scripts": []
}

4.2 Recommended export shape

skills/
  positioning/
    SKILL.md
    assets/
    references/
    scripts/

5. TailPack Container

5.1 Top-level shape

{
  "tailpack_version": "0.1b",
  "identity": {},
  "tails": [],
  "shared": {},
  "compatibility": {},
  "distribution": {},
  "extensions": {}
}

5.2 identity

{
  "id": "brand-strategy-pack",
  "name": "Brand Strategy TailPack",
  "description": "A portable set of strategic agents for positioning, critique, and recommendation.",
  "author": {
    "name": "Your Name"
  },
  "version": "0.1.0",
  "tags": ["strategy", "brand", "team"]
}

5.3 tails

Array of Tail references or embedded Tail objects.

[
  { "ref": "tails/strategist/tail.json" },
  { "ref": "tails/judge/tail.json" }
]

5.4 shared

Shared resources for the pack.

{
  "assets": ["assets/brand-framework.pdf"],
  "skills": [],
  "integrations": [],
  "defaults": {
    "team_mode": "collaborative"
  }
}

5.5 compatibility

Adapter-facing metadata and helpers.

{
  "includes": [
    "open-export",
    "skill-bundle",
    "mcp-mapping"
  ],
  "notes": [
    "Best used in multi-agent environments with voice support."
  ]
}

5.6 distribution

Sharing and remix metadata.

{
  "public": true,
  "star_enabled": true,
  "comment_enabled": true,
  "remix_enabled": true,
  "license": "custom",
  "attribution_required": true,
  "provenance": {
    "derived_from": null
  }
}

6. Recommended File Layout

brand-strategy-tailpack/
  tailpack.json
  README.md
  tails/
    strategist/
      tail.json
      agent.md
      prompt.md
      assets/
      skills/
        positioning/
          SKILL.md
          assets/
          scripts/
    judge/
      tail.json
      agent.md
      prompt.md
      assets/
  shared/
    assets/
    skills/
    integrations/
  compat/
    README.md
    setup-notes.md

Notes:

  • tail.json is canonical.
  • agent.md and prompt.md are human-readable support files local to each Tail.
  • Export adapters may add AGENTS.md, SKILL.md, MCP configs, and other compatibility artifacts.

7. Adapter Model

7.1 Adapter contract

Every adapter should declare: adapter_id, version, source_version_supported, target_format, lossiness, and capabilities_supported.

{
  "adapter_id": "skillmd-export",
  "version": "0.1.0",
  "source_version_supported": ["tail@0.1b"],
  "target_format": "SKILL.md",
  "lossiness": "partial",
  "capabilities_supported": [
    "skills",
    "assets",
    "instructions"
  ]
}

7.2 Adapter responsibilities

An adapter may export canonical fields into a target format, import a target format into canonical fields, emit warnings for unsupported fields, and annotate degraded mappings.

7.3 Adapter warning model

{
  "warnings": [
    {
      "code": "WARN_MEMORY_UNSUPPORTED",
      "field": "memory",
      "reason": "Target format has no native persistent memory representation."
    }
  ]
}

Rules:

  • All warnings should include a code, field, and reason.
  • code is a machine-readable identifier for automated validation and CI checks.
  • A formal warning code enum is not defined in v0.1b but may be standardized in future versions.

8. Required vs Optional Fields

8.1 Required for Tail v0.1b

Minimum viable Tail: tail_version, identity.id, identity.name, persona.system_prompt or persona.persona_prompt, capabilities, and distribution.

8.2 Required for TailPack v0.1b

Minimum viable TailPack: tailpack_version, identity.id, identity.name, at least one Tail, and distribution.

Everything else can grow later.

8.3 Minimal Tail example

{
  "tail_version": "0.1b",
  "identity": {
    "id": "assistant",
    "name": "Assistant"
  },
  "persona": {
    "system_prompt": "You are a helpful assistant."
  },
  "capabilities": {
    "skills": [],
    "modalities": { "text": true },
    "permissions": { "tool_use": false }
  },
  "distribution": {
    "license": "custom",
    "remixable": true,
    "attribution_required": true,
    "compatibility_targets": ["open-tailpack"],
    "provenance": { "derived_from": null }
  }
}

9. Versioning Rules

9.1 Spec versions

Use explicit versions: tail_version and tailpack_version.

9.2 Semantic intent

Recommended: patch = non-breaking clarifications, minor = additive fields, major = breaking schema changes.

9.3 Extension safety

Unknown extension blocks should be ignored unless explicitly supported.


10. v0.1b Design Philosophy

This version intentionally does not over-specify exact plugin file formats, exact MCP serialization details, runtime-specific memory implementation, strict event schemas, or hard output contracts.

Instead, it creates room for adapters, future runtime evolution, lossy compatibility, public/open exports, and secure TeamAgentix-native packaging later.

This version also reserves space for future expansion in three areas that are increasingly relevant across agent ecosystems: economics, trust, and lifecycle. These blocks are intentionally underdefined in v0.1b. They exist to prevent schema churn and to preserve room for portable metadata in areas where the ecosystem is moving quickly but has not yet converged on stable cross-platform representations.


11. Recommended Next Build Steps

  1. Lock the canonical tail.json shape.
  2. Lock the tailpack.json container shape.
  3. Build two adapters first: open TailPack export, and TeamAgentix runtime import/export.
  4. Then add: SKILL.md export/import, MCP mapping, webhook schema handling, and optional AGENTS.md emission.
  5. Define placeholder handling for economics, trust, and lifecycle in validators and serializers.
  6. Later: strict contracts, lineage graph, remix history, and secure commercial packaging mode.