TL;DR: Engineers and their coding agents write code that misses the customer's reality because the business context sits in one person's head, the FDE's. The fix is making account context queryable instead of couriered. At Aircall, engineers query rollout context (commitments, porting dates, integration decisions) through Claude via MCP, and the team now runs 3x rollouts per engineer (5 → 15). The stakes are measurable: 30% of developers report little or no trust in AI-generated code, and context quality is the biggest lever you control.
Your engineers are good. Their coding agents are fast. The code still comes back wrong, because "wrong" for a forward deployed engineer rarely means broken. It means technically correct and commercially off. The integration handles the API version the customer abandoned last quarter. The edge case the buyer flagged at kickoff never made it into the spec. The feature ships a week after the date sales promised, and nobody on the engineering side knew a date had been promised at all.
None of that lives in the codebase. It lives in call transcripts, Slack threads, and the FDE's memory. An FDE at a vertical AI startup put it plainly: "the engineers don't have the same context as I do […] I'm basically functioning as a product manager." We hear a version of that sentence from most FDE teams we talk to.
This article is about that gap: why it exists, why coding agents widened it, and how teams close it by letting engineers and agents query the account's memory directly instead of queuing for the FDE. It's one slice of the shared context problem for FDE teams, seen from the engineering side.
How did the FDE become the team's product manager?
Nobody assigns the role. It accretes. The FDE sat in the discovery calls, walked the customer's workflow, and heard the offhand remark about the legacy system that silently drops a field. Engineers back at HQ heard none of it. So every piece of work that crosses from customer to codebase has to pass through the one person who holds the picture, and that person becomes a translation layer with a backlog.
The courier work: tickets, evidence, interpretation
The courier work has a familiar shape. Writing Linear or Jira tickets with enough background that someone can act on them without a call. Pulling recordings and logs to turn "the claims team says it feels slow" into a reproducible case. Explaining why the deadline is the deadline. Then answering the same clarifying questions on the ticket, again on the PR, and again at QA.
The same FDE has tried to automate the packaging step: "dump it to an agent […] turn this into all into, like, a packaged […] But that has not happened yet." The raw material exists in transcripts and notes. The pipeline from the FDE's head to the engineer's editor doesn't.
The relay problem
An FDE at an industrial-AI company described the other half of the courier job, the status loop. The customer asks the CSM, the CSM asks the FDE, the FDE asks the engineer, and the answer walks the same chain back. Every hop loses accuracy and burns hours. It's the same context tax that implementation teams pay, collected from engineers instead of project managers.
Why do coding agents make missing context worse?
Coding agents moved the bottleneck. Writing code got fast. Knowing what to write didn't. The 2025 DORA report's summary line is that AI "amplifies what's already there", and that amplification cuts both ways. Feed an agent a clean spec that carries the customer's constraints and it produces useful code in minutes. Feed it a ticket reconstructed from memory and it produces plausible code that is confidently wrong about the business. That's a big part of why 30% of developers still report little or no trust in AI-generated code.
The pattern shows up at the company level too. An MIT-affiliated study found about 95% of enterprise AI pilots produce no measurable P&L impact, and its explanation is that generic tools stall because they "don't learn from or adapt to workflows". A coding agent with no access to what was promised, decided, or put at risk on an account is a generic tool, however strong the model behind it.
For FDE work there's a sharper twist: domain nuance is the business logic. Whether the porting cutover happens before or after the pilot group goes live isn't color, it's a branch in the code. Strip the nuance and you haven't simplified the ticket, you've deleted the requirement.
What context do engineers actually need?
Not the CRM. Not the full call archive. Engineers and their agents need the account's answers to the four questions that define shared context: what was promised, what was decided, what's at risk, and what's next.
Each maps to a concrete engineering need. What was promised is the spec and the date. What was decided is the reasoning that stops an agent from refactoring away a deliberate choice, like why this customer got webhooks instead of polling. What's at risk tells the engineer which corner of the build is load-bearing this week. What's next settles sequencing without a meeting.
They also need it at the moment of writing code, in the terminal. A wiki page an engineer might read before sprint planning is not the same as an answer the coding agent can pull mid-session. Note that Claude Code's own memory doesn't cover this: project CLAUDE.md is for repo conventions and travels via git, while auto memory stays on one machine. Account state has no home there by design.
Where do engineers get context today?
Most teams run some mix of four channels. Here's what each actually delivers.
- Spreadsheets + Slack. What the engineer gets: status cells and thread archaeology, freshness varies by team. What the coding agent gets: nothing it can query. Cost to the FDE: repeating answers that were already written somewhere, unquantified.
- Tickets (Linear, Jira). What the engineer gets: what to build, rarely why. What the coding agent gets: the ticket text, minus the background that didn't fit. Cost to the FDE: slow, careful writing per ticket, then clarifying rounds anyway.
- The FDE's head. What the engineer gets: good answers, queue permitting. What the coding agent gets: nothing. Cost to the FDE: every interruption, in both directions.
- A shared account memory. What the engineer gets: promises, decisions, and risks with sources. What the coding agent gets: the same answers, queryable mid-session. Cost to the FDE: curating instead of couriering.
The first three aren't wrong, they're just personal or partial. The ticket holds the what. Slack holds fragments of the why. The FDE holds the reconciliation of both, and the FDE doesn't scale.
What does couriering context actually cost?
Every "quick question" has a hidden multiplier. Interruption research puts the cost of getting back on task at an average of 23 minutes and 15 seconds, and the courier model generates interruptions in both directions: the engineer blocked waiting on the FDE, the FDE pulled out of a customer build to answer a status ping.
Then there's the compounding cost of code built on wrong assumptions. Stripe's 2018 developer research found the average developer already spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring. Code that was correct against a stale ticket and wrong against the customer's reality lands straight in that bucket, usually discovered on a customer call where the discovery is most expensive.
How do you let engineers and agents query the context directly?
The alternative to couriering is a queryable team memory that engineers and coding agents read from and write to. Here's the shape of it.
- Capture the account's reality in one place. Calls, Slack decisions, commitments, and risks flow into a project brain rather than into one person's notes. In Tandem's account brain you maintain it through an AI chat interface, so corrections are a message, not a gardening session.
- Connect it to the terminal. MCP is an open standard for connecting AI applications to external systems, supported by Claude, ChatGPT, VS Code, and Cursor. Tandem MCP puts the brain on the other end of that port, reachable from Claude, Claude Code, or ChatGPT. The full setup is in querying account context from Claude Code via MCP.
- Have the agent read before it writes. Before touching the integration, the engineer (or the agent itself) asks what was promised on this rollout, what was decided about the architecture, and what's currently at risk. The answers come back with sources, so a skeptical engineer can check the transcript.
- Push decisions back when the session ends. Real product decisions now happen inside coding sessions, and they die there unless someone moves them. You choose what syncs from a session into team memory, and nothing moves without you triggering it. The workflow is covered in getting product decisions out of Claude Code sessions.
- Move the FDE from courier to curator. The FDE reviews what flowed in, corrects what's off, and spends the reclaimed hours on discovery and building. Curation is minutes a week. Couriering was hours a day.
This is what Aircall runs. Engineers query rollout context (commitments, porting dates, integration decisions) through Claude via MCP. Paul Yi, a senior software engineer there, describes the effect: "I ask 'what's blocking the cutover' in Claude and get the actual answer, with sources. Same question, same answer, whoever asks." The same channel feeds the FDE-to-product feedback loop, because field learnings reach product without playing broken telephone. It's the core of how Tandem supports FDE teams.
What stays manual
Honesty matters here, because this pattern removes the relay, not the role.
The FDE still runs discovery and still builds. Sitting with the customer is the job, and no memory layer replaces it. Judgment doesn't transfer either: two engineers with identical context can still make different calls, and the senior one's call is still better.
You trigger the sync from a coding session yourself, and you choose what's worth keeping. Automatic re-sync at every checkpoint is a request we hear and haven't shipped. And any action a Tandem agent proposes on an account, a message, an update, a flag, goes through human approval before it touches a customer.
Finally, wrong facts need a human to correct them. Sources make errors findable in seconds, but a person still decides what the truth is.
From courier to curator
The outcome to aim for isn't engineers who know everything. It's engineers and agents who can get the sourced answer in the seconds before they need it, an FDE who curates a memory instead of retyping it, and code that's right about the business the first time. Aircall's version of that outcome is 3x rollouts per engineer with the same team.
See what your engineers would get back. Book a demo and watch Tandem answer "what's blocking the rollout" on one of your live accounts, with sources.
FAQs
Can a coding agent actually use business context?
Yes, when the context is delivered where the agent works. Through Tandem MCP, an agent queries commitments, decisions, and risks the same way it reads the codebase, before it writes a line. Aircall's engineers run this in Claude today, and the business result is 3x rollouts per engineer.
How is this different from writing better tickets?
A ticket is a snapshot written by the FDE at one moment, and accounts change weekly. A queryable memory is current at read time, answers the follow-up questions a ticket never anticipates, and doesn't cost the FDE an hour per issue. Better tickets help. They don't remove the courier.
What if the shared context is wrong?
Every fact carries its source, so an engineer can open the transcript or thread and check in seconds. Corrections happen through the chat interface and are visible to everyone afterward. The honest caveat: a human still owns deciding what's true, and that ownership doesn't disappear with any tool.
Does this replace conversations between FDEs and engineers?
No, it replaces the status and background relay. Design discussions, tradeoff calls, and "is this actually a good idea" conversations still happen between people, and they get better when nobody spends the first twenty minutes reconstructing account state.
We're two people. Do we need this?
Maybe not yet. A solo FDE sitting next to their one engineer can courier context across the desk. The gap opens with the second account, the second engineer, or the first coding agent that works while you're on a call, which is usually sooner than teams expect.
Key terms
Forward deployed engineer (FDE): A forward deployed engineer is an engineer who spends roughly half their time with customers understanding the problem and half building the solution for that specific customer.
Shared context: The account's memory that a whole team and its AI agents can query, answering what was promised, what was decided, what's at risk, and what's next, with sources.
Project brain: The category artifact that holds shared context, a maintained, source-linked store of account facts rather than a folder of documents.
Account brain: Tandem's product part, a project brain plus risk detection, Tandem agents (with human approval on actions), and a customer workspace.
Coding agent: An AI system that writes and edits code with limited supervision, such as Claude Code. It amplifies the quality of the context it's given, in both directions.
MCP (Model Context Protocol): An open standard for connecting AI applications to external systems, supported by Claude, ChatGPT, VS Code, and Cursor. Tandem's server is called Tandem MCP.