AIP-8: agentagencies/v1 — autonomous agency engine
A filesystem-first operations format that extends agentcompanies (AIP-6) and agentgovernance (AIP-7) with the doctypes needed to run an autonomous agency — services, procedures, engagements, agreements, deliverables, invoices.
| Field | Value |
|---|---|
| AIP | 8 |
| Title | agentagencies/v1 — autonomous agency engine |
| Status | Draft |
| Type | Core |
| Domain | agencies.sh |
| Requires | AIP-6, AIP-7 |
| Reference Impl | packages/agencies |
Abstract
agentagencies/v1 is the operating-layer specification on top of
AIP-6 (companies) and AIP-7 (governance).
It defines the doctypes an autonomous agency needs to run real commercial
operations: a service catalog, vendor-neutral procedures, engagements
with counterparties, signed agreements, deliverables, invoices, recurring
routines, and operator capacity. AIP-8 is filesystem-first: the agency
is the folder of files, with adapters projecting it into runtimes and
databases.
Motivation
An "AI agency" today means a vendor-specific bundle of prompts, tools, and scaffolds. There is no portable artifact you can hand from one runtime to another, no auditable record of what the agency agreed to or delivered. AIP-8 closes that gap: an agency is a collection of files, signed via AIP-7, structured around AIP-6 primitives, that any conforming runtime can ingest and execute.
This is the keystone of the agency-protocol stack: AIP-6 describes who, AIP-7 describes how decisions are recorded, AIP-8 describes what gets done and how it's billed.
Specification
Full normative text lives in
packages/agencies/core/AGENTAGENCIES.mdwith per-doctype Zod schemas atsrc/spec/doctypes/. AIP-8 will absorb that text in full as part of moving Draft → Review.
Operations doctypes added on top of AIP-6/AIP-7:
| File | Purpose |
|---|---|
AGENCY.md | Operational profile (alongside COMPANY.md from AIP-6) |
OPERATIONS.md | Root file for external operations packages |
SERVICE.md | Catalog item |
PROCEDURE.md | Vendor-neutral playbook |
PRICING-MODEL.md | Pricing rule |
COUNTERPARTY.md | External client |
ENGAGEMENT.md | Commercial instance |
AGREEMENT.md | Contract |
DELIVERABLE.md | Work product |
INVOICE.md | Bill |
ROUTINE.md | Schedule |
CAPACITY.md | Operator availability |
All doctypes follow the conventions inherited from AIP-6 (markdown +
frontmatter, slug references, schema: field, vendor extensions).
Approvals on every contractual artifact (AGREEMENT.md, DELIVERABLE.md,
INVOICE.md) flow through AIP-7's signature doctype.
Rationale
To be authored. Defend: extending AIP-6/7 instead of monolithic
re-spec, the specific doctype split (why ENGAGEMENT.md vs
AGREEMENT.md vs DELIVERABLE.md are separate files), filesystem-first
over orchestrator-first.
Reference Implementation
packages/agencies/core —
spec and Zod schemas. The companion adapter
packages/agencies/adapters/mastra
projects an agentagencies/v1 package into a Mastra runtime.
Backwards Compatibility
Not applicable — first version of the spec.
Security Considerations
The contractual surface is the central risk: a runtime that auto-signs
AGREEMENT.md files commits the operator to obligations. Mitigations:
- All contractual doctypes MUST be signed via AIP-7
signatureevents before they are considered binding — implementations that skip signatures are non-conforming. POLICY.mdfiles (AIP-7) gate which agreements an autonomous operator may sign without human approval.- Audit log entries for every contract state transition allow third-party verification after the fact.
AIP-7: agentgovernance/v1 — audit, approval & policy primitives
A filesystem-first format for recording approvals, append-only audit logs, and autonomy policies as workspace files — vendor-neutral, third-party-verifiable.
AIP-9: agentoperators/v1 — operator runtime protocol
A single canonical operator shell — pluggable profile, skills, tools, memory, governance — that any agent runtime can implement and any conforming workflow can dispatch to.