Hire an agent: its own identity, a narrow scope, and an offboarding that reaches every product

How the Hire an agent workflow will bring a new agent onto a team the way you would a new hire, from registration and listen mode to earned autonomy and a one-run offboarding.

Hire an agent is a workflow for builders adding a new coding, ops or support agent to a team. It will treat the agent like a new hire. The agent will get its own identity and a narrow scope, start in listen mode, read the team’s lessons before it acts, and earn autonomy one action at a time. When it leaves, one run will take its keys away in every product. PromptCompute, ContextFile and RepoOps each do a part.

The workflow is partly built. Several of the pieces it stands on already work inside PromptCompute and RepoOps, and this guide says which.

The problem

New agents often start on a shared service key with wide access. Nobody knows in advance what the agent will do with it, and nobody can say afterwards which actions were the agent’s and which were a person’s using the same key.

The end of the agent’s job is worse than the start. When an agent is retired or replaced, its keys stay behind in every tool it touched. Someone has to remember each one and revoke it by hand.

How the workflow solves it

The workflow will give the agent its own identity before it gets any access at all. In PromptCompute an agent has an id that starts agt_, an Ed25519 key, and a version (agv_) pinned to a signed manifest of its code, model and prompt. Once the PromptReports ID agent token is on, each of the agent’s requests will name that version.

From there the agent starts small. Its environment will run in listen mode, and it will read the lessons that apply to the code it will touch. Autonomy comes from the record. PromptCompute groups past requests by action and amount range, and suggests auto-approval only when a range has at least 200 decisions and a 97% lower bound on approval. Even then, a shadow period comes first, and 5% of auto-approved requests still go to a person for review.

Offboarding will be one run that revokes the agent everywhere and reports any product that did not confirm.

Step by step

When the workflow runner ships, a run will take these steps. Present tense means the part works in its product today; “will” means it is still to build.

A run will start when a person starts it from the app, or when an agent asks to be hired.

1. PromptCompute registers the agent and its version from a signed manifest. If the manifest detail does not hash to its declared digest, registration is refused with manifest_detail_mismatch, and the run will stop.
2. PromptCompute puts the agent’s environment in listen mode.
3. ContextFile will give the agent a starter context packet for its job, versioned and cited, so you can see later exactly what it was told.
4. RepoOps will load the lessons the agent must read before it acts, chosen for the repos it works in. The brain those lessons come from works today; agents read it with search_brain.
5. PromptCompute reviews earned autonomy per action after the trial. A person grants each step up, and access grants are critical actions that never run without approval.
6. PromptCompute will offboard the agent. It will revoke the agent’s keys and tokens in every connected product, and list each product that did not confirm.

The offboarding step has a rule of its own in the plan. If a product does not confirm the revoke within ten minutes, the run will mark that product missing and open an approval for a manual revoke. A half-finished offboarding will show as half-finished.

What the workflow will report

Each run will report three numbers:

• The share of agents on their own identity. The plan sets the target at 100%.
• The days each agent spent in listen mode before policy was enforced.
• The minutes it took to offboard an agent from every product.

The record of the run will name the agent version, its scopes, and every person who approved a grant.

Why it matters to a builder

You will be able to let a new agent do real work in its first week without betting the production database on it. It starts narrow, and each permission it gains later is backed by its record on that action and amount range, not by a guess about the agent in general.

It will also give you an answer when a reviewer asks what an agent was allowed to do. The registration, the grants and the approvals are signed, so you will show the record instead of describing your process.

How to set it up

Outside the family you connect GitHub and the agent’s runtime. The runtime can be any MCP client.

When the runner and the signed-in app ship, setup will be:

1. Sign in with PromptReports ID and pick your org.
2. Connect PromptCompute, ContextFile and RepoOps.
3. Prepare the agent’s version manifest: its code commit, model and prompt hash.
4. Set the approval policy for grant.create, access.grant and access.revoke. The last two are critical, and critical actions are never automatic.
5. Fill in the agent’s name and its starting scope, and start a dry run.
6. Start the run, approve the grants, and watch the agent’s record during listen mode.

An agent will be able to ask to be hired itself, through the PromptReports MCP server or API, using the proposed start_run tool.

You can register an agent in PromptCompute today without the workflow. The API takes POST /v1/agents, a signed key challenge, the key, and a signed version manifest. Its token, once the ID’s agent tokens are on, will name the person who started the agent (sub) and the agent and version (act).

Hire an agent is on every plan, like every workflow. Plans are per user per month: $25 for 100 workflow requests, $50 for 500, and Enterprise above 500. There is no free tier. Hiring an agent is one request, and offboarding it is another.

What is built today and what is planned

The workflows page lists Hire an agent as partly built: one of three parts is merged, and the PromptCompute hire flow and the RepoOps lessons step are still to go.

In the products today:

• PromptCompute registers agt_ agents with Ed25519 keys and agv_ versions pinned to a manifest digest.
• PromptCompute runs listen mode per environment and grants earned autonomy per action.
• RepoOps keeps the brain of lessons that agents read before they act.
• ContextFile gives a starter context packet for the agent’s job, versioned and cited (ContextFile #154).

Planned:

• A guided hire flow in PromptCompute, in the portal and over MCP.
• The step that picks the RepoOps lessons for the agent’s repos and keeps its track record as it works.
• Offboarding in every product. That waits on every product accepting the PromptReports ID agent token, which is also planned. The ID’s token exchange is built and off until its key is set.
• Registering any agent once for the whole family. Today registration lives in PromptCompute alone.
• The workflow runner. No runner exists today. The plan is a durable runner service in the PromptCompute stack, with one run id across products, approvals as steps, and each run metered as one workflow request.

Read more

• Every workflow and its state
• Pricing
• Which agent actions need a person? A threshold table
• PromptCompute, ContextFile and RepoOps