The Agent Is the Easy Part

The easiest part of an enterprise AI strategy is becoming the part that receives the most attention.

Choose a model. Choose an agent framework. Add a chat surface. Connect some tools. Run a polished demonstration in which the agent finds a number, explains a variance, and drafts the next action.

None of that is trivial. It is simply getting easier to buy.

The model can be rented. The agent loop can be assembled from an SDK. Tool calling is becoming a standard capability. Protocols are emerging for connecting agents to services and to each other. A new interface can be added without changing the systems that hold the underlying records.

The difficult part starts when someone asks what the number actually means.

Which revenue definition did the agent use? Was the customer active according to finance, sales, or delivery? Which organisation did the request belong to? Was the source fresh enough? Who approved the mapping? What changed since the same question was asked last quarter? What evidence would let a controller rely on the answer?

No model vendor can answer those questions for you.

That is why the agent is the easy part. Company context is the product.

What Everyone Can Rent

Frontier models remain extraordinary pieces of engineering. They will keep improving, and differences between them will continue to matter for particular tasks.

But access to a capable model is not scarce. Your competitors can use the same provider, the same API, and often the same agent framework. They can adopt the same protocol and install the same tools. If one model becomes too expensive, too slow, or less capable for a workload, another can take its place.

An asset that every competitor can rent may be essential infrastructure. It is not, by itself, a durable advantage.

The same applies to the visible agent. A well-designed agent can create a much better experience than a blank chat box, but its outer form is increasingly portable. It can live in Slack, a web application, an IDE, a command line, or another agent. The interface may be where the work begins without being where the enduring value lives.

OpenAI's account of its own internal data agent makes this separation unusually clear. The agent is available through Slack, a web interface, IDEs, the Codex CLI, and an internal ChatGPT application. Different entry points reach the same body of data knowledge and company context. The valuable system is not one of those chat surfaces. It is the context and control layer behind all of them. OpenAI describes the architecture here.

That pattern will not be unique to OpenAI. When employees bring different agents to work, the company cannot afford to rebuild its meaning inside each one.

What Nobody Can Bring With Them

A model vendor can bring general intelligence. A connector vendor can bring access to an application. A data platform can bring storage and compute.

None of them can arrive knowing that:

• recognised revenue excludes a particular class of pass-through cost;
• an active customer must have both a live contract and delivery in the reporting period;
• utilisation is measured against contracted capacity rather than nominal headcount;
• one legal entity closes on a different calendar;
• a project code changed meaning after an acquisition;
• the board definition of pipeline differs from the operational sales definition.

Those facts are not hidden in the model weights. They are not reliably recoverable from a schema. They may not even be written down in one place.

They are agreements the organisation has made, sometimes explicitly and sometimes through years of operating practice. They have owners. They change. They conflict. They apply within particular scopes and periods.

That is the context a company actually owns.

It is also the context that determines whether an agent is useful. A weak model with the right approved definition can produce a modest but defensible answer. A brilliant model using the wrong definition can produce a persuasive mistake.

The Agent Is Often the Fun Part

This imbalance helps explain why enterprise agent projects can look advanced while remaining fragile.

The agent is visible. People can watch it reason, call a tool, and produce a result. Progress is easy to demonstrate.

Company context is slower. Someone must identify the real source, resolve the join, define the grain, separate exceptions from rules, decide which measure is authoritative, and ask an accountable owner to approve it.

The work can feel like plumbing, data modelling, and governance because that is what much of it is. It is the work required to make intelligence accountable to a real organisation.

Research from LinkedIn offers a useful corrective to the idea that a capable model and enough metadata settle the problem. Its enterprise Text-to-SQL system combined a knowledge graph with database metadata, historical queries, wikis, code, retrieval, ranking, and automatic correction. On an internal benchmark, expert reviewers judged 53 percent of responses correct or close to correct. That is a meaningful system and a meaningful result. It is not a solved problem. Read the LinkedIn paper.

The lesson is not that agents cannot answer questions about enterprise data. They can.

The lesson is that the agent loop is only one component of the answer. The quality of the company context, and the controls around how it is used, become more important as the underlying estate grows.

Context Has to Become a Product

Most organisations already possess fragments of useful context:

• transformation code in a warehouse;
• metric definitions in a BI tool;
• source mappings in spreadsheets;
• process notes in a wiki;
• permissions in several applications;
• exceptions remembered by experienced employees;
• prompts copied between agent projects.

The problem is not total absence. It is the lack of one governed lifecycle.

If context is going to serve many agents, it needs to behave like a product:

1. It has an accountable owner. Someone can approve what the definition means and reject a plausible alternative.
2. It has a stable identity and version. A later change does not silently rewrite the meaning used by an earlier answer.
3. It has a declared boundary. Fields, filters, organisations, and operations are explicit rather than inferred at runtime.
4. It has validation evidence. Publication depends on more than syntactically valid SQL or a fluent description.
5. It can be evaluated. Supported questions can be tested against the exact published version.
6. It produces evidence when used. The answer can identify which product and relation were actually queried.

This is the role of a Twin in MLX.

Connectors land organisation-scoped evidence. Discovery operates in automatic, guided, or explicit mode and records diagnostics rather than silently promoting guesses. Deterministic proposals are reviewed by a human. Publication creates a stable mlx_curated relation, a versioned contract, a generated policy skill and routing snapshot, validation evidence, and an optional evaluation suite. Activation and evaluation remain separate decisions.

The result is not a larger prompt. It is a governed company context product that more than one prompt, model, or interface can use.

One Product, Several Agents

Once company context has a stable contract, the agent becomes easier to replace.

One team may reach it through an MLX task agent. An application may use the typed sdk.twin namespace. An organisation administrator may work in the Twin review surface. An evaluation runner may test a published product without any human conversation at all.

These interfaces have different ergonomics because they serve different roles. They can still agree on the product identity, version, organisation scope, capability policy, and evidence requirements.

That separation is commercially important.

If the definition of account margin lives inside one agent's prompt, changing the agent risks changing the definition. If the definition lives in the Twin, the organisation can change the model or interface while keeping the business contract stable.

This is the useful form of agent and model agnosticism. It is not a promise that every model behaves identically. It is a decision about which layer is allowed to own company meaning.

The model may be requested and executed under a particular provider identity. The resulting run can record which model actually executed. But model identity does not become product identity. The approved account-margin product remains the approved account-margin product.

The Context Layer Is Not a Moat If the Customer Cannot Leave

There is an obvious objection.

If a vendor convinces a company to encode its definitions, processes, and mappings in a proprietary layer, has it merely created a deeper form of lock-in?

It can.

The answer is not to leave business meaning scattered across prompts. It is to make the important artefacts inspectable and separable:

• the product contract can be reviewed;
• the published relation has a stable database identity;
• model routing remains a separate concern;
• task skills do not own the definition;
• validation and evaluation evidence can be examined;
• the invocation can return a structured product citation.

The durable asset should be the customer's governed meaning, not the vendor's preferred model or chat surface.

That is also why a Twin should not attempt to replace every source system. The ledger still owns postings. The CRM still owns opportunities. The project platform still owns delivery records. The Twin governs the cross-system product an agent is permitted to use.

What This Does Not Prove

Turning context into a product does not make every source complete, every mapping correct, or every answer true.

A published product can show which definition was approved and which relation should be queried. Validation can establish a specific set of claims. An evaluation can test supported questions. A structured citation can prove that the governed product and relation were used.

Those are meaningful proofs, and they have boundaries.

Product-level citation does not automatically provide transaction-level lineage for every aggregate. That deeper trace exists only where source references or an explicit lineage mapping have been preserved. A certificate that records execution does not prove that a source system contained the right fact.

MLX also does not currently expose a generally available remote endpoint that any arbitrary third-party agent can call. The TypeScript SDK and first-party governed paths exist today. A safe external surface remains product direction.

The honest claim is not that the context layer solves truth.

It makes company meaning owned, bounded, versioned, testable, and inspectable. It gives whichever agent arrives next something better than a schema and a hopeful prompt.

Where Value Moves

As models improve, some forms of intelligence become cheaper. As protocols spread, some forms of integration become easier. As agents converge, some interfaces become interchangeable.

Value does not disappear. It moves.

It moves toward the part no external model can infer and no generic agent can own: the organisation's explicit agreement about what its business means, who may use that meaning, and what evidence must accompany the result.

The agent is still important. It may be the place where the user begins, and it may do extraordinary work.

But the company context is the product that survives when the agent changes.

---

Previous: A Connector Is Not Context. Why access to source evidence is a prerequisite for approved meaning, not a substitute for it.

Next: Your Agent Remembers You. Who Remembers the Company?. Why personal continuity and institutional memory require different architectures.