AiThority Interview with Richard Yu, Chief Product Officer, LucidLink

Richard Yu, Chief Product Officer, LucidLink specifies why a poor understanding of the fundamentals behind MCP servers can impact sensitive enterprise data, in this Q&A with AiThority:

_________

Hi Rich, tell us about LucidLink’s recent AI enhancements and MCP capabilities?

Most organizations think they have a data problem, but it’s usually it’s an access problem. The data exists. It’s spread across cloud platforms, storage systems, applications and teams, and over the years their people learned to work around that. They know which drive, which bucket, who to ask, what to copy where. An agent doesn’t know any of it.

In June, we released the LucidLink MCP Server in public beta, along with a Python SDK and working examples for about a dozen agent frameworks. An agent connects to a filespace and can read, write, search, lock, and audit files, under the same permissions as the person it’s working for.

The part that matters more than the protocol is what sits underneath it. We stream file data on demand, so what the agent gets back is a path, not the file. The common approach is to return file contents through an API, which means a size limit and truncation above it. We don’t return the file, so there’s no limit. A four-kilobyte text file and a 200-gigabyte camera original are the same kind of object to us.

What do AI users get wrong in their understanding of MCP servers?

The one I hear most is that once you’ve connected everything through MCP, your agent has context. Teams connect storage, the ticketing system, the wiki, watch an agent pull correctly from all three, and consider it handled. What they’ve given it is reach. That’s the easy half. MCP is a connection protocol, and it has no memory. Between two tool calls, nothing persists unless something underneath is persisting it. As soon as you have two agents, or one agent across two sessions, or an agent handing work to a person for review, you need somewhere durable for the in-progress work to live, and MCP doesn’t specify one.

The second one is more technical, and it usually surfaces late in a project. Where the agents run determines what they can reach. Coding agents and desktop clients run on your machine, so the server can run locally against local credentials. Cloud-executed agents can’t do that. They need a public endpoint, which means decrypted content sitting on infrastructure the cloud agent vendor hosts. This presents a security posture decision and one not readily acceptable for sensitive enterprise data.

What are the fundamentals of a good data layer that most business heads forget or tend to dismiss often?

The one that gets skipped is coordination. People can handle this with intelligence. You tell someone you have a file open, you see their cursor in the document, you ask before you change something. Agents have none of that. Point three of them at the same dataset and they’ll overwrite each other. What they need are basic features that file systems have had for decades: locks, claims, leases that release when the process holding them dies, and an audit trail that records who changed what. None of it is new engineering. It’s just usually not there.

The rest is more familiar. Make data usable where it already sits, because every copy you create for an AI project is another silo and another permission model to keep in sync. Let permissions travel with the data, so an agent inherits the boundaries of whoever it’s acting for and revoking access actually removes access. And give agents somewhere to write. That last one is where I see the most confusion. Retrieval gives an agent context. It doesn’t give the agent anywhere to store the result. Most of the value in a multi-step workflow is in the intermediate output, and if that output isn’t durable and reviewable, every session starts over.

As MCPs and agentic workflows gain momentum in terms of usage and adoption, what precautionary measures would you share?

I’d skip the standard advice about not leaving governance until later. Everyone says it and it doesn’t change what anyone does.

The thing I’d look at first is accountability. Most agent deployments act through a service account, so your audit trail will tell you the service account did it. That’s accurate and it isn’t useful. It won’t tell you whose intent the action served, which agent in a swarm of three initiated it, or who is answerable for the result. Before you point an agent at production data, try answering these questions using the logging you have now. Most teams can’t. Identity and delegation for agents isn’t solved anywhere in the industry yet, and it’s better to know that going in.

The second is what your stack is retaining. Teams persist conversation state and cached context for performance reasons, which is reasonable. What they’ve also created is a partially reconstructable copy of everything they’ve sent to a model, in infrastructure nobody classified, with no retention policy and no owner. If the source data is governed and the derivative copy isn’t, the governance isn’t doing much.

Both point the same direction. Run AI on the access controls you already operate rather than building a parallel set for every initiative, and start with read-only and limited scope.

Also Read: AiThority Interview with Gou Rao, co-founder and CEO at NeuBird AI

A few thoughts on where AI is headed?

Models are converging. They get better every year, and the one you use in two years probably isn’t the one you use now. That’s good for buyers, and it changes what’s worth investing in. The model is what you rent. The context is what you own.

Your proprietary material, your working state, the accumulated output of agents doing your work in your domain. That’s the durable part. It’s also what you give away when every AI project starts by copying data into someone else’s platform. I’d ask any AI vendor two questions: do you keep my data, and can you read it? We built LucidLink so the answer to the second one is no. On our filespaces, content is encrypted on the client, and we can’t read our customers’ files. That’s a property of our architecture, not a commitment in a contract.

Some of this is familiar. During the pandemic, remote work exposed a data access gap in IT infrastructure that had been there for years, hidden under corporate high-speed LANs. The need for AI and agents to access data is exposing the same issue differently.

One thing did surprise us. The clearest demand for us isn’t coming from where the AI conversation is loudest. It’s engineering and technical teams with large and valuable datasets, who hit the access

problem first. Several of them came to us with an architecture already worked out and asked us to help. We didn’t pitch it.

Five AI innovators you’d shout out to in this conversation before we wrap up?

I’ll skip the obvious names and pick work we build against.

Anthropic, for publishing MCP as an open specification rather than a proprietary integration. They didn’t have to, but we are grateful that they did.

Harrison Chase and the LangChain team. Our LangGraph checkpointer passes their official interface tests, which means those interfaces were written by people who expected other implementations to exist.

Samuel Colvin and the Pydantic team, for insisting that agent output should be typed and validated. A lot of what gets described as agent reliability is that.

The people working on open weights. Being able to run capable inference next to your own data, instead of sending the data out, changes what an enterprise can consider.

And our own LucidLink team. They keep building things on the filespace that we didn’t design it for, including distributed CI with no CI server. That’s a better roadmap than a slide deck.

Also Read: ​​AI and The Future of Work: Artificial Intelligence Is Expanding Organizational Intelligence Beyond Human Limits

[To share your insights with us, please write to psen@itechseries.com]