agent-operations-contract

Agent Operations Contract

Use this skill to make configured agents and their operations inspectable without installing an agent runtime. It complements skill cards: a skill describes a reusable method; an agent card describes one actual worker, its current capabilities, and its authority.

This contract is opt-in and fail-closed. Documentation, configuration, marketplace presence, or a successful probe never grants authority.

1. Agent Capability Card

Create one card per concrete agent from templates/agent-capability-card.yaml.

Require:

• stable agent_id, purpose, bounded responsibilities, owner;
• authority: read, proposal, write, or external_action;
• configured models, tools, and knowledge bases;
• allowed schedules, including whether unattended runs are permitted;
• explicit approval boundary;
• dated capability confirmations with evidence.

Rules:

• List secret names, never values.
• external_action names exact action families; it is not blanket permission.
• An allowed schedule controls timing, not authority.
• Missing owner, approval boundary, or current confirmation blocks use.
• Capability changes update the card before a run depends on them.

2. Async Operation Receipt

Use templates/operation-receipt.json for scheduled, queued, or long-running work.

Allowed states:

QUEUED -> RUNNING -> NEEDS_APPROVAL -> SUCCEEDED | FAILED | CANCELLED

RUNNING may settle directly when approval is unnecessary. Each retry creates a new operation_id or records a stable parent/idempotency relationship; never overwrite a failed receipt as success.

NEEDS_APPROVAL must retain an action fingerprint and the exact proposed action. Approval is one-shot, expires, and cannot widen the agent card. A receipt contains compact operational facts and evidence references, not hidden reasoning, credentials, private content, full prompts, transcripts, or unrestricted logs.

3. Scoped Memory

Use templates/memory-record.yaml. Every memory record has exactly one scope: