From 4ebb4d127b6f595934953736d5fa9e63ab964e21 Mon Sep 17 00:00:00 2001 From: wassname <1103714+wassname@users.noreply.github.com> Date: Tue, 8 Sep 2026 07:52:47 +0800 Subject: [PATCH] Record user intent for visible supervision User wording with spelling and punctuation corrected. Preserve prior design discussion separately. Co-Authored-By: Pi/OpenAI <288921227+claudypoo@users.noreply.github.com> --- AGENTS.md | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index f8cbb47..4ff5a78 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -15,7 +15,29 @@ Run `npm test` before a commit. It includes unit and flow tests plus the RPC rev Run `/goals ` in that pane. Tmux checks the rendered menu, editor focus, widget, and keyboard handling. RPC does not render the terminal UI. - `pi -p` has no UI, so it cannot test `Ready`, `Refine`, `Edit`, or `Cancel`. -## Intended supervision workflow +## User intent for this branch + +To be clear, the hope is we can have a smart supervisor like you, with judgment and context. But it doesn't use many tokens as it checks in and sees an overview. + +It steers a smaller model, adding perspective and judgment. + +It compacts every 150k or similar to avoid cost and context rot. + +It has a goal / plan on a Ralph-loop-type repeat. + +That lets the worker be a cheaper model, and the supervisor more expensive, and still get a good outcome. + +Oh, and since it's two panes, the user can review both! + +Well, I want to see what the supervisor is thinking and saying. That's the whole point: all supervisor thinking and messages should be visible. + +So that should make it obvious that I need to see the messages, and the supervisor needs to use judgment. For example, it could say how we are tracking or whatever every time, and it would be useful, like in the recap. + +And it would only be a few output tokens. + +-- wassname (spelling and punctuation corrected by Pi/OpenAI) + +## Earlier supervision workflow discussion I already have pi-intercom-supervisor, but thought using pi-subagents could make it simpler. The idea is that the user makes a plan as in pi-goals, but on this branch, instead of a naive stateless subagent, we 1) fork, 2) compact, and 3) make it a supervisor with a prompt as in pi-intercom-supervisor. The supervisor is cheap because it sees only high-level material, which costs fewer tokens. It has good judgement because it sees a) compacted planning context, b) the plan, and c) summarised context (for example, my modified pi-vcc). This lets it operate read-only and steer the worker without losing track. It also compacts every 100k tokens to keep it cheap and high-level.