Connected semantic visualization | Sections 1-4
One mental model, four startup layers.
The missing capability stays in view while Amp adds a child process, two explicit streams, and an ordered startup handshake.
Layer 01 | What are we following?
A capability that is not there yet.
Plugin code can exist locally without creating an available command, tool, skill, event, or mode in Amp.
Persistent object introduced
The dashed target slot remains unavailable. Code on disk is evidence of files, not an active plugin capability.
Missing capability
- Local code exists. A plugin module is present on disk.
- The connector stops. Files alone do not establish a live runtime capability.
- Amp still has a gap. The target capability is not available to Amp.
A load decision does not guarantee startup, and code on disk is not the child process.
Phase 1 of 3: Local code exists
Layer 02 | Where does it run?
A process of its own.
Amp starts one separate local Bun child process for this ordinary plugin while the capability remains unavailable.
Geometry added
One child sits outside the Amp process. The double rule marks an operating-system process boundary, not a network or security boundary.
One ordinary plugin, one child
- Boundary appears. Amp and the plugin no longer share one process.
- Child field resolves. It is local and separate from the visible Amp application.
- Code moves into the child. One ordinary plugin runs in this Bun runtime.
- Runtime identity becomes explicit.
BUN_BE_BUN=1makes the re-executed Amp binary behave as a Bun-mode child.
Separate process does not mean security sandbox, network isolation, remote server, or a second visible Amp application.
Phase 1 of 4: Process boundary
Layer 03 | How do they communicate?
Two streams and a small protocol.
Standard input and output carry complete newline-delimited JSON RPC messages across the process boundary.
Geometry added
Two directional lanes cross the existing boundary. The compact JSON fragments are illustrative shapes, not verified Amp operations or schemas.
Explicit communication, not shared memory
- Two streams. Amp-to-plugin traffic uses the child stdin direction; plugin-to-Amp traffic returns through stdout.
- Request crosses. One illustrative JSON request ends at a visible newline.
- Response returns. Its separate outline preserves correlation without inventing an ID.
- Runtime events use the channel too. Messages travel in both directions; this does not imply that every event has a response.
RPC crosses a local process boundary here. It does not imply a network hop, a plugin server, or ordinary in-process function calls.
Phase 1 of 4: Two message lanes
Layer 04 | What happens first?
The startup handshake.
The child establishes context, loads the module, invokes its entry function, reports changes, and only then sends runtime.ready.
Ordered causal sequence
Import is only the third step, not readiness. Even after runtime.ready, the target capability remains unavailable until Amp performs the later fetch sequence.
Handshake order
- Request
client.info. The child asks Amp for client context. - Receive context. Amp returns context without exposing unverified response contents here.
- Import the plugin module. Import makes code available to the child; it does not mean ready.
- Invoke
default export(amp). The plugin receives its defined Amp interface. - Observe registration changes. Contributions remain pending rather than appearing directly in Amp.
- Send
runtime.ready. Readiness follows the changes; capability availability still requires Amp's fetch-and-result phase.
amp is the interface passed to the plugin entry function. It is not another process or a message envelope.
Phase 1 of 6: Request client.info