You Are Not the Front Door
People may bring Claude Code, Codex, Gemini, or whatever comes next to work. The company-side answer is not another chat window, but one governed interface to the business.
Right now, somewhere in your product, a team is building an agent.
It may be a copilot, a chat panel, or an “ask your data” box. It will probably ship. It may demo beautifully. It may even be genuinely useful.
But there is a harder possibility product teams need to consider: your agent can work without ever becoming the place your customer starts.
The customer may already have an agent. They chose it. It knows how they communicate, which tools they use, what they are trying to achieve, and what happened before this task began. It moves across products because the work itself moves across products.
When that customer needs something from your software, they may not open your product to speak to your agent. They may ask their agent to speak to your product.
That does not make your product irrelevant. It changes where the front door is.
The Bet That Is Actually at Risk
Embedded agents are not going away. A product that owns a narrow workflow often has the best context for helping a user complete it. An accounting agent inside an accounting product can understand the available screens, validations, and actions. A design agent inside a design tool can manipulate its native objects precisely.
The risky bet is not that these agents can be useful.
The risky bet is that every product's agent can become the user's primary interface.
A person's work rarely fits inside one application. “Why is cash lower than expected?” may cross the ledger, CRM, project system, bank, email, and a spreadsheet someone created last Tuesday. “Prepare the client review” may require commercial history, delivery status, support issues, open actions, and the latest correspondence.
An agent contained inside one product begins with deep local context and a narrow horizon. A general agent begins with the user's objective and can move between tools.
The advantage is not necessarily a better model. It is continuity.
Imagine the request begins in the notes from a customer meeting: “Work out whether we can afford the service credit they asked for, then prepare tomorrow's account review.” The relevant evidence may sit across the contract, support history, project time, CRM, ledger, and the conversation that triggered the question. An embedded agent sees its part of that chain. The user's agent can carry the objective across it.
Your Product Does Not Disappear. Its Interface Moves.
Enterprise software has long distinguished systems that hold the record from systems through which people engage with that record. Agents may move the engagement layer out of individual products more quickly than most roadmaps expect.
In that future, a customer may use your product more while visiting it less.
The ledger still has to post journals correctly. The CRM still owns opportunities. The project system still schedules work. Specialist interfaces remain essential for configuration, exception handling, review, and high-stakes changes.
But the first request may begin elsewhere:
Find the customers whose revenue is growing while delivery margin is falling, explain why, and prepare the account review.
The user's agent decomposes the objective, calls the services it is permitted to use, and returns to the user. Your product remains part of the work. It is simply no longer guaranteed to own the conversation.
This is a relocation of value, not the destruction of software.
For a software vendor, the defensive move and the enterprise's need are two sides of the same architectural bet. The vendor that exposes its product through a precise, authorised, evidence-producing capability can remain the trusted source even when it does not own the conversation. The vendor that protects only its chat box risks customers reaching the same data through exports, browser automation, shared credentials, and other less governable routes.
No single vendor can provide the whole company view. The enterprise still needs a layer that reconciles several products into one reviewed business contract. Vendor interfaces supply authoritative capabilities; the Twin governs how those capabilities and their evidence fit together.
It Does Not Require One Agent to Win
Perhaps people consolidate onto one primary agent. Perhaps they use a small set: one for coding, one for research, one supplied by their employer, and another for personal administration. Perhaps today's names, Claude Code, Codex, and Gemini, are replaced by products that do not yet exist.
The argument survives every version of that future.
In fact, uncertainty makes the architectural requirement clearer. If no company can know which agent its customers will choose, building a bespoke context layer for each agent is the wrong abstraction.
The person may bring one agent or five. The business still needs one coherent way to answer:
- Who is asking?
- Which organisation and role are they acting within?
- What are they allowed to know?
- Which definition of revenue, margin, utilisation, or risk is approved?
- Which source evidence is fresh enough to use?
- What operation is permitted?
- What proof should return with the result?
The user's agent is their interface to work. The company needs an interface to itself.
The Strongest Case for the Embedded Agent
There is an obvious objection.
The embedded agent knows the product. A general agent does not understand its data model, edge cases, permissions, or business rules. Giving a third-party agent access will produce worse answers and a larger security surface.
Today, that objection is often correct.
The usual “agent integration” hands an external system an API token, documentation, and perhaps a database schema. The agent is then expected to rediscover the company's joins, definitions, permissions, and operating rules from raw surfaces.
Each agent does that work independently. Each builds a slightly different picture. Each carries another copy of sensitive context. Each may reach a plausible but incompatible answer.
A thousand embedded copilots do not add up to one trustworthy interface. But a thousand external integrations are not the answer either.
The missing layer is not a more persuasive agent. It is a governed company-side contract.
The Twin Is the Company's Interface to Itself
A Twin sits between the company's operational systems and whichever agents or AI products it permits.
It is not a chatbot, and it is not a firehose of every table and API.
Approved connectors land organisation-scoped evidence inside the selected MLX deployment. The Twin turns that evidence into narrow, reviewed business products, such as cash position, receivables exposure, account margin, renewal risk, or delivery utilisation. Each is a definition the organisation has chosen to govern.
Each published product has a stable identity and version. It names the relation an agent may query, the fields and filters it exposes, its source freshness, its validation evidence, and the policy that constrains its use.
The agent does not invent the join whenever someone asks a question. It does not choose a convenient definition of margin from a prompt. It selects an approved product and makes a bounded request against it.
The result can identify the product, version, published relation, and freshness evidence used. Where a product preserves a source reference or explicit lineage mapping, it can support deeper drill-down. Where it does not, the interface should say so rather than manufacture a transaction-level explanation.
Do not hand an external agent your credentials and a schema. Hand it a reviewed product and a receipt.
More Than an API Gateway in a Trench Coat
An API describes operations. A semantic layer can standardise metrics. An access gateway can authenticate callers. An agent protocol can make tools discoverable.
All are useful. None, alone, answers the organisational question: what does this business fact mean, who approved that meaning, and what evidence makes this result safe to use?
The Twin combines several concerns that are usually left scattered:
- connected, organisation-scoped source evidence;
- reviewed definitions and mappings;
- stable, versioned business products;
- typed and read-only query boundaries;
- identity and capability policy;
- validation and, where defined, product-specific evaluations;
- runtime evidence showing which governed product and relation were actually used.
Governance is not decorative metadata around the interface. It is the reason an unfamiliar agent can use the interface without being given authority to reinterpret the company.
The Twin also faces the same disintermediation test as every other product. Why would someone visit a Twin application if their preferred agent can call it?
They may not.
The Twin wins by not needing to be the destination. Its human interfaces matter for connecting sources, reviewing definitions, approving changes, investigating evidence, and managing access. But its durable value is the contract that other interfaces can call.
What MLX Exposes Today
This idea is partly implemented and partly a direction. The distinction matters.
Today, MLX exposes several interfaces around the same Twin lifecycle:
- Organisation administrators use the Twin workspace to inspect what has been discovered, review proposed changes, examine source coverage, and manage publication.
- Integrated applications and coding-agent tools can use MLX's TypeScript SDK and its
sdk.twinsurface for discovery, evaluation, and governed queries with the appropriate identity and access. - MLX task agents use bound product policies plus the
twin-catalogworkflow. They query the organisation-scoped catalog first and then the published relation named by the selected manifest. - Operators and evaluation runners have separate interfaces for fleet inventory, controlled discovery, validation, and persisted evaluation evidence.
The SDK's runTwinQuery helper is a useful example of the boundary. It creates a foreground run fixed to read-only data access, the warehouse plugin, and the Twin catalog. It waits for completion and rejects a result unless the run produced catalog evidence, queried the published relation, and returned a matching structured product citation.
That is materially different from sending a prompt to a model and trusting the answer text.
Today, that structured citation is the receipt: evidence of which governed product, version, relation, and freshness answered the question. It is not proof that the resulting number is correct. Validation against trusted business figures is a separate claim with separate evidence.
There is also an important gap: MLX does not currently expose a general remote endpoint that an arbitrary Claude Code, Codex, Gemini, or other third-party agent can connect to directly. The governed query helper is a TypeScript SDK composition, not one public OpenAPI operation. The HTTP surface covers Twin lifecycle operations, but universal agent-facing transport remains product direction.
The contract exists. Making it convenient to reach from whichever agent a user chooses is the next interface problem.
Protocols Are Weather. The Contract Is Climate.
The winning transport may be an SDK, ordinary HTTP tool calls, Model Context Protocol, or a successor that has not been named yet.
That layer should be replaceable.
The durable questions are:
- Identity: Who is the caller and on whose behalf are they acting?
- Authorisation: Which organisation, products, fields, and operations may they access?
- Meaning: Which reviewed version of the business definition applies?
- Evidence: Which product and relation produced the result, and how fresh was it?
- Accountability: Which request, tool calls, approvals, and outcomes can be inspected later?
Agent-agnostic does not mean anonymous access. LLM-agnostic does not mean model behaviour is interchangeable. It means these controls belong to the company-side contract rather than to the habits of one model, one chat product, or one protocol.
If the calling agent changes, the business should not have to redefine revenue.
Reading and Acting Are Different Promises
The safest first interface is read-only.
MLX's governed Twin query path currently requests only read-only data capability. It is designed to answer through an approved published product, not to grant a visiting agent a general ability to modify source systems.
That boundary should remain explicit as agent interfaces expand.
Reading “Which invoices are overdue?” and acting “Send every customer a reminder” carry different authority, failure modes, and consequences. Write-capable tools require separate connector support, narrower authorisation, validation, previews where appropriate, human approval for consequential changes, idempotency, and durable receipts.
An agent-facing interface should not turn “can understand the business” into “can operate the business” by implication.
Build for the Agent That Is Not Yours
The product strategy question is no longer only:
How do we add an agent to our software?
It is also:
How does our software become safely useful to an agent we did not build, running a model we did not choose, through an interface that may not exist yet?
That changes what a durable product surface looks like.
It rewards stable contracts over prompt tricks. It makes identity and evidence part of the user experience. It raises the value of precise business meaning while lowering the value of owning one more empty chat box. It lets specialist products remain excellent at being systems of record and systems of action without requiring each one to become the operating system for a person's work.
Your user may already have picked their agent. The open question is whether your company has built an interface to itself.
Do not fight only to be the last chat window.
Become the safest, clearest way for whichever agents people choose to understand the business, with every answer carrying checkable evidence of which approved product, version, relation, and freshness produced it.
The Twin is not the front door. It is the map, the guard, and the receipt.
Next: Your AI Doesn't Need More Context. It Needs Approved Meaning.. Why access to more evidence cannot settle disputed business meaning.
Related: LLM-Agnostic by Design. Why the business product and evaluation contract need to remain stable when the model route changes.
Architecture: Letting an LLM Write SQL Against Your Warehouse Safely. The difference between a governed Twin query and bounded exploratory SQL.
Frequently asked
- Does this mean product-specific agents will disappear?
- No. Embedded agents can be excellent at narrow workflows where the product already owns the context and action surface. The weaker bet is that every embedded copilot will become the user's main interface across all their work.
- Can any external agent connect directly to an MLX Twin today?
- Not yet. MLX currently exposes typed Twin lifecycle methods and a governed query helper through its TypeScript SDK, while MLX task agents use the Twin catalog internally. A general remote endpoint for arbitrary third-party agents is a product direction, not a shipped claim.
- Is a Twin just an API or semantic layer?
- An API exposes operations and a semantic layer can standardise measures. A Twin adds reviewed, versioned business products, scoped access, validation evidence, runtime policy, and checkable citations so an agent does not have to reinterpret the business on every request.