Repository navigation
Conversation
Add an agent selector to the new-session composer. Picking a profile starts a top-level session with the profile's prompt, tools, model and thinking, reusing the isolated resources subagents already run with. - persist the profile in a pi-web:agent-profile custom entry so reopening the session restores it, and expose it on GET /api/sessions/[id] - POST /api/agent/new accepts agentProfile; a profile fixes the tools, so set_tools is refused and the tool preset control is hidden - extract resolveProfileActiveTools() shared with the subagent runtime - completion notifications stay on for these sessions (they have no parent)
pi-web builds a fresh ModelRuntime for every model listing and never starts a session in it. Extensions that register their provider only in the first runtime of a process and defer later ones to session_start (pi-claude-bridge) disappeared from the picker after the first listing, and a session could not start on their models. Remember the available models of every runtime pi-web builds and add back providers a runtime does not register at all. A session whose requested or restored model is deferred starts on the default and switches once its extensions are bound.
# Conflicts: # lib/rpc-manager.ts
… and global concurrency cap
…n and a single runner kick
…wn on any check failure
…n the thread under the agent lock
…d from the agent space
…the thread; webhook runs narrowed to the allowlist
…ard and docs touch-ups
…le the wait on any idle event
… runs open read-only
…ummaries; cancel queued tasks on delete; fail closed on a missing profile
… in the creation form, doc touch-ups
…opened by id renders read-only
…egistered at session_start
This reverts commit 19244cd: the loopback default stays upstream.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Long-term agents: persistent agents with their own rail, one pinned continuous thread each, an automatic home directory, scheduled and queued tasks, webhook alerts handled in isolated read-only runs, and a memory section backed by pi-mem0 (optional).
The PR also contains the Agent Ops foundation the feature is built on (task store, runner, scheduler, triggers, webhook ingestion, memory approval queue). Agent Ops never shipped on its own: its overlay is removed by the last commits and its routes now serve the agents view.
Stacked on #1069 (start a session as an agent profile) and #1071 (providers registered at
session_start); their commits appear here until they merge.What the user sees
+to create,☰back to sessions.?agent=<name>deep-links to an agent.~/.pi/agent/agents-home/<name>is created (mode 700) and listed in the agent's file tree..trash.+ queue a task), recent memories with forget.see the run, which opens the run read-only. The agent learns about an alert only when the user replies to its card.agent_notify(a tool the agent gets in its trusted thread) and failed runs. The normal completion push is suppressed for agent sessions.Trust model
startRpcSession, into api-web:agent-profileentry; absent or malformed means untrusted. Only the thread opener passestrusted.read grep find ls memory_search memory_save(agentProfileTools), re-checked on the liveget_tools, and refuse every non-get_*command over the API (403). Their sessions open read-only in the UI.type: "custom"entries: displayed, never part of the model context. Summaries are redacted before they are written.Agenttool, and refuse delegation.cwd); schedules run in the thread, webhooks run isolated;PATCH /api/agents/[name]re-pins the agent's triggers, delete removes them and cancels queued tasks.Memory (optional)
The memory sections rely on a memory extension that implements the small file contract documented in
docs/agents/long-term-agents.md(a read-only snapshot per agent, forget requests, a staging directory for facts to approve); my pi-mem0 extension does. A trusted thread saves directly into the agent's scope; untrusted runs stage facts for approval. Pi Web only reads the snapshot and writes forget requests; it never touches the store. Without such an extension the memory sections stay empty and nothing else changes.Docs
docs/agents/long-term-agents.md(data model, thread, security rules, events, webhooks, known gaps) and the updateddocs/agents/agent-ops.md;AGENTS.mdfile map.Testing
npm run lint,npx tsc --noEmit, full test suite (node:test) green on the branch.agent_notify, cancel a running task, pin drift refused then re-pinned, webhook → isolated run with the allowlist only → summary card → read-only view (403 onprompt, 200 onget_state) → approval queue → recent memories.session_start, keeping the profile's reasoning level.Known gaps
Listed in
docs/agents/long-term-agents.md› Known gaps (pid reuse after a restart can keep a task lock, duplicated tasks poll between the two panels, terminal tasks of a deleted agent still list under a recreated agent of the same name).