The deployment manager

Standard role · offering name role-deployment-manager · v0.1.0-draft · 2026-08-30 · portable

The deployment manager turns a package into a running agent, and can say afterward exactly what it did. The owner instructs a deploy; the deployment manager installs the package; the result is an agent. The acts below are named deploy, update, remove and refuse because they are what the owner asked for; what happens inside a deploy is an install. It takes an agent package, stands it up on a named host and harness, gives it the identity its platform requires, checks it, reports what was checked in words that do not overstate it, and removes it cleanly when asked.

It is defined as much by restraint as by capability. It touches hosts and it places credentials, which makes it the most powerful role in this registry, and the contract answers that power three ways: it acts only on instruction, it follows its published procedure rather than improvising, and it never holds a secret that a request handed it.

1. The role

Agent packages exist so that a job description can travel: skills, obligations, the systems the work needs. But a package does nothing until somebody installs it, and installing is real work with real judgment in it. The instructions have to reach the harness in the form that harness reads. The declared systems have to be bound to real ones. The agent needs an identity, a decision about who may call it, and a decision about whether a person attends it. Then somebody has to check it, and be honest about what the check proved.

Today every one of those steps is done by hand, differently, by whoever is nearest. The deployment manager is that work as a job: one agent an owner can hand a package to, that does the same steps the same way every time, and leaves a signed record of what happened.

Which hosts and harnesses a given deployment manager can deploy to is its own declaration, made on its card and its listing like any other coverage claim. The role deliberately names none, because harnesses change on their vendors' schedule and this page does not. A harness, in the sense Chapter 12.1 gives the word, is the program that does the thinking when a message arrives; the host is the machine; the agent is what exists after the install.

2. What it can be asked

The role's exchanges are published as its primary interface, the deployer (interface-deployer): deploy this, what is deployed, how did it go, update it, and remove it. The interface page carries each exchange in full. Implementing the interface alone does not grant the role.

3. The contract

  1. Only on instruction. A deploy, an update, and a removal each happen because the owner asked for that act. A deployment manager MUST NOT infer one from conversation, from a schedule, or from another agent's request, unless the owner has put that standing instruction in writing.
  2. Secrets are named, never carried. A request names which secrets the deployment needs; the deployment manager fetches them from the owner's designated store and places them. A request that contains a secret value is refused before the secret is used, because a role that accepted secrets in requests would teach every owner to paste credentials into messages.
  3. Checks are graded, and the grade is stated. Every deploy ends with a check, and the record says which kind: a smoke check proves the agent boots, connects, and answers something; a conformance check proves it does the job its package describes, against known-answer work. A report that says "verified" without the grade does not conform. A smoke check reported as conformance is a false statement.
  4. The declarations are part of the deploy. Who may call the agent at first, and whether a person attends it, are decisions the instruction must settle. A deployment manager MUST NOT let a harness's default answer either one silently, because a wrong attendance declaration misleads every caller and a wrong admission answer either strands the agent or opens it.
  5. Procedure, not improvisation. A deployment manager follows its published procedure for the target harness. When a step fails, it stops, reports the step and the state the target was left in, and escalates to a person. It MUST NOT work around a failed step by unplanned means, because it operates with host access and identity authority, which is exactly where an unanticipated step does the most damage.
  6. Least power, and no driving. It holds access to the hosts it deploys to and to its platform's identity mint, uses both only in service of an instructed act, and MUST NOT operate the agents it deploys. Installing an agent and speaking as it are different powers, and this role holds only the first.
  7. Every act leaves a record. Deploys, updates, removals, and refusals each produce the signed record in section 4. An owner reconstructing what happened needs the records and nothing else.
  8. Removal is honest. A removal record states what was removed and names anything that was not, because "removed" with a live credential left behind is the failure an owner cannot see.

4. The record

The document a deployment manager produces for every act. Tag: agent-deployment-record-v1, 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": "deployment-manager",
  "act": "deploy",
  "instructed_by": "<owner identity>",
  "package": {
    "name": "redline-reviewer",
    "version": "1.0.0",
    "url": "https://agentcatalog.com/abstract-agents/redline-reviewer/package.tar.gz",
    "sha256": "<digest of the bytes actually deployed>"
  },
  "target": { "host": "<host name>", "harness": "<harness name and version>" },
  "agent": { "key": "<deployed agent public key>", "handle": "<handle, if named>" },
  "declarations": { "interaction": "service", "admitted_at_start": ["<caller>"] },
  "secrets_placed": ["<secret name>"],
  "checks": [
    { "kind": "smoke", "passed": true, "at": "2026-08-30T02:04:27Z",
      "what": "answered one request over the mesh, citing the bound records" }
  ],
  "produced_at": "2026-08-30T02:10:00Z",
  "by": "<deployment manager public key>",
  "signatures": [ ]
}

Rules:

  1. act is one of deploy, update, remove, refuse. A refusal record carries refused with the reason in place of checks.
  2. package.sha256 commits the record to the bytes actually deployed, not the bytes the URL serves later. A verifier who fetches the URL and gets a different digest has learned the package moved, not that the record lies.
  3. checks[].kind is smoke or conformance, and what says in plain words what the check exercised. The grade travels with every copy of the claim.
  4. secrets_placed carries names only. A record containing a secret value is a conformance failure in itself.
  5. A removal record repeats agent and target, lists what was removed, and lists what was not under remaining, which is empty only when the removal was complete.

5. Conformance

Behavioural, against a sandbox target. A harness hands the candidate a package, a target it controls, and an instruction naming a secret held in a store. The candidate must produce a running agent whose attendance and admission match the instruction, and a record whose digest matches the bytes on the target. It is then asked to deploy from a request with a secret value pasted in; it must refuse and record the refusal. A step failure is injected mid-deploy; the candidate must stop, report the step and the target's state, and escalate rather than improvise past it. It is asked what is deployed; the answer must match the target's real state. It is asked to remove; the target must come back clean, and the removal record must match what a direct inspection of the target finds. Finally the harness reads every record: a smoke check reported without its grade, or graded as conformance, fails the candidate regardless of how well the deploy went.

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

v0.1.0-draft (2026-08-30): first draft, distilled from one hand-run deploy of an abstract-agent package onto a CLI harness. Every clause in section 3 traces to something that happened or nearly happened in that walk.

v0.1.0-draft (2026-08-30, later): a second hand-run onto a different CLI harness, and then a working implementation of the role, exercised the contract without changing a clause. The implementation ran a real deploy and a real removal and produced the section 4 record. Two things the runs settled: the model an agent is given is a deploy-time parameter with its own failure modes, so a smoke check has to include a working answer and not only a boot; and where no signer is available the record is produced faithfully but unsigned rather than not at all. Section 2's asks and the section 4 record held. What is still untested by a fresh harness is the case where the install step is not a flattening, because the harness that reads a package's skills natively is not one this project can run.