The Forward Deployed Context Engineer Is the Next Essential Hire in Comms
The role barely exists yet. It should (and will) exist everywhere.
Erin Miller, VP of Corporate Comms at Yahoo, posted a job listing on LinkedIn last week for a “Global Communications AI Adoption Lead.” The role, as she described it, is someone who can “drive AI adoption across our global comms team, elevate data-driven storytelling, and shape how Yahoo’s narrative shows up in AI-driven discovery and emerging influence models.”
This is a real job posting for a job that almost nobody has done before. That alone is a signal worth paying attention to: one of the first times a major company's comms leadership has created a dedicated role at the intersection of AI and communications strategy.
But the more interesting thing about the posting isn’t what it says, but what it’s missing. The role Yahoo described is essentially an AI evangelist: someone who drives tool usage across the team and shapes narrative. That’s useful. It’s also not the role that will actually transform how a comms team operates.
The gap between what companies think they’re hiring for and what they actually need in order to succeed with AI tools is enormous. And getting it wrong will be expensive in ways that go beyond a bad hire.
The Role Everyone Needs and Nobody Knows How to Fill
Here’s the pattern I keep seeing. A head of comms walks into a budget review and gets the same message as every other department head: no new headcount, but we’ll fund AI initiatives. The CEO wants to hear that the comms team is leading on this. The board wants it in the quarterly update.
So the comms leader has three options, each flawed in its own way.
Option one: hire a big agency. They’ll sell you a six-figure advisory package, assign a team of eight (you’ll interact with two), and produce enough slide decks to fill a bookshelf. In four months, you’ll have a “Comms AI Transformation Roadmap” that looks great in a presentation and changes nothing about how your team actually works on a Tuesday morning.
Option two: bring in a management consultancy. McKinsey and Boston Consulting Group are standing up AI practices as fast as they can staff them. What you’ll get is a 25-year-old with a UChicago MBA running a global playbook designed for supply chain optimization and adapted for “communications” by swapping out some nouns. They don’t know your job because they’ve never done your job.
Option three: tap someone internal. Pick the most AI-curious person on your team and make them the tiger team lead. But that person is already slammed, probably doesn’t have line of sight into every workflow across the comms org, and there’s a real gap between being good with ChatGPT and knowing how to architect a system that transforms how a team operates.
What you actually need is someone who’s sufficiently savvy at comms and at building AI architecture. Not someone who uses AI tools. Someone who builds with them, who understands why a crisis response workflow needs a different context structure than a media monitoring workflow, because they’ve been in the room when the crisis hits and they know what information you’re scrambling for at midnight.
That person barely exists in the market right now. But they will, because they’re becoming essential.
The Context Problem
The reason most AI implementations in comms disappoint isn’t the technology. It’s the context, or lack thereof.
Anthropic’s engineering team published a piece last year called “Effective Context Engineering for AI Agents“ that I’d call required reading for anyone thinking about this space. The core insight: the quality of AI output isn’t determined by the prompt, but by the context—the structured information available to the model at the moment it generates a response. Get the context right and a five-word instruction outperforms a thousand-word prompt against a blank slate.
If you’re thinking “we already handle this because we’ve connected Gemini to our Google Workspace” or “our team uses Claude with Slack and Drive,” you have the beginning of a context layer. You don’t have a good one.
Connecting AI to your email, documents, and chat gives it access to your team’s explicit knowledge—the stuff that’s already been written down. That’s a fraction of what drives good comms work. How your CEO prefers to be briefed before earnings calls. Which journalists are genuinely curious about your space and which ones are fishing for a gotcha. What your CEO actually means when she says “make it tighter.” The relationship history with the reporter who just called about a story publishing in 45 minutes. That knowledge lives in your team’s heads, and when your team asks some hastily-rolled-out LLM chat product for help, none of it is available. The output is generic—Sameness as a Service—and it needs so much editing that it barely saves time.
The difference between a mildly useful AI setup and one that actually transforms how a team operates is whether someone has captured that tacit knowledge and structured it into a persistent layer the AI can draw on. That’s context engineering. And it requires someone who understands the domain deeply enough to know what’s worth capturing and how to get it.
“Forward Deployed”
This brings me to the term in the headline: the Forward Deployed Context Engineer.
The concept of a forward deployed engineer is not new. Palantir created the role in the early 2010s, calling them “Deltas”—engineers embedded directly in client operations who learn how decisions are actually made on the ground and build custom solutions around those realities rather than generic ones.1 The technical capability is table stakes. The domain-specific context is the moat.
The same logic applies to communications, and it’s why the three options I described earlier—agency, consultancy, internal enthusiast—all fall short. An agency doesn’t have the domain depth. A management consultancy doesn’t have the comms expertise. An internal AI enthusiast doesn’t have the systems architecture knowledge.
What you need is someone forward deployed in the truest sense: embedded in the comms operation, fluent in both the technology and the discipline, building context infrastructure that reflects how this specific team actually works.
What the Role Actually Does
Let me make this concrete, because “context engineering” risks becoming the same kind of terminology inflation I’ve criticized before in the AI agent space. A Forward Deployed Context Engineer in comms does three things.
The unglamorous foundation is capturing the tacit knowledge. That means interviewing senior team members to codify the frameworks they use but have never written down. It means building a relationship intelligence layer—not a media list with email addresses, but the qualitative intelligence about every journalist, analyst, and stakeholder the team interacts with that actually makes outreach effective. It means documenting editing patterns, voice standards, and crisis playbooks. All the institutional knowledge that currently lives in people’s heads and evaporates when they leave.
Then comes building the context layer. Once the knowledge is captured, it needs to be structured so AI tools can actually use it. This is where the technical fluency matters. Meeting transcripts become queryable archives. Editorial standards become automated quality checks. Stakeholder intelligence becomes contextual input for outreach drafting. Without this layer, you’re just prompting against a blank slate and wondering why the output sounds like it was written by someone who’s never worked in comms.
The real leverage comes from designing the workflows. Context without automation is a knowledge base—useful, but not transformative. The transformation happens when the context layer powers workflows that compress operational overhead2: editorial systems that enforce house style before a human editor touches the draft, crisis response tools that surface relevant history and approved positioning in minutes rather than the better part of an hour, stakeholder prep that assembles everything known about a journalist before a briefing without anyone having to ask for it.
None of this is hypothetical. I’ve built every one of these systems for my own practice.3 It’s time-intensive but life-changing, not just in terms of improved results but also the time I get back for stuff that actually needs my brain.
What This Means for You
If you’re a comms leader, the Yahoo posting should be a wake-up call. The temptation is to say “we need one of those too” and post a similar req. Before you do, ask yourself whether you’re hiring for what the role actually requires—deep comms expertise with true AI systems knowledge—or whether you’re hiring an “AI-curious comms person” and hoping they figure it out. Those are different things. The first transforms your operation. The second produces a Slack channel full of ChatGPT tips.
If you’re mid-career in comms and wondering where to invest your professional development, this is it. Not “learn to use AI tools.” That ship has sailed, and it’s table stakes. I mean learn to build with them. Understand how context layers work via MCP servers, RAG systems, content stores, and connectors. Get comfortable with the idea that your career’s most valuable skill might not be writing a perfect press release but building the system that produces consistently excellent ones. The people who develop this capability will be the most sought-after professionals in the industry within a year, because right now, almost nobody has it.
If you’re early in your career, you have an advantage your seniors don’t: you’re not unlearning anything. The people entering comms right now who treat AI fluency as a building skill rather than a productivity hack are going to leapfrog people with a decade more experience. It doesn’t require twenty years of experience, but it does require understanding what institutional knowledge actually matters and why, which means paying close attention to how the senior people around you make decisions.
The Window
The comms team that can walk into a budget review and say “we’ve implemented context-engineered workflows that increased our output capacity by 40 percent without adding headcount” just changed how the C-suite sees them. They’re no longer a cost center; they’re an operational model for everyone else.
The teams that build real context infrastructure now will have a compounding, almost-unfair advantage, because context layers get more valuable over time as they accumulate more institutional knowledge. The teams that wait will be trying to catch up to systems that have had a year’s head start absorbing how the organization actually works.
At one point, Palantir had more FDEs than traditional software engineers. That's how central the model was and how poorly "just deploy the software" worked without someone who understood the client's actual world.
And also offload the stuff people don’t want to do manually. If you want to supercharge AI adoption, start by asking team members, “What do you hate doing?” and build from there.
I recently went through the exercise of codifying my own editorial standards, voice patterns, and conceptual frameworks into structured reference documentation that my tools can draw on. More on this in a forthcoming edition. Stay tuned.