This document explains the foundational concepts of the Tail/TailPack specification and clarifies terminology that may otherwise be ambiguous.
A Tail is the smallest complete portable unit of agent definition.
It is not a prompt. It is not a config file. It is a full description of what an agent is, how it behaves, what it can do, and how it participates in systems. A Tail carries everything needed to understand and deploy a single agent: identity, persona, capabilities, input/output expectations, contextual feed dependencies, memory strategy, integration wiring, teaming roles, and distribution metadata.
A Tail is the canonical source of truth. Every other format — SKILL.md exports, AGENTS.md artifacts, MCP configs — is an adapter target derived from it. The Tail is always richer than any single export.
A Tail may run alone, as part of a TailPack, in a runtime directly, or through an adapter into another platform.
A TailPack is a portable container for one or more Tails, bundled with shared assets, skills, integration configs, and compatibility metadata.
If a Tail is a single agent, a TailPack is a team: a strategist, a copy chief, and a judge packaged together with shared brand assets and collaborative defaults. TailPacks are the unit of sharing, distribution, and remixing.
A TailPack does not replace the Tail as the atomic unit. Tails inside a TailPack retain their full definitions and can be extracted and used independently.
This is one of the most important distinctions in the spec.
Inputs are transactional. They describe what a Tail can receive in a single interaction: a file upload, a JSON payload, a user message. Inputs arrive, get processed, and are done.
Feeds are ongoing contextual streams. They describe what kinds of ambient, continuous context a Tail expects to have access to: a document corpus, an event stream, a repository watcher, a memory store. Feeds are declared dependencies — the Tail says "I work best with access to these ongoing data sources" and the runtime decides how to wire them up.
Most agent frameworks today blur this distinction by stuffing everything into context. The Tail/TailPack spec makes it explicit because agents are increasingly becoming background workers and ambient services, not just chat responders.
TailPack does not force anyone to adopt a new runtime. Instead, it provides a canonical source of truth that can be exported — lossily — into other formats.
An adapter is a translator. It takes a Tail and converts it into a target format: a SKILL.md folder, an MCP server config, an AGENTS.md file. Because the Tail schema is richer than any single target format, adapters will inevitably drop information. The spec makes this explicit through the adapter warning model, where every export includes machine-readable annotations of what was lost.
This is deliberate. Perfect fidelity across all platforms is impossible. Honest, annotated lossiness is better than silent degradation.
Every adapter declares what it supports and what it cannot represent:
{
"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"]
}Warnings are structured and machine-readable:
{
"warnings": [
{
"code": "WARN_MEMORY_UNSUPPORTED",
"field": "memory",
"reason": "Target format has no native persistent memory representation."
}
]
}These are different things. The naming similarity is intentional (both relate to agents) but the distinction matters.
agent.md (lowercase) is a Tail-local, human-readable companion file. It lives alongside tail.json inside a specific Tail's directory and provides a narrative description of that agent — its purpose, style, and intended use. It is internal documentation for the Tail. It is not a standard; it is a convention within the TailPack file layout.
AGENTS.md (uppercase) is an external ecosystem standard, maintained by the Agentic AI Foundation under the Linux Foundation. It provides repo-level or project-level context for coding agents: build commands, code style, testing procedures, boundaries. Over 60,000 GitHub repos have adopted it. AGENTS.md is not part of the TailPack spec itself — it is a compatibility target that TailPack export adapters may emit.
In short:
agent.md= internal companion doc for a TailAGENTS.md= external interoperability artifact for repo-oriented runtimes
When Tails work together in a TailPack, two coordination patterns are defined:
Handoff targets are Tail IDs that a Tail may pass work to during normal operation. "I'm done with my part; now the copy chief should take over."
Escalation targets are Tail IDs for conflict resolution or decision authority. "We disagree on positioning; escalate to the judge for arbitration."
Both resolve only within the same TailPack. Cross-pack coordination is out of scope for v0.1b.
The spec also includes escalation rules as freeform text strings. These serve a different consumer: while escalation_targets tells the runtime where to route, escalation_rules tells the model when and why to escalate. Both layers are useful.
These three top-level blocks are present in the v0.1b schema but intentionally underdefined. They exist to reserve space for concepts that are becoming real in the ecosystem but have not yet converged on stable representations.
economics — Agent micropayments and transactions are production-real (Coinbase AgentKit, Stripe Agentic Commerce, Google AP2). The block reserves space for spending authority, payment capability, and pricing hints without committing to any specific payment rail or token standard.
trust — Verifiable credentials for agents, Know Your Agent frameworks, and on-chain trust infrastructure are actively developing. The block reserves space for credential references, attestations, and verification hints without defining a canonical trust schema.
lifecycle — Agent versioning, migration, and deprecation are documented pain points across every major framework. The block reserves space for state tracking, upgrade lineage, and identity continuity without defining a full state machine.
The architectural rule: spec the durable abstractions, not the transient mechanisms.
A Tail's integrations.tools section declares what tools the agent is allowed to use. These are capability claims — "I can use web search."
A TailPack's shared/integrations/ directory provides the actual implementation configs that a runtime should wire up — the API keys, transport configurations, and endpoint details.
This separation means a Tail can declare its needs portably, while the concrete wiring stays at the packaging level where it belongs. Different deployments of the same Tail can wire up different implementations of the same tool.