The two hottest new roles in the bay are the Forward Deployed AI Engineer and AI Product Manager. We think they shouldn’t exist.

Okay, that’s a bit hyperbolic. But the best approach to implement AI applications is shifting from ad-hoc context engineering to productized context platforms.

These roles were created to address a real need: closing the gap between AI’s capabilities in the lab versus the real world. We recently wrote about how context, not intelligence, is the limiting factor to making AI work in enterprise. Most of the work FDAIEs and AIPMs do is gathering context from their customers to manually update system prompts and evals. 

This approach works, but it’s slow, labor-intensive, and non-scalable. As AI promises to automate every aspect of work, why is its implementation so manual?  

It doesn’t have to be this way: context creation and implementation will become more productized as part of a core platform, instead of a post-sales service.

Context Engineering → Context Platforms

As we wrote previously, emerging context platforms we see all share three core capabilities:

• Automate context creation (via screen recordings, historical queries, email threads, tickets, existing documents, etc.)
• Deliver the right context human and/or AI workers need to complete a task
• Empower human and/or AI workers to maintain and improve context over time

Let’s compare them to today’s context engineering:

‍

Products built around context platforms will be faster and cheaper to deploy. They’ll do tasks more reliably because context is more easily kept up to date. 

And critically, they will allow customers to own and manage their operational processes: creating a valuable data asset/intellectual property, as opposed to ceding control and information to their vendors.

Forward-deployed resources will still be critical, but will spend most of their time on things like integrations, edge case handling, and change management; not writing and tweaking prompts. 

Meanwhile, as most business jobs shift from doing work to managing AI agents, these context platforms will become key systems of record and operational tools to manage agent behavior.

Where Are the Best Places to Build Context Platforms?

Context will be a critical part of any enterprise AI application. But there are some areas where it will just be a component of vertical platforms, versus others where the context platform is the dominant feature and might even be a standalone company.

In spaces like cybersecurity, there is a ton of sophisticated domain knowledge required to do the job successfully: writing complex queries, reasoning about attack paths, etc. Much of this knowledge is universal – phishing attacks and cloud misconfigurations look similar anywhere. Customer-specific context is still very useful, but the most important thing is having the latest security expertise. These functions will best be served by sophisticated vertical applications like Maze and Dropzone, which build features for customer context.

In other functions, company-specific context massively outweighs general domain knowledge. Consider procurement or customer support. Individual tasks might be simpler, like looking up data in one system and entering it in another. But knowing what to do entirely depends on how your organization operates and makes decisions. In these domains, getting AI to work requires huge amounts of context gathering, and the context platform will actually be the most important feature driving product value and scalability. 

Two areas where we think context platforms will be critical are:

Operations: Ops are extremely complex and variable, requiring coordination across every function in the business. Processes are documented in scattered SOPs, past conversations, and tribal knowledge. Outside of basic project management and brittle RPA tools, ops leaders have no core software platform where they can view or manage how their operations are executed. We wrote about this opportunity extensively in our Business Context Layer article. 

‍EPD: A huge amount of context and history underlie every product and engineering decision. Today’s PRDs are not sufficient to direct coding agents: they might understand the desired features and general best practices, but won’t have the background context on priorities, tradeoffs, and historical decisions that inform the right way to build them. It’s possible that context is a byproduct of coding agents, but we think there is an opportunity to build a context platform across engineering, product, design, and customer teams.

It’s clear that productizing context will be a key unlock for deploying the next generation of AI applications.

If you’re building context platforms for enterprise, or AI applications where context is a core component of your product, I’d love to hear from you: at@theoryvc.com.