Lifecycle Policy

Agents and tools decay. Endpoints break. Models retire. Authors move on. This policy describes how the registry surfaces decay rather than hiding it.

Agent lifecycle states

State	Meaning
pending	Submitted, awaiting endorsement (for first-time authors)
endorsed	Endorsed but not yet through the gate
active	Live, all dependencies healthy
degraded	At least one required tool is unreachable; banner shown
stale	Tested-on model is 4+ generations behind, OR has been degraded for 30+ days
withdrawn	Author or moderator pulled it (citable, with public notice)
superseded	Replaced by a newer version (citable, with link to successor)
flagged	Under review by moderators

Tool lifecycle states

State	Meaning
pending	Registered, awaiting review (always for local-action; automated for remote-query)
active	Live, recent health checks succeeding
degraded	Intermittent failures
unreachable	8+ consecutive failed health checks (≈48 hours of being down)
decommissioned	Operator retired the tool; listing remains for citation continuity
flagged	Under review by moderators

Health checks

Every registered tool endpoint is pinged on a 6-hour interval. The ping:

• Sends a minimal request to the declared endpoint.
• Records latency and HTTP status to tool_health_history.
• Increments consecutive_failures on any non-success; resets to 0 on success.

Thresholds:

Condition	Effect
1–2 consecutive failures	No state change; recorded in history
3–7 consecutive failures	Status flips to degraded; operator notified by email
8+ consecutive failures (~48h)	Status flips to unreachable; dependent agents auto-flip to degraded
90 days unreachable + no operator response	Moderator review for forced decommission

Agent degradation (broken-tool grace period)

When a required tool flips to unreachable, the registry:

1. Auto-flips dependent agents to degraded status.
2. Posts a banner on each affected agent's detail page: "Required tool [name] has been unreachable since [date]."
3. Notifies the agent's author by email (Phase 3).
4. Gives the author 30 days to either fix the tool, swap to a working alternative, or withdraw/supersede the agent.

After 30 days:

• The agent moves from degraded to stale.
• It remains citable; default views exclude it.

After 90 days:

• A moderator reviews. Typical outcomes: forced withdrawal, or (if the broken tool is the only issue and the agent is otherwise valuable as a historical artifact) leave as stale indefinitely.

Model staleness

The registry maintains a current_models reference table — a curated list of model identifiers and their generation numbers, updated by moderators when new model releases occur.

An agent's model_tested_on value is checked daily against this table:

Distance from current	Effect
Within 1 generation	No flag
2 generations behind	Warning banner: "Tested on an older model — behavior may have drifted."
4+ generations behind	Status flips to stale.

The author can re-validate at any time: submit a new validation block tested against a current model, and the status flips back to active (assuming no other issues).

What the public sees

Decay is communicated, not hidden:

• A degraded agent's detail page shows the banner and which tool is broken.
• A stale agent's detail page shows why (broken tool grace expired, model too old, or both).
• A withdrawn agent shows the withdrawal notice and reason.
• A superseded agent shows a link to its successor.

Default search excludes withdrawn, superseded, and stale listings; users can opt into a broader view with an "include withdrawn / stale" filter.

Notifications

Authors receive email notifications (Phase 3) when:

• A tool they depend on flips to degraded or unreachable.
• Their agent is auto-flipped to degraded or stale.
• A moderator action is taken on their listing.
• A flag is filed against their listing.
• They're 7 days from a state transition deadline.

Notifications are opt-out-able per category. The "moderation action taken" category cannot be disabled.

What doesn't happen automatically

• No automated forced withdrawals. Only moderators do that, with cause.
• No silent state changes. Every state change has a recorded reason in the audit log.
• No content edits without a version bump. Lifecycle changes touch state, not the record itself.

Reactivation

A stale agent can be reactivated by the author:

1. Submit a new version with refreshed validation against a current model.
2. If the underlying tool is restored, the gate detects this and the new version is active on approval.
3. The old stale version is automatically superseded by the new version.

A withdrawn agent cannot be reactivated under the same version. The author must submit a new version (or new agent) and explicitly reference the prior withdrawal in the new submission.

Tunable defaults

The thresholds in this policy are configurable, not constitutional. Changes require the standard policy-change process (PR → moderator review → 14-day announcement). Current production values:

Setting	Value
Health-check interval	6 hours
Unreachable threshold	8 consecutive failures
Degraded grace period	30 days
Stale model-generation threshold	4 generations
Forced-withdrawal review trigger	90 days unreachable