How We Built the Context Engineering Layer

Foundation Capital made the argument cleanly a while back. The models themselves are commoditizing, so the durable advantage moves to whoever captures how an organization actually makes its decisions, the reasoning that never makes it into a system of record. They call the structure that holds it a context graph. It's the right diagnosis, and it isn't only a revenue idea, it's an everywhere idea.

I agree with it. I'd push one step further, because the interesting question isn't whether that knowledge is valuable. It's where it has to live. For revenue specifically, the answer is a layer we built, and it sits in a place most teams aim at by mistake.

Most teams read "the model is commoditizing" and conclude they should build a smarter agent. That's the wrong layer.

Execution is cheap now. Judgment isn't.

Think about a frontier model as a world-class contractor. It can build almost anything you describe, fast, to spec. The bottleneck was never whether the contractor is skilled. It's the blueprint you hand them: this building, this site, this code, what the last three jobs on this block taught you.

Everyone is now handing the same skilled contractor the same generic blueprint. So everyone gets the same generic building.

In revenue terms: an agent can draft a follow-up, summarize a call, or write a business case in seconds. That work is commoditized. The part that still decides whether a deal closes is the judgment behind it. Which stakeholder to multi-thread into, the week the renewal clock starts mattering, the objection that looks like pricing but is really about the security review nobody has scheduled yet. That judgment is the tacit knowledge top reps can't quite put into words, and it's the one part of selling that compounds instead of commoditizing.

That judgment is the blueprint. And it can't sit inside the contractor.

Why the agent is the wrong place to keep it

There are two standard ways to build this, and both put the intelligence in the wrong place.

The first is a set of workflow agents. A research agent, an outbound agent, a meeting-prep agent, a follow-up agent, strung together with integrations and called a platform. The problem is that these agents are stateless. They run, return an output, and forget. They never build a continuous understanding of the deal, and they can't compare what's working across deals because they don't persist long enough to see a pattern.

The second is a per-deal agent: one agent assigned to each deal, holding state across its lifecycle. Better, but it creates thousands of isolated agents, each learning locally, none of them sharing what works. One rep softening one email is a preference. Twenty reps doing it across forty deals is a pattern. A per-deal agent can't tell the difference, because it only ever sees its one deal.

The most useful thing an agent can do for a revenue team isn't drafting. It's answering one question: what actually works in situations like this? That question is comparative by nature. You can't answer it from inside a single workflow or a single deal.

So we stopped trying to make the agent smarter and built the layer the agent calls. The result is the thing the standard playbook never gets to: one agent that holds every deal in your pipeline at once and actually understands them, because the understanding doesn't live in the agent. It lives in the layer underneath, and any agent that calls it inherits the whole org's judgment in a single request.

Loop: the context layer underneath every agent

Loop sits below whatever agent you run. It ingests the full context across a GTM org, calls, emails, Slack, CRM, documents, and turns it into context an agent can actually reason with, then serves that context through MCP to whatever model is doing the work. Loop is the MCP: the protocol routes the request, Loop generates the context it routes. This is what context engineering actually means: not a longer prompt, but a built layer that decides what an agent knows before it acts.

Three pieces of engineering make that real.

Pre-Materialized Context. When an agent asks "what should I do next on this deal," the naive version fires three to five tool calls to assemble the picture: pull CRM, pull the transcript, pull the Slack thread, pull comparable deals, every single time. Loop pre-computes that context and holds it ready before the agent asks, enriched with the patterns our ML has already derived. One Loop call replaces the three-to-five-call scramble. That cuts token spend by about 30 percent, and because the context is already judgment-enriched, the agent is faster and smarter at the same time. This is not prompt caching. Cached prompts are still raw context. Pre-materialized context carries the labels.

Routing across models, not one model for everything. Synthesizing a multi-threaded deal history needs depth. A quick internal update needs speed. Scoring patterns across hundreds of deals needs scale, and that is a math problem, not a language problem, so it runs on private org-scoped small models rather than a frontier LLM. Loop picks the right model for each job and runs the pattern work on weights that stay yours. You get one experience. Underneath, it's the right tool per task.

Cross-org pattern recognition. This is where the layer beats any single agent. Loop builds a map of what works from outcome-linked deal cycles, not best practices from a slide deck written two years ago. When a deal stalls, the layer can surface something concrete: deals with this champion profile that stalled at this stage recovered when the rep did X, drawn from a cohort of similar deals that actually closed. Pattern extraction from real outcomes, not a guess. With more than 150,000 outcome-linked cycles behind it, three years in production, that map is the part a competitor can't clone by swapping in a better model.

The loop most agents never close

There's a failure mode nobody puts on a roadmap. An agent runs. The dashboard says it ran. There's no attribution back to whether the deal moved, so the feedback never arrives, and the agent never learns. Spans and latency in Datadog tell you the thing executed. They tell you nothing about whether it worked.

Agents don't carry quota. So the question every RevOps leader eventually gets asked, by a CFO or a CRO, is: how do you know any of this is making money? If the loop is open, you don't. You have activity, not evidence.

Loop closes it. The agent's trace plus its intent gets joined to the CRM outcome, private ML labels what happened, and that label feeds back into the context the next agent run draws on. The system improves every cycle, including the cycles that happen when no one on your team is at work. That's the difference between a tool you operate and a system that compounds.

What this changes for stuck deals

Most deals don't die from a competitive loss. They stall. Stuck in legal, waiting on a stakeholder, delayed because the champion couldn't carry it internally. The traditional fix is more process: tighter stage definitions, more required fields, another pipeline review where a manager asks a rep to defend the commit.

None of that addresses why the deal is stuck, which is usually that the rep doesn't know what to do next and the playbook doesn't cover their exact situation. A context layer does address it, because it can match the live deal against the ones that recovered and hand the agent the specific move, with the evidence attached so the rep trusts it enough to act.

The shift worth naming: the owner of this isn't the individual rep. It's RevOps. When the judgment lives in a layer the whole org calls, a new rep gets the org's pattern library on day one instead of rebuilding it through two years of trial and error. RevOps stops configuring SaaS tools and starts engineering the system that produces revenue outcomes. That's the job now, and the context layer is how it gets done.

What building it actually taught us

A few things we got wrong first, since the honest version is more useful than the tidy one:

1. Depth beats breadth. We assumed covering more tools was the priority. It wasn't. Actually reasoning over what's in a call transcript, rather than indexing it, delivered more than shallow coverage across fifteen connectors. Fewer sources, understood properly.
2. Reps want the reasoning, not the verdict. "Do this next" gets ignored, especially when it contradicts instinct. Showing the comparable deals and what happened in them is what turns guidance into something a rep will act on.
3. The decision trace earns its keep in the moment, not just in training. We built it to teach the model. It turned out to be the thing that makes the model's next recommendation credible to the human reading it. The trace is the product, twice over.
4. Local learning has to become global learning. The unlock isn't helping one rep on one deal. It's encoding what works so the whole org compounds. If the patterns aren't accessible from day one, you've built a smarter silo, which is the problem we started with.

The value is migrating to context

Salesforce won by giving leadership a place to see pipeline. It never gave reps a reason to keep it accurate, because it didn't do anything for them, so the context that drives outcomes stayed trapped in people's heads.

The value is migrating from models to context to application. Models are commoditizing. Applications sit on top. The defensible middle is the context layer, and that's the layer we own. Reps engage because the system helps them close. Leadership gets accurate forecasts as a byproduct, because the context is captured during execution instead of retyped into fields afterward.

That's the bet. An agent that understands your deals is the payoff. A context layer it runs on is the reason it can.

If you're running revenue like an engineering team and want to see the layer working on real data, the place to start is an integrated pilot: fluint.io/request-demo.