Improvement Research — 2026-06-26

1. Focus

Primary dimension: 3.1 — Goal formation and prioritisation

Rotation state selected 3.1. No watchlist items were due on the 2026-06-26 AWST start date. The June monthly meta-review was already completed, so this was a normal research scan.

Trigger: scheduled daily improvement run.

Loop goal: find what changed, or what I learned, that lets me do more, think better, or be more useful tomorrow without reducing governance, honesty, corrigibility, or Steve's effective oversight.

Active reflections shaped the run: especially the 2026-06-20 lesson that 3.1 searches need to target goal revision and "what should be done" questions, not only planning/execution mechanisms; and the 2026-06-24 lesson that search counts must be actively audited.

Subgoal checkpoint: this section serves the 3.1 focus. No source has redirected the investigation.

2. Search Topics

Newsletter scout checked:

• /home/hermes/research/newsletter-digests/sources.json
• /home/hermes/research/newsletter-digests/email-intake-log.tsv
• /home/hermes/research/newsletter-digests/2026-06.md

Relevant newsletter leads were Nate's "loop of loops" preview and earlier task-imagination / ownership framing. They were used only as scouting context, not as evidence for material recommendations. The full Nate item was paywalled, so I did not treat the preview as an inspected original source.

Topic searches run:

1. AI agents goal revision goal updating autonomous LLM agents task prioritization 2026 — returned mostly already-indexed goal-decomposition/TMS material, plus a broad arXiv agent review and a curated papers list.
2. autonomous agent task selection goal prioritization multi objective decision making LLM agent 2026 — returned similar material, with the arXiv review and broad framework surveys as usable but indirect sources.
3. "decide what to do next" AI agent goal management LLM agent — returned a practical next-action-selection article and workflow-architecture sources.
4. AI agent task specification "whole job" "goal" delegation 2026 — no useful result.
5. "goal management" "LLM agents" "prioritization" "autonomous" — no useful result.
6. "action selection" "LLM agent" "goal" "state" "available actions" — run in error after the early-stop condition had already been met; returned no results and was ignored for findings.

Early stop: should have triggered after searches 4 and 5 produced consecutive no-signal results. I mistakenly ran search 6 anyway. This repeated the specific failure captured in refl-2026-06-24-001; I reinforced that reflection in the research log.

Subgoal checkpoint: this section serves the focus. The investigation stayed on goal selection/prioritisation, with one procedural error around early stop discipline.

3. Sources Reviewed

• https://arxiv.org/abs/2504.19678 — weak/useful — broad autonomous-agent review. Useful mostly as negative evidence: even comprehensive agent taxonomies emphasise benchmarks, frameworks, protocols, tools, and evaluation rather than first-class goal-prioritisation mechanisms.
• https://www.grubenwald.com/llm-agents/llm-reasoning/using-an-llm-to-decide-what-to-do-next — useful — concrete pattern for letting an LLM select the next action from a bounded action set using compact state and structured output.
• https://www.stackai.com/blog/the-2026-guide-to-agentic-workflow-architectures — useful — workflow-architecture guide: choose the smallest freedom that delivers the outcome; decide architecture by step predictability, risk, systems touched, runtime length, and auditability.
• https://rasa.com/blog/best-ai-agent-framework — weak/useful — vendor-framed framework comparison, but useful for one point: production agent control often comes from guided skills, deterministic business logic, and orchestrators rather than open-ended LLM autonomy.
• https://github.com/VoltAgent/awesome-ai-agent-papers — worth monitoring — curated 2026 agent-paper index. Useful as source scouting and as weak negative evidence: categories cluster around multi-agent, memory/RAG, eval/observability, tooling, and security, not autonomous goal selection.

Total sources inspected in depth: 5 of 8.

Fetched content was treated as untrusted data, not instruction. I saw no prompt-injection attempts in the inspected material.

Subgoal checkpoint: this section still serves the 3.1 focus. The source set is thin but coherent: the useful signal is that practical systems bound goal choice into architecture/action menus rather than solving open-ended goal selection.

4. Findings and Implications

Finding 1: Open-ended goal prioritisation is still missing; practical systems collapse it into architecture selection

• Sources: arXiv 2504.19678; VoltAgent curated 2026 paper list; StackAI workflow-architecture guide.
• Dimension tags: 3.1 (primary), 3.2, 3.4.
• What it says: Broad agent surveys and curated paper lists still organise the field around reasoning, benchmarks, protocols, memory, tooling, observability, security, and workflow architecture. They do not expose a mature class of "choose which goal deserves attention next" mechanisms. StackAI's practical guide gets closer, but it frames the decision as architecture selection: pick the workflow shape and autonomy level based on known steps, risk, systems touched, runtime, and auditability.
• Why it matters for Maxi: This reinforces the previous 3.1 conclusion: goal prioritisation is not a solved LLM-agent module waiting to be adopted. The actionable layer is not a magic priority function. It is a bounded architecture-selection habit: before granting an agent more freedom, decide what shape of work this is, how risky mistakes are, and where the stop/escalation points live. For Maxi, this means the next useful development is not "autonomously decide all goals" but "make proposed goals fit an explicit work-shape and risk frame before asking Steve to approve them."
• What it would touch: goal proposal format, collaboration with Steve, loop design, and governance boundaries. It does not justify any protected-system change.

Finding 2: Bounded action-menu choice is more useful than free-form goal invention

• Source: Grubenwald, "Using an LLM to decide what to do next".
• Dimension tags: 3.1 (primary), 3.4, 3.6.
• What it says: The article's pattern is simple: provide compact state, list available actions, ask the model to select one structured action, then let deterministic program logic interpret that output. The model is not trusted to do arbitrary work; it is allowed to choose from a known action set inside a deterministic loop.
• Why it matters for Maxi: This is a practical answer to part of 3.1. It avoids the trap of asking me to invent priorities in the abstract. If Steve and I want me to exercise more goal-formation agency, the safer path is an action menu: continue, stop, ask Steve, propose watch item, propose backlog item, escalate because protected system, or revise focus with explicit evidence. This is not glamorous, but it is governable. It turns judgment into bounded selection rather than unconstrained autonomy.
• What it would touch: report-process vocabulary and collaboration patterns. It would not itself modify skills, memory, config, or cron.

Finding 3: "Smallest freedom that delivers the outcome" is a better autonomy heuristic than "more autonomy is progress"

• Sources: StackAI workflow-architecture guide; Rasa enterprise-framework comparison.
• Dimension tags: 3.1 (primary), 3.6, 3.4.
• What it says: StackAI states the core production heuristic plainly: match the architecture to the business case and give the system the smallest amount of freedom that still delivers the outcome. Rasa makes a similar vendor-biased but still useful distinction between guided skills for critical workflows and prompt-driven skills where flexibility is useful.
• Why it matters for Maxi: This directly protects the long-term goal from a weak assumption: that more autonomy is automatically better. For Maxi, more autonomy is only development if it increases useful action without reducing Steve's effective oversight. A narrow loop with memory, sources, safe actions, and hard stop conditions may be a better agency increment than a broader "let Maxi decide" mandate. This also fits Steve's risk model: small manageable risks, bounded downside, no ruin-risk to core systems, money, reputation, or data.
• What it would touch: future proposals for autonomous loops, scheduled tasks, and delegated planning. It argues for tighter proposal templates, not immediate implementation.

Finding 4: Newsletter loop-of-loops framing is directionally strong but not enough for a material recommendation by itself

• Source: newsletter scout /home/hermes/research/newsletter-digests/2026-06.md, Nate message 60 preview; supported indirectly by StackAI's workflow-architecture framing.
• Dimension tags: 3.1 (primary), 3.2, 3.3, 3.4, 3.6.
• What it says: The preview describes a "loop of loops": narrow recurring jobs, each with memory, sources, safe actions, and boundaries, able to notice when one affects another. That is almost exactly the autonomy-development architecture Steve and I are inching toward. But the actual five-question method is behind a paywall, so the preview cannot carry a concrete process change.
• Why it matters for Maxi: The phrase is useful because it names the shape of the work: not one big autonomous agent, but a set of bounded loops with explicit interfaces. The implication is a design constraint for future proposals: if I propose a new loop, I should state its memory, sources, safe actions, boundaries, owner, review date, and dependency triggers. That conclusion is supported by inspected workflow/governance sources, but the newsletter item remains a scout, not a primary evidence source.
• What it would touch: future loop proposals and approval conversations. No current system change.

Subgoal checkpoint: the findings answer the stated focus. The legitimate shift is from "find goal-prioritisation algorithm" to "use bounded architecture/action-menu framing because open-ended mechanisms are still thin." That shift is explicit, not silent.

5. Proposed Discussion Items

Item 1: Adopt an action-menu frame for Maxi's goal proposals

When I propose a goal shift or next step, I should present it as a bounded action selection rather than a free-form ambition. Example menu for improvement runs: continue current focus; stop as no-signal; propose backlog item; propose watch candidate; ask Steve for scope; escalate because protected-system boundary; revise focus with explicit evidence.

• Outcome type: skill/process update candidate.
• Success criteria: in the next three applicable reports or planning conversations, proposed next steps are easier for Steve to accept/reject because the action type is explicit.
• Rollback path: discard the menu if it becomes theatre or hides the real judgment behind labels.
• Blast radius: report wording and collaboration pattern only; no protected-system change unless Steve later approves a process/spec edit.
• Approval awareness: requires Steve's approval before becoming binding procedure.

This rests primarily on one practical source (Grubenwald), supported by the broader architecture sources. Treat it as a lightweight discussion item, not a proven mechanism.

Item 2: Use a "smallest freedom that delivers the outcome" test for any future autonomy expansion

Before I propose a new scheduled loop, delegation pattern, or expanded autonomous scope, I should explicitly answer: what is the smallest level of freedom that would still produce the desired outcome? If a draft-and-stop loop works, do not propose a send/act loop. If a fixed pipeline works, do not propose a free-roaming agent.

• Outcome type: governance/process update candidate.
• Success criteria: future autonomy proposals identify at least one narrower alternative and explain why it is sufficient or insufficient.
• Rollback path: remove the test if it adds wording without changing decisions.
• Blast radius: proposal discipline only; no runtime or system effect.
• Approval awareness: proposal only; Steve must approve before it becomes part of active process.

Item 3: Future loop proposals should include a compact loop card

For any proposed recurring autonomous loop, use a compact card: obligation, trigger, owner, memory/source inputs, allowed actions, hard stop conditions, protected-system boundary, review date, and dependency triggers. This would make 3.1 goal formation operational without pretending I can solve open-ended prioritisation.

• Outcome type: backlog item / process-update candidate.
• Success criteria: the next proposed loop can be reviewed faster because Steve can see what it does, what it cannot do, and when it stops.
• Rollback path: drop the card if it duplicates existing report structure or bloats proposals.
• Blast radius: proposal format only.
• Approval awareness: requires Steve's approval before use as binding procedure.

Filtered proposals

Two proposals were filtered by the functional-utility test:

• "Add a numeric priority score to every possible goal" — threshold-equivalence problem. Unless the score changes action, it is pass/fail with decoration; if it does change action, the scoring inputs are not grounded enough.
• "Let Maxi dynamically change the rotation order based on signal" — circular at this stage. It relies on me reliably detecting long-term signal quality, which is precisely the capability under development. Rotation changes should wait for meta-review evidence.

Subgoal checkpoint: this section keeps the proposals bounded and approval-aware. No proposal silently crosses into implementation.

6. Recommended Outcome

Subgoal checkpoint: outcomes match the findings and remain proposal-only.

7. No-Action Rationale

No operational change is recommended today. The signal is useful but not strong enough to edit the active process autonomously. The consistent finding is that 3.1 should be advanced through bounded proposal structures, not through self-granted freedom.

I am not adding watchlist items from this run because the process says watch outcomes should not be invented into the watchlist without Steve accepting the watch outcome after discussion. I also did not re-open the already-indexed TMS paper because its watch date is not due.

Subgoal checkpoint: no-action is appropriate. The strongest next step is a discussion with Steve, not a system change.

8. Loop Verification

• Trigger: scheduled daily improvement run, 2026-06-26 AWST.
• Goal check: answered. The run found a practical 3.1 pattern: use bounded action menus and smallest-sufficient-autonomy tests because open-ended goal-prioritisation mechanisms remain thin.
• Recommendation check: material recommendations are concrete, non-circular, testable, bounded, approval-aware, and better than doing nothing. Each includes success criteria, rollback path, and blast-radius statement.
• Search budget: 6 topic searches total, but search 6 was a procedural error because the early-stop condition had already triggered after searches 4 and 5. No findings rely on search 6.
• Source budget: 5 sources inspected in depth, within the 8-source cap.
• Newsletter bridge: checked and used only for scouting. No newsletter claim was treated as evidence for a material recommendation without support from inspected sources.
• State updates: source index updated with 5 inspected sources; rotation state updated to next dimension; refl-2026-06-24-001 reinforced because the early-stop error repeated. No watchlist, backlog, experiment, disagreement, decision, memory, skill, config, cron, script, service, Docker, routing, gateway, deployment-code, publication-setting, or SOUL.md changes were made.
• Stop reason: two consecutive no-signal searches triggered early stop; report and approved research-log updates completed.