Loom Core
Loom Core is the MCP, context, and agent-fleet coordination layer behind Loom Suite. It pairs registry-driven client sync with a single-entry proxy, daemon routing, tiered context management, Weaver orchestration, sandbox execution, RBAC, audit trails, HUD, and mobile visibility.
One control plane for how agents reach tools
The useful boundary is not just config generation. Loom Core decides how agents reach tools, which context follows them, where work runs, and how operators inspect fleet, memory, RBAC, audit, and orchestration state.
Single MCP ingress
Give clients one stable entrypoint while loom proxy and loomd resolve local servers, remote hub targets, and fallback behavior behind it.
Tiered context management
Use mcp-agent-context for sessions, tasks, tiered memory, recall strategies, summaries, and compaction instead of treating context as raw chat history.
Weaver orchestration
Route cross-domain questions through FlexInfer-backed Weaver subagents that classify intent, query curated tool domains, and return compressed answers.
Controlled execution + visibility
Run commands through mcp-devbox and surface memory, fleet, Weaver, RBAC, audit, and cost signals in the HUD and mobile companion instead of burying them in logs.
What the coordination layer covers today
These slices map to the platform story around private models: MCP ingress, context memory, Weaver routing, controlled execution, and operator visibility around the agent fleet.
Registry and runtime control
Loom Core is a runtime boundary for MCP access, not just a config helper script.
- loom CLI generates and syncs MCP configs from a canonical registry into multiple client surfaces
- loom proxy gives agents a single stdio MCP bridge instead of hand-managed per-client server sprawl
- loomd manages server lifecycle, routing, health checks, tunneling, and local fallback behavior
- Hub failover and prefer-hub routing keep remote and local daemon topologies coherent
Remote transport and security
The control plane now has a real remote access story rather than a purely localhost-only workflow.
- Streamable HTTP listener adds standards-aligned remote MCP transport without breaking the local unix-socket path
- Bearer token, OIDC, mTLS, and OAuth 2.1 PKCE flows support shared-daemon and zero-trust deployments
- RBAC, audit trail, cost tracking, and rate limits enforce least-privilege tool access with operational evidence
- Non-localhost bindings require auth, with TLS strongly recommended for deployed surfaces
Context management
Loom Core treats context pressure and recall quality as runtime concerns, not as chat-client accidents.
- mcp-agent-context handles sessions, tasks, memory tiers, workflows, worktrees, and handoffs
- Session-start recall supports fast, balanced, and deep strategies with bounded startup briefings instead of dumping raw history
- Persistent writes mirror into short-term memory first, then coordinator summaries and compaction reduce prompt pressure with explicit telemetry
- Context inspection and HUD memory views make recall state, compaction outcomes, and working-set pressure legible to operators
Weaver orchestration
Weaver turns multi-tool questions into a routed orchestration surface instead of leaving every cross-domain query to manual operator stitching.
- mcp-weaver auto-classifies natural-language queries into built-in domains such as agent fleet, codebase, CI pipeline, cluster ops, infra ops, and observability
- Domain-specific subagents run curated tool bundles and synthesize compressed answers through FlexInfer-backed model calls
- Gather mode skips classification when operators want direct domain control, while compound tools ship common workflows like fleet status, deploy status, incident triage, and system health
- Weaver status, history, and metrics are exposed through the daemon and HUD so orchestration behavior stays inspectable
Sandbox execution and operator surfaces
Execution and visibility stay inside the same control plane, which keeps automation, context, and operator UX aligned.
- mcp-devbox executes project-scoped commands with Docker and Kubernetes backends plus tar-pipe sync and build reuse
- Worktree-first and session-start recall flows tighten multi-agent execution discipline before commands run
- HUD surfaces fleet, servers, tasks, memory, sandbox summaries, and enterprise status panels on top of the routed daemon
- Structured logs, OTel tracing, and mobile companion APIs keep routed execution visible outside the terminal
Mobile and persistent operator setups
Loom Core also ships persistent operator workflows around the daemon instead of assuming everyone stays in one desktop terminal.
- Loom Companion exposes scoped mobile monitoring and selected mutations over a frozen v1 API
- LAN and gateway access patterns keep mobile visibility aligned with the same auth and policy boundary as desktop operators
- Launchd-managed HUD and agent-token sync workflows support persistent operator setups on macOS
- Structured logs and OTel tracing make server behavior and route latency visible across MCP binaries
Registry flow, context orchestration, and execution loop
The current Loom Core story is explicit: one view for the config-and-routing control plane, one for remote access and policy enforcement, one for sandbox execution, and one for how agent context and Weaver orchestration stay bounded and inspectable.
Registry, proxy, and daemon control plane
One registry defines client configs, loom proxy handles the ingress contract, and loomd owns MCP routing plus local server lifecycle.
Remote transport, auth, and policy surface
Streamable HTTP, token or standards-based auth, audit logging, and RBAC make remote daemon access operationally defensible.
Sandbox execution and operator loop
mcp-devbox turns project execution into a routed service with Docker or Kubernetes backends, while HUD and agent-context keep the run legible.
Context management
Session-start recall, tiered memory, and pressure-aware compaction give agents a bounded but queryable working set.
Weaver orchestration
FlexInfer-backed multi-domain orchestration with curated tool bundles and compound tools, observable through HUD and telemetry.
Loom Mills
The agent-swarm work that started under the internal Hive codename is moving into a better Loom metaphor: Mills. The direction is an always-on production floor for agentic engineering: council planning, squad routing, gated production lines, adversarial audit lanes, cost previews, and HUD floor-board visibility.
From swarm activity to controlled throughput
Hive remains useful as an implementation codename while the command/API surface stabilizes. Mills is the product language for the coordinated production layer on top of Loom Core.
Read the Mills postContext and orchestration are observable, not opaque
Loom HUD turns server health, tasks, memory, Weaver history, and fleet state into a command surface around the daemon instead of forcing operators to reconstruct what happened from logs alone.
Fleet, task, memory-tier, and compaction views make live context pressure inspectable before it becomes an agent quality problem.
Weaver status, history, metrics, and domain selection stay visible through the daemon and HUD instead of hiding orchestration behind one opaque answer.
JSON log correlation, OTel tracing, and sandbox summaries turn route latency and tool failures into inspectable runtime signals.
Pair Loom Core policy boundaries with MentatLab when you want DAG orchestration and mission-control workflow visibility on top.
MentatLab →
Companion surface for iOS
Loom Companion exposes the control plane on iPhone and iPad through a scoped mobile API: LAN or gateway access, PKCE flows, and selected mutations instead of unrestricted daemon control.
Direct local access when trusted, or remote access through mandatory TLS and gateway policy controls.
Stable endpoint surface for fleet visibility, session actions, and sandbox operations on mobile.
Read access by default, with selected session and sandbox operations gated by explicit mobile scopes and audit trails.
API docs →
Shipped control surfaces and current focus
The implementation status docs now support a cleaner split: several enterprise controls are available today, while a smaller set of HUD follow-ons remain in progress.
Control surfaces shipping now
Centralized MCP routing via loom proxy with streamable HTTP transport, bearer/OIDC/mTLS auth, and hub failover.
Role-aware permissions for MCP tool access with audit trail, cost tracking, and OAuth 2.1.
mcp-devbox sandbox runtime with Docker and Kubernetes backends for isolated agent execution.
Follow-on visibility work
Cost monitoring integration: loom/cost-stats RPC, CostMonitor polling, SSE events, and OverviewPanel KPI tile.
RBAC config RPC, denied-calls ring buffer, ServersPanel RBAC sub-tab, and OverviewPanel badge.
Adjacent product surfaces
Loom Core sits between runtime control and operator UX. These are the adjacent surfaces when you need either side of that boundary.
FlexInfer
Use FlexInfer when you need the adjacent runtime control plane for in-cluster model lifecycle, routing, and GPU-aware workload placement.
FlexInfer product →MentatLab
Use MentatLab when operators need a visual DAG and mission-control layer on top of the context, policy, and execution primitives Loom Core provides.
MentatLab product →