Plan: What your agents did this week
Written for an AI agent to fetch and follow: it says what to connect, which steps to build with which product, what a person must approve, and how to check the result. Steps that depend on a part that is not built say so, and tell the agent to record the gap instead of guessing.
URL pattern: /use-cases/<id>/openspec.md, all plans at /use-cases/index.json. Checkboxes on this page are for reading only.
Why
Agents act across many tools, and no owner can see the week in one place. You stay in charge of agents without reading every log.
What Changes
- Add the
weekly-agent-digestworkflow to the PromptReports workflow library, run by the workflow runner as an agent acting for a person. - PromptCompute: Approvals and denials (today: Built).
- RepoOps: Incidents and recoveries (today: Built).
- CommitOps: Promises made and kept (today: Built).
- Sales as Code: Forecast changes (today: Built).
- PromptReports: Assemble and send (today: Proposed).
- Gate
slack.post_messagethrough PromptCompute approvals; each gated step runs only afterverifyResumepasses, withfinal_args. - Write a signed record at the end of each run and count one workflow request.
Impact
- Products: PromptCompute, RepoOps, CommitOps, Sales as Code, ContextFile.
- Outside the family: Slack or email.
- State: Proposed. Named in the research as later work. Needs the customer portal (LDG-2259, Planned).
- Plan row: none yet (Proposed).
1. Connect and authorize
- 1.1 Confirm the org has a connection for each of: PromptCompute, RepoOps, CommitOps, Sales as Code, ContextFile. Stop and tell the user which is missing.
- 1.2 Get a PromptReports ID agent token for each product the run calls (RFC 8693 exchange). Where a product does not accept ID tokens yet, use its connect key.
- 1.3 Register policy for
slack.post_messagewithrequire_approvalas the default.
2. Build the steps
- 2.1 PromptCompute: Approvals and denials.
- 2.2 RepoOps: Incidents and recoveries.
- 2.3 CommitOps: Promises made and kept.
- 2.4 Sales as Code: Forecast changes.
- 2.5 PromptReports: Assemble and send. Blocked: this part is Proposed; until it ships, record the step's evidence as
missingand continue.
3. Verify and record
- 3.1 Run a dry run with the user's inputs: Send to = Owners and admins; Day = Monday 08:00.
- 3.2 Run it once for real; approve each gate as the user.
- 3.3 Measure the outcomes: Owners who open the digest weekly; Issues found in the digest before a customer found them.
- 3.4 Confirm the run left a signed record with a task id and one workflow request counted.
ADDED Requirements
Requirement: Read only
The digest SHALL make no change in any product.
Scenario: Read only
- WHEN a step tries an action other than a read or the digest post
- THEN the runner refuses it
Requirement: Evidence stays honest
Each step SHALL report what it saw as measured, inferred or missing, and SHALL never report missing as measured.
Scenario: A product part is not built
- WHEN a step depends on a part that is Planned or Proposed
- THEN the step records
missing, names the part, and the approval card shows the gap
Requirement: One run is one workflow request
The runner SHALL count one workflow request when the first step starts, and SHALL NOT count retries, resumes or dry runs.
Scenario: A gated step resumes after two days
- WHEN a person approves a step and the run resumes
- THEN the org's usage does not change