Pi Extensions

Where future runtime extensions belong in the Pi-native architecture.

OpenWaggle runtime capabilities are routed through Pi adapter boundaries.

Future runtime capabilities should be implemented as Pi-native extensions or adapter-backed ports:

• Pi SDK imports stay in src/main/adapters/pi/.
• Application and IPC layers consume vendor-free OpenWaggle ports.
• Renderer code displays OpenWaggle-owned DTOs and runtime events.
• New tools should use Pi-native extension points and OpenWaggle-owned IPC DTOs.

This keeps OpenWaggle extensible without leaking vendor SDK types across the app.

Pi reference: Extensions.

Skills vs Runtime Extensions

Skills are instruction packages. Runtime extensions change what the agent can actually do.

OpenWaggle injects project resource roots into Pi with .openwaggle > .pi > .agents precedence for skills, extensions, prompts, and themes. Same-name project resources resolve from .openwaggle first, then .pi, then .agents.

Runtime extensions belong behind Pi adapter boundaries and need explicit product support in IPC and the renderer.

For custom provider registration, see Pi’s pi.registerProvider() documentation.

MCP

MCP is the first user-facing Pi extension-backed runtime capability in OpenWaggle. It uses the pi-mcp-adapter package and keeps source configuration in MCP JSON files instead of OpenWaggle’s SQLite settings store.

OpenWaggle binds Pi session extensions during session creation and emits session_shutdown before disposal. Future extension hosting should follow the same boundary: Pi owns runtime extension execution, OpenWaggle owns typed settings/projection UI and passes only explicit adapter inputs across the boundary.