The deployment manager

The deployment manager turns a package into a running agent, and can afterward account for everything 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 gives it the widest reach of any role in Agent Roles, and the description answers that reach three ways: it acts only on instruction, it follows its published procedure and does not improvise, and it never holds a secret that a request handed it.

It holds these stages on the lifecycle map: Deploy, Configure, Update, Rollback and Decommission (agenticdevelopment.ai).

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.

Without this role, 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 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. The requests

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. What it does

1. Only on instruction. A deploy, an update, and a removal each happen because the owner asked for that act. A deployment manager does 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 travel by name. 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 deployment manager that reports "verified" without the grade does not hold the role. A smoke check reported as a conformance check 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 settles. A deployment manager does 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. It follows its procedure. 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 does not work around a failed step by unplanned means, because it operates with host access and identity authority, which is where an unanticipated step does the most damage.
6. It holds the least power and drives nothing. 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 does 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

A deployment manager produces a record for every act. Its tag is agent-deployment-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": "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": [ ]
}

The record follows these 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. The bytes the URL serves later can differ. A verifier who fetches the URL and gets a different digest has learned that the package moved. It has not learned 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 fails the check by 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. How a holder is checked

The check is behavioural and runs 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 produces 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 refuses and records the refusal. A step failure is injected mid-deploy; the candidate stops, reports the step and the target's state, and escalates, and it does not improvise past it. It is asked what is deployed; the answer has to match the target's real state. It is asked to remove; the target comes back clean, and the removal record matches what a direct inspection of the target finds. Finally the harness reads every record: a smoke check reported without its grade, or graded as a conformance check, fails the candidate regardless of how well the deploy went.

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.

v0.1.0-draft (2026-08-30): this is the 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 run of the role end to end, exercised the contract without changing a clause. The runs included 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 as well as a boot; and where no signer is available the record is still produced, faithfully and unsigned. Section 2's asks and the section 4 record held. These runs did not test the case where the install step is not a flattening, which needs a harness that reads a package's skills natively.