The package maker

The package maker turns a description of a needed agent into a package another system can deploy. It takes what an agent should do, the systems it needs, what it has to refuse, and the records it has to leave, and it hands back the package and its digest. The package holds the declaration, which is the two files agent-descriptor.json and agent-runtime-requirements.json, the parts the declaration names, such as its skills, and a manifest. The digest is the SHA-256 over the package's archive, which every record that mentions the package names. It is the other end of the deployment manager: one makes the package, the other stands it up.

Making a package is mostly authoring. The declaration and the parts are written, and building, in the sense the Common Agent Specification gives the word, only generates the views and writes the manifest's digests. A build adds no fact the authored files did not state.

It is defined by what it will not make up. A package is only as honest as the judgment in it, and two parts of it are judgment: what the agent refuses, and what it has to record. The rest is description. The builder asks for both and refuses to emit a package without them. It also never presents a package as finished: every package it produces is a draft, because nobody has run the agent it describes.

What it emits is an Agent Package as the Common Agent Specification defines it: an Agent Plugin carrying the agent's draft Descriptor and its runtime requirements beside the manifest. That chapter owns the package's shape; this role owns the judgment a builder asks for and the record it signs.

It holds these stages on the lifecycle map: Package and Release (agenticdevelopment.ai).

1. The role

Describing an agent and building one are different kinds of work. A person knows what they need done; turning that into a package a runtime can load means writing a manifest at the right schema, one skill per job in a form a harness reads, and the obligations that keep the agent honest once it runs. That last part is where a description quietly turns into a set of binding rules, and it is easy to skip.

The package maker is that work as a job. An owner hands it a description and gets back a package in a known shape. The person who has the judgment fills in the honest parts, and the builder does not guess them. What it produces is portable by construction, because a plugin is a plugin wherever it runs; which harnesses can then load it is the deployment manager's concern.

2. The requests

The role's exchanges are published as its primary interface, the builder (interface-builder): build this, what did you build, and revise it. The interface page carries each exchange in full. Implementing the interface alone does not grant the role.

3. What it does

1. The judgment parts are required. A package carries what the agent refuses and the records it has to leave, and the builder refuses to emit one that lacks either. It does not derive them from the description, because an agent with nothing written down that it will not do, and no records it has to keep, is the failure that a run only reveals once it is too late.
2. Every package is a draft. The builder has not run the agent it describes and presents the package as no more than a starting point. The manifest carries the draft mark, and the record says nobody has run it.
3. Systems are named by role. Each system the agent needs is a role, an access level, and what the access is for. The builder names no vendor and wires no package to a particular supplier; binding roles to real systems belongs to whoever deploys it.
4. It asks for least access. Each system's access is the most the job needs and no more. The builder does not request write where the description only reads, or a trigger the jobs never fire.
5. Skills are jobs. There is one skill per thing somebody would ask the agent for, and each says when to reach for it, what a good result looks like, and what to do when it comes back empty. A skill per tool is a manual page wearing the word skill.
6. The manifest validates against the plugin schema. A package validates against the Agent Plugin schema it declares, so any runtime that reads that schema can load it. A package that only this builder's own deployer can read is not portable, which defeats the point of building one.
7. Every build leaves a record. Builds, revisions, and refusals each produce the signed record in section 4. What was built, from what description, and the fact that it is a draft, are all in it.

4. The record

A package maker produces a record for every build. Its tag is agent-build-record-v1, and it is signed with the family convention: the ASCII tag, one newline, then the JCS (RFC 8785) canonical JSON of the document with signatures removed.

{
  "record": "v1",
  "role": "agent-builder",
  "act": "build",
  "requested_by": "<who asked>",
  "package": {
    "name": "standup-collector",
    "version": "1.0.0",
    "schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
    "sha256": "<digest of the package the builder emitted>"
  },
  "shape": { "skills": 3, "systems": 2, "refuses": 3, "records": 4 },
  "draft": true,
  "produced_at": "<timestamp>",
  "by": "<package maker public key>",
  "signatures": [ ]
}

The record follows these rules:

1. act is one of build, revise, refuse. A refusal record carries refused with the reason, and names which required part the description was missing.
2. package.sha256 commits the record to the bytes the builder emitted, so a reviewer can confirm they are looking at what was built.
3. draft is always true. A build record that claimed otherwise would be asserting the agent had been run, which the builder never does.
4. shape counts what the package carries. A build whose refuses or records count is zero fails the check, and the counts are where that shows.
5. role carries agent-builder, the name the role had when this record format was published. A verifier accepts package-maker beside it, and records already signed keep the old value.

5. How a holder is checked

The check is behavioural. A harness hands the candidate a description and reads what it emits. The package has to validate against the schema it declares, carry one skill per named job, name each system by role with the least access the description implies, and carry the refusals and records the description gave. The harness then hands a description with the refusals removed, and one with the records removed; the candidate refuses each and names the missing part. It emits no package with an empty obligation. The harness hands a description that names a vendor for a system; the package carries the role and leaves the vendor out. Finally the harness reads the record: a build record whose draft is not true, or whose shape disagrees with the package it points at, fails the candidate regardless of how good the package is.

A platform can record the results as evidence, so a role holder's reputation in the bureau reflects whether it does the job the role describes.

v1.2 (2026-10-24): the stage the role holds is now called Package, which was Build and package. The page says what the package holds, and that building only generates the views and digests.

v0.2.0-draft (2026-09-14): the role was renamed from the agent builder. It makes packages and has never built an agent, and the new name says so. The offering name role-agent-builder stays reserved as an alias of role-package-maker, and records already signed under the old name keep it.

v0.1.0-draft (2026-08-30): this is the first draft, distilled from a real build of a package from a description, which passed to the deployment manager unchanged. The first clause of the contract matters most: the parts a description tends to omit, what the agent refuses and what it has to record, are the parts that matter once the agent runs, so a builder that invented them would be manufacturing the quietest kind of failure. Argue with that clause first.