Last year I wrote about what building enterprise AI looks like on the ground: deployment pods, QA spreadsheets, integration docs. Since then I’ve moved from building AI for customers to building it for my own company. I now lead Internal Reinvention Services at Cresta, and the biggest lesson from the switch is one I should have seen coming. The hard part of internal AI isn’t the model. It’s context.
The forward-deployed lesson I kept relearning
As a forward-deployed PM for AI agents, I spent a lot of time with healthcare and life sciences customers like TailorCare, where my colleagues at Cresta and I launched an outbound patient education AI agent program. Healthcare is unforgiving in a useful way. An agent that sounds fluent but doesn’t know a patient’s program, the care team’s escalation rules, or which questions must go to a clinician isn’t just unhelpful. It’s a liability.
Across deployments, I noticed that most of the effort wasn’t prompt engineering. It was archaeology. Where does the policy actually live? Which version of the workflow is current? Who decides what the agent is allowed to say? The model was rarely the bottleneck. The bottleneck was getting the right knowledge, from the right source, in front of the model at the right moment.
Turning the lens inward
When you start building AI for your own company, you assume it’ll be easier. You have access to everything. You know the people. There’s no procurement cycle.
It turns out internal context is just as scattered as a customer’s, and arguably more so, because nobody has ever had to organize it for an outside party. Knowledge sits in Slack threads, Linear tickets, Notion pages, Google Docs, call recordings, and, most of all, people’s heads. Every team has its own source of truth, and they don’t always agree.

I’m not alone in seeing this. At LeanData’s OpsStars 2026, a survey of 157 revenue practitioners traced stalled AI initiatives to three root causes: bad data (45%), undocumented processes (37%), and siloed teams (32%). Only one of those is about the model’s inputs in the narrow sense. The other two are about how the company itself is organized, which is exactly where internal AI has to start.
That’s the problem DeploymentOS (dOS) is meant to tackle. dOS is an internal app and MCP server that gives people and AI tools a shared, structured way to pull company context. MCP, the Model Context Protocol, is quickly becoming the standard way agents connect to tools and data. That means an investment in clean, well-scoped context pays off across every assistant someone uses, not just one.
“Context” is really five problems
I’ve been using “context” as shorthand, but it’s too broad to diagnose anything. When an internal AI answer is wrong, it usually fails in one of five places:
- Retrieval. Did the system find the right material at all?
- Context use. Finding the right document doesn’t mean the model actually uses it correctly.
- Reasoning. The retrieved policy may be accurate, yet the model still applies the wrong exception.
- Authority. Content can be visible to the retriever but off-limits to the person asking.
- Evaluation. “Better context” needs a measurable definition. That means tracking retrieval recall, answer correctness, evidence faithfulness, permission violations, abstention quality, latency, and cost separately.
Splitting it up this way changes how we build dOS. Each failure has a different fix and a different metric, and lumping them together as “context” hides which one is actually hurting you.
Three things I’ve learned so far
1. Context is a product, not a pipeline
The instinct is to treat context as plumbing: connect the sources, index everything, done. But people judge an internal AI tool by whether the answer is right, current, and traceable to a source. That means making product decisions about context: what counts as authoritative, how freshness is handled, and what gets left out on purpose. A retrieval system that returns ten mostly-right documents is worse than one that returns the single right one.
2. Permissions are a feature
In healthcare, access control is the first conversation, not the last. Internally it’s tempting to skip because “we’re all one company,” but that’s the authority failure above waiting to happen, and trust collapses fast once it does.
3. Adoption is a weekly habit
The tools that stick are the ones that visibly move. I post weekly dOS updates in Slack, pulled from Linear, and those updates have turned into a feedback loop. Someone replies “can it do X?” and that becomes next week’s work. People engage with something that’s clearly improving far more than with a one-time launch.
The forward-deployed mindset applies inside, too
The most useful thing I brought over from customer deployments is the posture: sit with the user, watch the actual workflow, and don’t trust the process doc. Internal teams deserve the same treatment as an enterprise customer. The sales engineer prepping for a call, the deployment lead onboarding a new account, the PM trying to remember why a decision was made six months ago: each has a real workflow, and AI only helps if it fits into it.
That’s also why I think “internal reinvention” is the right framing. The goal isn’t to bolt a chatbot onto the intranet. It’s to rethink how work moves when every person has an assistant that actually knows the company.
Where this goes
I’m increasingly convinced that a company’s context layer will become one of its most important internal assets. Models will keep getting better and cheaper, and most companies will have access to the same ones. What won’t become a commodity is a clean, permissioned, current map of how your company actually works. The teams that build that map now will get compounding returns from every new agent and model that comes along.
In my last post on this, I wrote that the real work of enterprise AI happens quietly, inside deployment pods and integration docs. The same is true inside the building. The next wave of internal AI won’t be won by whoever has the flashiest demo. It’ll be won by whoever does the unglamorous work of making company knowledge legible to machines and people alike.
