Productising research safely

The problem with making research visible

Every research institution eventually faces a version of the same tension: the work that is most valuable to share is often the work that is most dangerous to share.

This is not paranoia. It is the structural reality of building research that is designed to become product. The moment you describe *how* something works in enough detail to be genuinely useful to the outside world, you have also described it in enough detail to be replicated. And in a field moving as quickly as autonomous systems, memory, and AI-driven interfaces, replication lag is your only competitive window.

At MSG, June 2024 is a useful moment to sit with this tension directly. Benediction Lab, the research arm of the group, has been building in areas that matter for the rest of the portfolio. Some of that work is beginning to influence Orbit and Orion in ways that are ready to be discussed publicly. But "discussed publicly" does not mean the same thing as "described in full." Getting that distinction right requires a deliberate approach, not a casual one.

What makes the tension sharper here than it might be in a traditional technology company is the nature of what the Lab produces. This is not product engineering with a research veneer. The work concerns questions that are genuinely open: about how agents should manage memory across long-running tasks, about what it means for a system to understand interface state, about where the boundaries of autonomous action should sit. The fact that these are open questions in the broader field does not mean that the specific answers MSG is developing are ready to be published. Quite the opposite: when a field is moving fast, the particular set of answers you have arrived at in advance of others is precisely the thing worth protecting.

What Benediction Lab actually does

The Lab's remit is narrow by design. It does not try to be a general AI research operation. It is not producing papers for academic audiences or chasing benchmark leaderboards. The focus areas, agents, memory systems, GUI control, and autonomous product development, are chosen because they are directly load-bearing for the products MSG is building. Research that cannot eventually land somewhere useful is, for the Lab's purposes, a distraction.

This creates a tight feedback loop. Work done in the Lab eventually informs decisions made in Orbit. Patterns discovered in agent orchestration eventually become constraints or capabilities in Orion. Observations about GUI control eventually feed into how TUXX approaches custom system work for clients. The research is not separate from the product portfolio: it is the upstream of it.

But that feedback loop only functions well if the pathway from lab to product is managed deliberately. Research that moves too fast into product risks exposing architecture before it is robust. Research that moves too slowly risks becoming irrelevant, absorbed into the broader field before MSG can build a durable advantage from it.

The Lab is also not the only source of learning in the portfolio. TUXX, operating in live client environments, generates its own signal about what works and what does not at the implementation level. CheekyGains, as a consumer product, generates signal about user behaviour and expectation that is qualitatively different from what you observe in B2B environments. These streams of learning feed each other, but they do so through considered channels, not through open documentation. What the Lab discovers informs TUXX's approach to client work without TUXX necessarily understanding the full research context. What TUXX observes in client environments informs the Lab's prioritisation without that feedback loop requiring a public description of either.

What "productising safely" actually means

There is a version of this conversation that sounds like corporate IP protection: file patents, add NDAs, lock down documentation. That is not what we mean here, and it is not the right frame.

Productising research safely is less about legal protection and more about epistemic hygiene. It is about understanding what you are actually sharing when you publish something, and being intentional about the level of the stack you are making visible.

There are roughly four levels at which you can describe any piece of research work:

**Capability:** what the system can do, what outcomes it produces, what it enables for users.

**Interface:** how the capability is accessed: what inputs it accepts, what outputs it returns, how it fits into a broader workflow.

**Approach:** the broad family of techniques being used: transformer-based reasoning, retrieval-augmented patterns, structured memory, agent loops.

**Implementation:** the specific choices, configurations, schemas, prompts, training decisions, and orchestration logic that make the capability actually work at the quality level it works at.

Public conversation should generally live at the capability and interface levels, occasionally at the approach level, and almost never at the implementation level. The implementation is the moat. Everything else is signalling.

This sounds obvious until you realise how easy it is to accidentally collapse these levels when writing about your work. A single blog post that gets too specific can move from "we are building memory systems" to "here is how our memory system actually retrieves and weights context" without the author ever noticing the line was crossed. The collapse is often invisible in the moment. You are enthusiastic about what you have built, and enthusiasm tends to be specific. The antidote is not to suppress the enthusiasm but to develop a reflex for catching the level-shift before it makes it to a published page.

Public interfaces, protected implementation

The phrase that has come to anchor MSG's thinking on this is: public interfaces, protected implementation.

When Orion is described externally, the description should be accurate at the interface level. It is the intelligence layer powering Orbit. It handles memory, reasoning, context, and tool orchestration. That is true. It is useful to the people evaluating whether to work with us. It is not useful to someone trying to replicate what we are building, because it says nothing about how any of those capabilities actually work.

This is not obfuscation. It is the same distinction that exists in every mature software product between the public API and the private codebase. The API is documented. The codebase is not published. Users of the API do not need to read the source code to get value from it. Competitors cannot replicate the product by reading the API documentation alone.

Applying this same logic to research outputs means deciding, for each piece of work coming out of the Lab, what level of the stack is appropriate to surface. For most things, that is capability and interface. For some things, particularly where public engagement or credibility-building matters, it may include approach. For implementation, the default is private unless there is a specific reason to share.

There is also a temporal dimension that the four-level framework does not fully capture. Some implementation details that are genuinely proprietary today will become standard practice within eighteen months. The field moves quickly enough that staying silent about your approach often means staying silent about something that others are about to publish independently. The question worth asking is not only "is this proprietary now?" but "will it still be proprietary by the time keeping it quiet has made a material difference?" That question does not always favour disclosure, but it does calibrate the degree of protection that any particular piece of knowledge actually warrants.

The harder question: what earns a public discussion?

Not all research is the same, and not all public discussion carries the same risk.

Work that has already been substantially absorbed into the public field, retrieval augmentation, transformer attention mechanisms, agent loop patterns, can be discussed more openly because discussing it does not reveal anything proprietary. The value of that work, for MSG, is in the specific implementation decisions layered on top of public patterns, not in the patterns themselves.

Work that represents genuine differentiation, specific approaches to memory weighting, specific approaches to tool orchestration, specific approaches to GUI state understanding, warrants much more care. The test is not "has anyone else thought about this?" but "would describing this in detail allow someone to meaningfully close the gap without having done the same work?"

For Benediction Lab specifically, this means that what earns a public discussion is usually a specific outcome, a specific lesson, or a specific observation about the state of a problem space, not a technical disclosure. The Lab can write about *what it has learned* about agent memory without writing about *how its agent memory system works*. Those are different things, and the difference matters.

It is also worth noting that the most interesting public contributions from research institutions are rarely technical disclosures. They are usually framings: ways of describing a class of problem that help practitioners think more clearly about something they were already working on. That kind of intellectual contribution does not require exposing implementation. It requires thinking seriously about the shape of a problem and then articulating that shape in a way that is genuinely useful. This archive is, in part, an attempt to do exactly that.

The institutional posture

There is also a longer-term consideration that shapes how MSG thinks about this.

As the group matures, what gets documented publicly becomes part of an institutional record. Not a PR record. An actual record of intellectual development, of how thinking evolved, of what was understood when. That record has value independent of any competitive consideration. It is part of how the institution earns credibility with the people it eventually wants to work with: builders, clients, and collaborators who want to understand whether MSG's approach is coherent.

That means the archive cannot just be a careful silence. It has to contain substance. It has to demonstrate that real thinking is happening. The challenge is to do that without the documentation becoming a leak.

The working resolution is to write about problems, lessons, and frameworks rather than about implementations. The questions the Lab is trying to answer are often as interesting as the answers, and the questions can be shared without exposing the answers. What does it actually mean for an agent to remember something? What is the right boundary between automated action and human authorisation? What changes when the interface layer becomes fluid rather than fixed? These are real questions. Writing about them seriously demonstrates the intellectual quality of the work without revealing what the work has actually produced.

This is, in a sense, what distinguishes an institutional voice from a marketing voice. Marketing describes outputs and outcomes. An institutional voice describes the questions it is genuinely wrestling with, the mistakes it has made, the things it now understands that it did not understand before. That kind of honesty about the process, without disclosing the substance of the proprietary results, is the thing that builds trust over time with exactly the kind of people that matter.

Where this lands in mid-2024

The work of the past several months has clarified something that was previously more intuitive: the pathway from Benediction Lab to Orbit and Orion is real and operating, but it needs to be managed more deliberately as the portfolio grows.

That means cleaner separation between what is documented internally and what is shared externally. It means writing about research with a consistent awareness of which level of the stack is being described. It means treating the public interface as a genuine surface, one that is maintained and curated, rather than as an accidental product of whatever happens to be easy to describe.

It also means being honest about the limits of what the public record can capture. The documentation that exists here represents a considered selection from a much larger body of work. The selection is made on the basis of what can be shared without undermining the competitive position of the portfolio. That constraint is real, and it is worth naming directly rather than pretending that the public record is comprehensive.

None of this is unique to MSG. Any institution building in fast-moving technical territory faces the same set of trade-offs. What varies is how deliberately you engage with them. Organisations that do not think clearly about the four levels of description tend to drift, sometimes erring on the side of too much silence, sometimes on the side of too much disclosure, rarely finding the line that lets them demonstrate genuine intellectual substance whilst protecting what makes their work valuable.

The answer is not silence. The answer is precision.