LightWire is the coordination layer for a managed-agent system. It does not host the agentic loop itself. Managed agents handle reasoning, tool use, and iterative execution in provider infrastructure. LightWire handles the control plane: message normalization, route matching, prompt rendering, session dispatch, output capture, and follow-on routing.
The runtime is built around a small set of provider-neutral concepts:
- normalized messages
- route matching
- prompt rendering
- managed-agent session execution
- captured routed outputs
- connector cursors and heartbeat state
That separation lets the execution layer stay remote while the coordination layer stays local and inspectable.
Every inbound event becomes a NormalizedMessage.
Current sources include:
- API events from
POST /events - Slack connector events
- Telegram connector events
- heartbeat ticks from the scheduler
- agent outputs emitted after a session completes
Each message then follows the same path:
- Persist the normalized message in SQLite.
- Match routes from
workspace/routes.yaml. - Render the route prompt template with message context.
- Start the target managed-agent session with:
- agent instructions from
AGENT.md - enabled skill instructions from
SKILL.md - the rendered route prompt
- configured built-in tools and MCP servers
- agent instructions from
- Persist the session record and raw agent output.
- Convert the result into a normalized
agent_outputmessage. - Feed that output back into the dispatcher so downstream routes can run.
This gives LightWire explicit multi-agent chaining without requiring shared working directories or implicit memory conventions.
Direct routed outputs are the normal handoff mechanism.
- an upstream agent returns the output content itself
- LightWire captures that output as orchestration state
- downstream routes receive structured upstream context
Agents do not need to know provider filesystem paths. They do not need to emit a strict JSON contract just to hand off work to the next step.
app/main.py: FastAPI app creation, startup, shutdown, and service wiringapp/config.py: workspace and environment-backed config loadingapp/models.py: shared runtime modelsapp/routing/: route matching and prompt renderingapp/workers/: dispatch, session execution, and output normalizationapp/connectors/: external event ingestion and reply adaptersapp/scheduler/heartbeat.py: internal heartbeat schedulerapp/claude/: Claude Managed Agent provider adapterapp/db/sqlite.py: SQLite-backed repositories
SQLite stores orchestration state, not the shared execution environment for agents.
Key tables include:
messages: inbound and internal normalized eventssessions: managed-agent session recordsagent_outputs: captured completion content and summariesheartbeats: next and last run stateconnector_cursors: Slack and Telegram resume stateprovider_state: cached provider resource IDs such as environments, memory stores, vaults, and credentials
The current provider adapter targets Claude Managed Agents, but the routing model is not Claude-specific.
LightWire owns:
- route evaluation
- template rendering
- connector ingestion
- output capture
- orchestration persistence
The managed-agent platform owns:
- model execution
- tool invocation
- iterative reasoning
- provider-side session lifecycle
To support another managed-agent backend, the main seam is the provider adapter layer. The rest of the system can stay intact:
- normalized message handling
- route matching
- workspace conventions
- repository interfaces
- connector logic
The current Claude-specific implementation is concentrated under app/claude/.