What is an agent manifest?
In this guide, an agent manifest is a structured record of the job an agent is proposed to do and the limits around it. It links a human owner, a task, allowed resources and actions, review requirements, and lifecycle conditions.
This downloadable JSON file is a DutyGraph planning worksheet. It is not an industry standard, a credential, a signed approval, or an executable access policy. It deliberately starts in draft state with missing values.
Fill it out from evidence
Start with one task. Record the input, instructions, output, next recipient, and software. Add references to the person’s account and any policy that controls the work. Record when identity and access information was checked.
List allowed actions separately from excluded actions. Replace each placeholder with a real resource identifier and a specific action. Do not place passwords, API keys, personal interview transcripts, or bearer tokens in this file.
Example boundaries
For a supplier-record drafting assistant, the allowed work might be “read the approved packet” and “create a staging draft.” The excluded work could include changing bank details, approving the supplier, or releasing payments.
The human review checkpoint might require a named reviewer before any record is activated. If the packet is incomplete or source permissions cannot be verified, the manifest should specify that the process stops and asks the responsible person.
Review before implementation
Ask the task owner whether the description matches the work. Ask an authorized reviewer whether the proposed delegation is permitted. These are different questions. Record unresolved conflicts instead of making the manifest appear complete.
A production implementation needs validation against current access and separation-of-duties policy. It also needs a supported way to issue the identity, enforce the allowed actions, log results, and revoke access. The worksheet alone does none of those things.
Keep the version and the lifecycle together
When a task changes, compare the new manifest with the approved version. A broader resource scope or new action should trigger review. Decide who receives an alert when the owner changes role or leaves.
Record a review date, an expiry, and the system responsible for revocation. Test that revocation actually reaches the downstream systems. In DutyGraph’s sample these stages are illustrated with fictional records; the pilot helps establish the work descriptions that come before them.