u/Certain_Net_3408

I’ve been looking at Hermes Agent’s "/goal" approach: give the agent a persistent goal, let it continue across turns, have a lightweight judge decide whether it’s done, and stop when the goal is achieved or the turn budget is exhausted.

It got me thinking about Pi:

Could this be implemented as an extension rather than a core feature?

Something like:

"/loop 30m "Fix the tests and get CI green""

The extension would manage:

• a time/iteration budget
• continuation decisions
• completion checking
• pause/stop
• existing Pi session state

That feels quite aligned with Pi's philosophy: keep the core small, but make powerful agent behaviours possible through extensions.

Would a lightweight, time-bound autonomous loop be useful in Pi, or does this belong entirely outside the harness?

I've been looking at Prime Agent, which is built on Pi, and I'm curious what the Pi community thinks about some of the ideas they've added on top of the Pi foundation.

Prime Agent describes itself as a self-improving RLM harness for coding and long-running autonomous tasks, with several interesting differences in how the harness operates:

• Programmatic tool calling the model can use a persistent execution environment to compose tool calls rather than treating every tool invocation as a simple one-shot interaction.
• Context as a variable context can be programmatically inspected, transformed, compressed, persisted, and selectively brought back into the working context rather than treating the conversation history as a fixed block.
• Multi-agent messaging agents can spawn/delegate to other agents and communicate with them as part of a longer-running task.
• Self-modifiable harness state the agent can modify things such as memories, skills, prompts and sub-agent configurations while working, allowing the harness to adapt based on what it encounters.
• Long-running autonomous execution the emphasis is less on interactive "chat → edit → chat" coding and more on giving the agent a goal and letting it work through the problem, iterate, test and recover over a longer horizon.
• RLM-style persistent execution Prime Agent uses a persistent execution environment where state can survive across interactions, giving the model another layer in which to manage context and reasoning.

What caught my attention is that Prime Agent is built on Pi, rather than being an entirely separate agent architecture.

So I'm wondering:

Would it make sense to bring some of these ideas back into Pi as optional/core primitives?

For example, could Pi eventually have a more native concept of:

"Pi → persistent execution → programmable context → sub-agents → modifiable skills/memory → iterative refinement"

while still keeping Pi's current philosophy of being minimal, composable and hackable?

Or is the whole point of Pi that these things should remain extensions on top of the minimal core, rather than becoming part of Pi itself?

I'd be particularly interested in hearing from people who've actually used both Pi and Prime Agent. What does Prime's architecture enable that you couldn't achieve cleanly with Pi extensions today?

Not trying to argue that Prime is "better" — I'm more curious whether some of these RLM/harness ideas represent a direction Pi could support while preserving its minimal philosophy.

I’ve been experimenting with Pi packages and published pi-agent-continuity, a small extension for making long-running Pi sessions less forgetful.

The first version was a continuity layer around compaction, forks, and subagent workflows. After some great feedback, I added an experimental branch for agent-managed handoff: the agent can decide when context is getting noisy, save durable knowledge, record a focused handoff brief, and continue with cleaner state.

What it includes:

• JSONL memory ledger
• /ac:status, /ac:memory, /ac:remember
• continuity_memory and remember_continuity
• bridge tools for pi-subagents
• subagent lifecycle tracking
• new continuity_handoff tool
• durable reusable notes
• session-scoped handoff briefs
• next-step tracking
• context-load advisory memory around ~30%, ~50%, and ~70%

The important bit: this does not replace Pi’s native compaction yet. It is advisory/tool-driven. The agent gets visibility and tools, but still chooses when to hand off, compact, continue, or ask the user.

The idea is heavily inspired by:

• elpapi42/pi-observational-memory
• tintinweb/pi-subagents
• agenticoding/pi-agenticoding

My mental model right now:

pi-subagents = execution layer
pi-agent-continuity = memory layer
agent-managed handoff = policy layer

Repo: https://github.com/vishn9893/pi-agent-continuity

Tags:

• v0.0.1: baseline continuity package on main
• v0.1.0: agent-managed handoff experiment branch

Would love feedback from anyone building Pi extensions or running long-lived agent sessions.