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.

FieldValue
AIP8
Titleagentagencies/v1 — autonomous agency engine
StatusDraft
TypeCore
Domainagencies.sh
RequiresAIP-6, AIP-7
Reference Implpackages/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.md with per-doctype Zod schemas at src/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:

FilePurpose
AGENCY.mdOperational profile (alongside COMPANY.md from AIP-6)
OPERATIONS.mdRoot file for external operations packages
SERVICE.mdCatalog item
PROCEDURE.mdVendor-neutral playbook
PRICING-MODEL.mdPricing rule
COUNTERPARTY.mdExternal client
ENGAGEMENT.mdCommercial instance
AGREEMENT.mdContract
DELIVERABLE.mdWork product
INVOICE.mdBill
ROUTINE.mdSchedule
CAPACITY.mdOperator 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 signature events before they are considered binding — implementations that skip signatures are non-conforming.
  • POLICY.md files (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.