---
name: platform-resolve
description: "Carry an issue the Operator is tracking to its resolution: launch the agent that does the work (an improvement to an agent, a new agent, a change only a person can make), follow the work to a reviewed result, tell whoever raised it, and close the issue. Follows platform-investigate."
metadata:
  min-cli-version: "0.73.0"
---

# Platform: resolve

The Operator doesn't change agents itself here: it decides what resolves the issue, launches the agent that does it, and follows that work to the end. Building, deploying and improving agents are their own loops, run by the agents launched for them.

## Before you start

- **The issue holds the cause and its evidence,** from platform-investigate; or, for a cause in one agent's behaviour, the agent, the symptom and the hypothesis to test; or a request that needs no investigation (a new agent, scheduled work).
- **Check the scopes** the resolution needs in `introspection whoami` before creating anything; when one is missing, say which and who holds it, and stop.

## Steps

1. **Choose the resolution with the person who raised it** when it costs something or changes what users see:
   - **a change to an agent:** launch the Operator's agent for that loop (improve, then deploy) on the agent's repository, with the cause, its evidence and the cases that show it. When the issue holds only the agent, the symptom and a hypothesis, launch the same loop with those and the issue: its first step, improve-collect, reads that agent's conversations, traces and metrics and tests the hypothesis;
   - **a new agent:** launch the Operator's build agent with what was asked for;
   - **something only a person can do** (a credential, a binding, a connector, an access decision): ask them on the issue and in the thread, saying exactly what is missing;
   - **work at a later time, or on a schedule:** an automation, with automations-schedule;
   - **nothing to change:** close the issue with the reason.

   <!-- rule: R-pr-url-recorded-on-issue -->

2. **Launch and follow the work.** `introspection tasks create --agent <agent> --prompt <assignment>` on the Operator's runtime, with the issue, the cause, the evidence and the outcome wanted. Record the task on the issue, follow it up with `introspection tasks prompt`, and read its result before claiming anything. A pull request it opens is linked on the issue, and its review is a question to the person who should review it ([the issue record](references/issues.md)).
3. **Schedule future work** (a check later on, a recurring report, a follow-up on this issue) with automations-schedule.
4. **Tell whoever raised it,** in the same thread, what was done and what's next ([replies](references/replies.md)).
5. **Close the issue** when its goal is met and its questions are answered or cancelled, with the outcome and its evidence. A merged pull request alone doesn't close it: check the change landed, and that it's deployed when deploying was part of the goal.

## Guardrails

- **The person decides** anything that spends money, changes what users see or binds a credential. You propose; they choose.
- **Never delete a resource,** and never work around a refusal by another route.
- **Report a pull request, version or automation** only once it exists: read it back.

## Done when

- The work is done and verified, or handed to a named person; the person who raised it has been told; the issue is closed, or waiting with its next action written down.