Pulsing Integration¶

How Forge uses Pulsing Actor capabilities — and what remains in-process.

Capability matrix¶

Pulsing feature	Forge usage	Maturity
`@remote` + spawn	`ToolWorkerActor`, inbox, MCP hub, code registry	✅
`resolve` (gossip)	Shared worker, inbox, hub, registry	✅
`ask`	Exec approval, permissions, code cell nested tools	✅
`tell`	Forge events, inbox → Host side effects	✅
`new_process`	Isolated `ToolWorkerActor`	✅
`ForgeBackend`	LOCAL / DEDICATED / SHARED	✅
Supervision policy	Manual respawn via supervisor	🟡
Queue / Topic	Not used — events in memory	⚪
Multi-node placement	Local spawn only	⚪

CraftAgent.call_tool("Read", ...)
  → ForgeBackend
  → ForgeWorkerSupervisor → ToolWorkerActor (child process)
  → ToolResult

Worker / Host runtime
  → tell_forge_event(inbox)
  → ForgeEventInbox.on_forge_event
  → tell Host.on_forge_stream_event / on_forge_side_effect

Worker
  → ask Host.resolve_exec_approval
  → Host UI / PermissionChecker
  → decision dict

Component	Reason
`HybridForgeRuntime`	PyO3 callbacks, Session state, MCP in Rust
`ForgeWorkerSupervisor`	Cannot spawn child from actor mailbox
REPL `LocalToolRuntime`	Debug path without cluster
Extension handlers	Local I/O, no cross-node need

This is intentional layering: Actor for deployment boundaries, not for every function call.

Most integrators should use:

from pulsing.forge import ForgeEnvironment          # library / tests
from pulsing.forge import ForgeBackend, ...         # Craft-style host

Only advanced hosts need tell_forge_event, ensure_forge_actors, or custom gossip names.

No new_process spawn inside actor mailbox handlers — use Host process or delayed patterns.
Isolated actors must pickle cleanly — defer locks / exec managers to on_start.
Separate approval sink from event sink — inbox receives tells; Host receives asks.