# MLX

> A business-owned AI operating layer that connects private systems, structures operational knowledge, encodes workflows as skills, and routes work across the models a company chooses.

MLX is for established organisations whose valuable work is spread across private systems, documents, SaaS tools, spreadsheets, legacy data, and key-person knowledge. It deploys managed, in the customer's VPC, or on-prem; connects approved systems with read-only defaults; builds governed operating views; and keeps workflows, skills, rules, and reviewed corrections outside any single model provider. Every customer is paired with a Mercury Labs forward-deployed engineer who maps the first workflow, wires up sources, and authors the initial skills. Claude, OpenAI, open-weight, and self-hosted models become routing choices rather than places where the business logic is trapped.

## What MLX does

- **Owns the business record.** Connects accounting, CRM, documents, email, warehouse, ERP, and operational systems into an AI-ready layer that stays under the customer's control.
- **Owns the playbook.** Captures recurring workflows, judgement calls, reports, exceptions, approvals, terminology, and source-of-truth rules as reviewable skills and overlays.
- **Runs where the data lives.** Supports managed cloud, customer VPC, and on-prem deployment patterns with read-only defaults and scoped capabilities.
- **Keeps model choice portable.** Claude, OpenAI, open-weight, and self-hosted models are routing choices. The customer's workflows and reviewed corrections stay in MLX rather than inside one provider.
- **Controls the cost curve.** Per-workflow model routing lets cheap models handle high-volume work and frontier models handle jobs where they earn the cost.
- **Improves through review.** Every run leaves evidence. Reviewed misses become better company-owned skills and rules instead of opaque vendor memory.
- **Ships with implementation support.** Mercury Labs engineers embed with the team to map the workflow, wire up sources, and author the first useful skills.

## Core concepts

- **Operating layer**: the customer-owned layer of connected systems, governed views, skills, overlays, model routes, audit trails, and review loops that sits between a business and the AI models it uses.
- **Skills**: customer-authored, versioned definitions of recurring processes the agent can run repeatedly. Equivalent to runbooks for the agent.
- **Overlays**: business-specific rules, terminology, source-of-truth preferences, caveats, and judgement that shape how skills use data.
- **Profiles**: scoped contexts that bind a skill to specific data sources, capability levels (read vs. write), and approver chains. Govern who and what the agent can act on.
- **Forward-deployed engineers (FDEs)**: MLX engineers who embed with the customer's team during deployment to wire up integrations and author skills. Replaces the typical "platform shipped, you figure it out" model.
- **Read-only by default**: the agent's initial capability set is analysis and answer generation against approved data, not autonomous actions on customer systems. Write capabilities are scoped, audited, and opt-in per profile.
- **Customer-controlled execution**: the agent worker can run in MLX's managed cloud, the customer's VPC, or fully on-prem.
- **Per-task model routing**: each skill specifies which model it runs against, so customers compose cheap and frontier models per workflow and rebalance as prices move.

## How a deployment works

Four-week implementation, run with a forward-deployed engineer:

1. **Week 1 — Choose the first workflow.** A forward-deployed engineer maps the source systems, repeated decisions, reports, exceptions, and controls around one valuable workflow.
2. **Week 2 — Connect read-only systems.** Bring the required data sources into MLX with scoped permissions so evidence and access are clear.
3. **Week 3 — Author views and skills.** Build the channels, tables, dashboards, skills, and overlays that make the workflow repeatable and reviewable.
4. **Week 4 — Run, review, and expand.** Put the first workflow into use, review the evidence trail, then expand to adjacent workflows, models, and deployment requirements.

## Common questions

- **Where does our data go?** It stays under customer control. MLX connects to approved systems, builds governed views, and starts read-only by default.
- **Can we run this on-prem or in our own VPC?** Yes. The agent worker is designed for customer-controlled execution.
- **Are we locked into one LLM provider?** No. Workflows, skills, rules, and reviewed corrections live in MLX. Claude, OpenAI, open-weight, and self-hosted models are routing choices.
- **What does this cost to run?** Customers control the per-task model choice, so the marginal cost of running a workflow is set by the customer's routing strategy — not by a vendor's premium per-seat SaaS curve. Open-weights and self-hosted models are first-class.
- **Why not just use ChatGPT or Microsoft Copilot?** Those are broad assistants. MLX is the company-owned operating layer underneath them: source-system access, governed views, skills, rules, audit trails, and model routing.
- **We're regulated. Can we use this?** The combination of customer-controlled deployment, read-only defaults, and per-profile capability scoping is built specifically for regulated environments — not retrofitted onto a consumer AI assistant.
- **Will it force a rip-and-replace of our data infrastructure?** No. MLX connects to existing systems and creates AI-ready operating views around them. The point is not another warehouse project.
- **Are we on our own to make this work?** No. Mercury Labs embeds senior engineers with the team during deployment.

## Who MLX is for

- **Established mid-market and enterprise organisations** whose core systems were not designed for AI, but whose leaders now need AI adoption without provider lock-in.
- **Finance, operations, sales, founder, and portfolio-company teams** running recurring work that's repeatable enough to encode but specific enough that off-the-shelf tools don't fit.
- **Regulated industries** (financial services, healthcare, public sector, professional services) that need on-prem or VPC deployment and a clear data perimeter.
- **Teams that need to capture key-person knowledge** before it disappears into scattered docs, chat histories, spreadsheets, or one model provider's memory.

## Status

Design-partner deployments. MLX is engaging with companies that want to map a first owned AI workflow and build from there.

## Writing

Most recent first. Each post has a corresponding markdown rendering at `/blog/{slug}/markdown`; the full corpus is at `/llms-full.txt`.

- [CubeSandbox Lands — the Other Half of Customer-Controlled AI](https://mlx.systems/blog/cubesandbox): Two weeks ago, the open-source agent stack was missing a credible in-your-environment sandbox. With Tencent's CubeSandbox release, the gap is closed — and customer-controlled finance AI just became a much shorter procurement conversation.
- [Agentic Finance Workflows on SunSystems: A Forward-Deployed Pattern](https://mlx.systems/blog/agentic-workflows-on-sunsystems): SunSystems is exactly the kind of system where agentic finance workflows pay off — a stable, structured ledger sitting underneath brittle, swivel-chair processes. Here is the pattern we use to layer agents on top of it without breaking anything.
- [Agentic Finance Workflows on Xero: A CFO and Project-Lead Pattern](https://mlx.systems/blog/agentic-workflows-on-xero): Xero is the cloud ledger most growth-stage CFOs and project-led businesses actually run on. The pattern we use to layer agents on top — for cash, runway, and margin answers in minutes, and live budget variance across a portfolio of projects — without ever owning the keys.
- [Kimi K2.6 Lands — and Why Open-Weights Frontier Models Change the Finance AI Calculus](https://mlx.systems/blog/kimi-k2-6): An open-weights model that is competitive with the closed frontier on agentic coding is exactly the event LLM-agnostic, customer-controlled architectures were designed for. Here is what it means for finance buyers — and the honest caveats that come with it.
- [Letting an LLM Write SQL Against Your Warehouse — Safely](https://mlx.systems/blog/warehouse-sql-safety): If your agent can read the warehouse, the right question is not 'can it answer the question?' but 'what is the worst query it could run, and what stops it?' A practical model for thinking about LLM-generated SQL in finance environments.
- [What 'Customer-Controlled AI' Actually Means for Finance](https://mlx.systems/blog/customer-controlled-ai): Most AI tools ask finance leaders to give up the data, the model, and the deployment posture in one go. There is another way.
- [Skills, Not Prompts: How Forward-Deployed Engineers Codify Finance Processes](https://mlx.systems/blog/skills-not-prompts): A skill is a versioned, reviewable definition of how your team runs a recurring finance process — authored with you, not handed to you in a docs link.
- [On-Prem AI for Finance: A Practical Path for Regulated Teams](https://mlx.systems/blog/on-prem-ai-for-finance): VPC and on-prem are not exotic any more. Here is what a phased deployment actually looks like for a finance function with real residency, regulator, and audit constraints.
- [LLM-Agnostic by Design: Why Finance AI Shouldn't Be Locked to One Vendor](https://mlx.systems/blog/llm-agnostic-by-design): Routing per task — not per platform — is how you keep the cost curve, the capability curve, and the procurement story under your control.
- [Why Your Operational Reporting Is Lying to You](https://mlx.systems/blog/operational-reporting-disconnect): Ledger reality, pipeline reality, and ops reality each live in their own silo. The disconnect between them is what breaks your reporting — across finance, sales, and operations.

## Links

- Website: https://mlx.systems
- Blog: https://mlx.systems/blog
- Blog feed (RSS): https://mlx.systems/blog/rss.xml
- Full blog corpus (markdown): https://mlx.systems/llms-full.txt
- Per-post markdown: https://mlx.systems/blog/{slug}/markdown
- About: https://mlx.systems/about
- Privacy: https://mlx.systems/privacy
- Terms: https://mlx.systems/terms

## Contact

- General: team@mercurylabs.io
- Sales: team@mercurylabs.io
- Support: team@mercurylabs.io