Products, tools, and operational surfaces
This is the map of the systems I build on: where each product fits, what it owns, and which surface I reach for when the work moves from planning to production.
A map of the products and internal surfaces I use most often.
Each product links to docs, playground, and writing so you can inspect the work instead of relying on summary copy.
In-progress work is labeled explicitly — nothing here is aspirational.
Start with the surface, then follow the evidence
Open the product first, then follow the docs, writing, or playground path that shows how the work behaves in practice.
From private model to production workflow
The pitch is not four unrelated tools. It is a path for teams that need private inference, governed agent access, repeatable orchestration, and a concrete sensitive-data use case.
Operate private model runtimes first
FlexInfer gives teams a Kubernetes-native control plane for model lifecycle, OpenAI-compatible routing, GPU-aware placement, scale-to-zero activation, quantization, adapters, and model artifact delivery.
Can this model run, scale, route, and roll back inside our cluster boundary?
FlexInfer product →Govern the agent and tool boundary
Loom and Loom Core turn MCP sprawl into a single governed entrypoint with registry sync, daemon routing, tiered memory, fleet state, sandbox execution, RBAC, audit, and HUD visibility.
Which agents can reach which tools, with what context, and what audit trail?
Loom Core product →Compose repeatable DAG workflows
MentatLab is the mission-control surface for DAG agent orchestration over direct API model nodes and internal services. In this stack, those model calls can target FlexInfer private endpoints instead of a frontier coding harness.
Can operators design, validate, run, and observe the workflow as a graph?
MentatLab product →Apply it to sensitive integration work
fi-fhir ties the platform story to healthcare ETL: Source Profiles, HL7v2/FHIR parsing, semantic events, workflow routing, terminology mapping, and AI-assisted explanations inside a controlled environment.
Can legacy clinical data become validated, explainable, routable events?
fi-fhir product →FlexInfer
Private inference operations for teams that need model lifecycle, routing, GPU placement, quantization, adapters, and OpenAI-compatible endpoints inside their own boundary.
- Run private model endpoints behind Kubernetes-native lifecycle and readiness controls
- Customize with quantization pipelines, OCI model delivery, and LoRA adapter workflows
- Route chat, completions, embeddings, and image flows through standard OpenAI-compatible APIs
Loom
MCP and agent-fleet coordination for private operations: editor sync, single-entry tool access, daemon routing, tiered context, Weaver orchestration, skills, and workflow memory.
- Single registry across Codex, Claude, Gemini, Zed, VS Code, Kilocode, and Loom Core
- Agent sessions, tasks, handoffs, recall, compaction, and fleet state stay inspectable
- RBAC, audit, sandbox execution, remote transport, HUD, and mobile surfaces keep MCP controlled
MentatLab
Mission Control for DAG-based agent workflows that call direct API model nodes, internal services, MCP-governed tools, and private FlexInfer endpoints.
- Design workflows as explicit graphs with dependency-aware execution plans
- Use direct model/API calls instead of assuming a frontier coding harness is the runtime
- Pair with Loom for context and policy, and FlexInfer for private model endpoints
fi-fhir
Healthcare ETL and integration tooling for Source Profiles, semantic events, workflow routing, terminology mapping, and HL7v2/FHIR development in an AI-first IDE loop.
- Profile-driven ingestion across HL7v2, FHIR, CSV, EDI X12, and CDA/CCDA
- Semantic event layer, FHIR output, and workflow DSL for routable transformations
- AI-assisted warning explanations and workflow generation for integration development
Read the tradeoffs and postmortems
If you want to see how I think, start with the case studies and writing that explain the decisions behind these product surfaces.
Open the working surface
When the product card is not enough, the playground is where I keep hands-on validation flows and docs-backed tooling.
Boundary matrix
Core surfaces I use most often: runtime, context control, and sensitive-data integration.
Boundary types I validate first: deployment and integration.
Unfinished enterprise controls stay visible here so you can tell what is shipping and what is still moving.
Architecture snapshots
High-level diagrams for runtime control, public operations surfaces, and GPU GitOps automation.
Loom Core control plane
Registry-driven client sync, loom proxy ingress, daemon routing, and HUD-backed operator surfaces for private MCP operations.
Loom Core context management
Session-start recall, tiered memory, and prompt-pressure compaction keep agent context bounded and queryable.
Loom Core Weaver orchestration
FlexInfer-backed multi-domain routing with curated tool bundles and compound tools for reusable agent work.
FlexInfer control plane
OpenAI-compatible proxying, model lifecycle control, and GPU-aware execution inside a private cluster boundary.
FlexInfer runtime lifecycle
Artifact preparation, cache gating, quantization, and preload behavior that turns model intent into a ready endpoint.
FlexInfer federation surface
GlobalProxy and FederatedModel coordinate cross-cluster reach while keeping runtime execution local to each cluster.
Healthcare parsing pipeline
Profile-driven transformation flow for sensitive interoperability workloads.