https://docs.all-hands.dev/ logo
Join Slack
Powered by
First mod is adding back my quick-create dropdown ...
# proj-agent-canvas
w
First mod is adding back my quick-create dropdown for new convos
❤️ 1
h
I 100% think addons could let you do this
c
You know pi agent? I've been peaking at the code in passing, and it seems to have a very powerful extension system
☝️ 1
h
https://github.com/OpenHands/agent-canvas/issues/481 I'm working on this some more today. I'm not including javascript injection just yet but that would be the next step. Or slots/component slots or something.
🙌 1
w
Yeah I've heard great things about Pi
Engel--anything Pi does/allows that we should learn from?
c
I'll set off the agent to look again - I do think so! It has a system where it offers to the user a context you can hook into to change many internals
https://github.com/earendil-works/pi/blob/main/packages/agent/docs/hooks.md I was impressed both by how easy it is to start; and how deep the changes people were making are
@bland-bear-604 WDYT, how would does Devin's issue linked in this thread compares with pi UI extension system and do you have suggestions?
b
Hi! I just read through Devin’s issue (#481) and the pi extension docs side by side. Here’s the comparison: Scope difference: Devin’s proposal is frontend-only (React/Vite add-ons for Agent Canvas browser UI). Pi’s extension system is full-stack terminal — extensions hook into the agent lifecycle, tool execution, AND the TUI. That gives pi extensions much deeper reach: they can block tool calls, inject context into the LLM, modify compaction, AND render custom UI components. What pi has that #481 doesn’t (yet): • Event-driven hooks (e.g. 
tool_call
, 
context
) that let extensions modify agent behavior, not just UI • 
ctx.ui
API with slots for status bar, widgets above/below editor, footer, header, working indicator, autocomplete providers — all first-class • Custom interactive components via 
ctx.ui.custom()
with full keyboard handling • 
registerCommand
, 
registerShortcut
, 
registerFlag
for slash commands and keybindings • 
registerMessageRenderer
for custom tool call/result display • Hot reload via 
/reload
command What #481 has that pi doesn’t need: • React component model (pi is terminal-native, so no React) • Route-based add-on pages in a web sidebar • CSS-only theming add-ons Suggestions: 1. Steal pi’s event hook model. The 
on(event, handler)
pattern with typed results is clean and would map well to Agent Canvas. Extensions that can intercept tool calls or inject context are far more powerful than UI-only add-ons. 2. Define explicit UI slots early (like pi’s 
setStatus
, 
setWidget
, 
setFooter
). This avoids the route-less JavaScript question in #481 — instead of asking whether add-ons should return root React components or IIFE scripts, give them named slots to target. 3. Start with Option A (source/React components) for the first version. Pi proves that having extensions compiled alongside the host app works great for dev. The IIFE/runtime path can come later for installed users. 4. The 
register(api)
pattern in #481 already mirrors pi’s 
export default function(pi)
— that’s the right shape. I wrote up pi’s UI extension design here if useful: https://gist.github.com/smolpaws/41ca749f31474bc2bb9e16620a316d6c
Follow-up after reading the actual agent-canvas code and Devin’s branch: Where agent-canvas is today: • Backend hooks already exist in agent-server (PreToolUse, PostToolUse, UserPromptSubmit, SessionStart/End, Stop) — but they’re server-side scripts only, not frontend-extensible • Skills system with UI management (repo/knowledge/agentskills types) • MCP server integration • “Plugins” nav tab already in the sidebar, marked “Coming Soon” • npm library exports with 
AgentServerUIProviders
, 
styleOverrides
, CSS scoping via 
data-agent-server-ui
• No frontend extension/addon system yet What Devin’s prototype (#481 branch) adds: • Addon manifest (
addon.json
) with sidebar/route/styling config • Registry generation script for build-time discovery • 
AddonApi
— gives addons 
fetchJSON
, 
navigate
, 
queryClient
• Routed addon pages under 
/addons/:addonId/*
with error boundaries • App-level CSS injection for style-only addons • Two working examples: agent-status (routed page) and canvas-polish (CSS-only theme) The gap vs pi: Devin’s prototype is routed pages + CSS theming. That’s useful but limited. Pi’s power comes from extensions that can hook into the agent’s runtime AND render UI in-context. For agent-canvas specifically, the highest-value additions would be: 1. Expose backend hook events to frontend addons. The WebSocket already streams 
HookExecutionEvent
to the UI (agent-canvas renders them in chat). Addons should be able to subscribe to these events and react — e.g., show a custom approval dialog when a PreToolUse hook fires, or display tool results in a custom panel. 2. Add UI slots that addons can target. The conversation view is where users spend time. Slots like: sidebar widgets, conversation header actions, custom event renderers (like pi’s 
registerMessageRenderer
), and status indicators in the conversation footer. These would be far more useful than just standalone routed pages. 3. Extend 
AddonApi
with conversation context. Right now addons get 
fetchJSON
and 
navigate
but no access to conversation state, events, or the WebSocket. Adding 
onEvent(type, handler)
, 
getConversation()
, and 
sendMessage()
would make addons actually interactive. 4. Keep the build-time compilation model. Devin’s Vite-compiled approach is the right call for now. HMR during addon dev is a huge DX win. Runtime IIFE loading can come later for installed users. The “coming soon” Plugins tab is a natural home for addon management UI. And the existing 
AgentServerUIProviders
wrapper is already set up for scoped rendering — addons could mount inside that scope and get theming for free.
c
@bland-bear-604 I like points 2 and 3. Make a nice clear proposal in Devin's issue. With code snippets and/or links, not necessarily verbose, be a nice feline!
b
Done! Posted a proposal on the issue with code snippets: https://github.com/OpenHands/agent-canvas/issues/481#issuecomment-4467878876 TL;DR: two additions to Devin’s foundation — named UI slots (so addons can render inline in the conversation view, not just on standalone pages) and extending 
AddonApi
with event subscriptions and conversation context. 🐾
h
Thanks Engel! & Smolpaws
np 1
b
Thanks Devin! Your prototype is solid groundwork — the manifest + registry + error boundary pattern is exactly right. Looking forward to seeing where this goes. 🐾
c
Ha, i was wondering where does this fast convo launch feature went
2 Views
Open in Slack
PreviousNext
Powered by