← Back to home

The missing production unit

Agent Pack

A versioned, deployable unit of agent — its prompt, its tools, its engine, and its permissions.

What your IDE writes, your CI validates, and your infrastructure runs — small enough to review and roll back, portable across engines and your perimeter.

Read the published spec Download free
warehouse-analyst / agent.yaml 
# yaml-language-server: $schema=https://packs.agenthippo.ai/schema/v1/agent.json
apiVersion: agenthippo.ai/v1
kind: Agent
metadata:
  name: warehouse-analyst
  version: 0.1.0
spec:
  engine: claude
  engineVersion: 2.1.209
  model: claude-fable-5
  permissions:
    fileAccess: read-only

Line 1 names the format. Everything else is reviewable like any other production change.

Write

Author the pack in an IDE — prompt, tools, engine, permissions in one versioned unit.

Validate

Schema-check in CI. Reject drift before it reaches production data.

Run

Deploy into your infrastructure — or point spec.remote at the instance that serves it.

The enemy

Agents that can’t leave the laptop without becoming a liability — no version, no permissions boundary, no audit trail — so pilots die.

  1. 01

    Folder of conventions

    A prompt in a chat tab or a pile of scripts. Works on one machine, unreviewsable in git, no shared contract.

  2. 02

    Identity collapse

    Once two people use it on company data, nobody can answer whose permissions ran, or which version touched production.

  3. 03

    Engine lock-in by accident

    Whatever you prototyped on becomes welded into code — switching engines means a rewrite, so you never measure.

Engine is a field, not a rewrite

Most teams don’t choose an engine. They inherit whichever one they prototyped with — because revisiting the choice has always meant a rewrite.

In an Agent Pack, spec.engine is a manifest field. Same prompt, same tools, same permissions — change one line and re-run your evals. 

  metadata:
    version: 0.1.0
    version: 0.3.0
  spec:
    engine: claude
    model: claude-fable-5
    engine: codex
    model: gpt-5.4

Hours to find out which engine wins on your workload — versus a redesign. See also multi-engine IDE.

Agent Pack vs everything else

Landmarks for how people build agents today.

vs raw AGENTS.md

A prompt file isn’t a permissions boundary, an engine pin, or a versioned identity. An Agent Pack is the prompt plus the contract that makes it shippable — and the prompt itself stays at the fixed path AGENTS.md (no manifest field needed).

vs Claude Code rules alone

Project rules and AGENTS.md loaders already know how to find a prompt. A Pack closes those rules inside one folder and schema — skills, MCP, engine pin, permissions — so Claude Code–style agents can be satisfied by the pack tree without inventing a parallel format.

vs nested mini-subagents

A name plus a paragraph inside a parent config isn’t enough. Each subagent should be another Agent Pack — its own engine, model, tools, and permissions — so workers stay as reviewable as the parent.

vs managed agent containers

Hosted agent clouds usually mean their container and roster. A Pack deploys into your perimeter; optional spec.remote points at that instance.

vs hardcoded provider SDKs

Welding to one provider’s SDK makes every model release a migration. A manifest field lets you re-benchmark and bump a version.

Spec and tools

The published specification is CC BY 4.0. The registry, certification, and runtime are separate products.

Agent Pack Specification v1 JSON Schema Agent Store