How a context engine actually works and why you need to care, now

Brandon Waselnuk

January 30, 2026

I sat down with Peter, one of our founding engineers, to talk about what makes a context engine work. We covered why every new employee trips over the same Font Awesome problem, how to figure out who's right when two people in Slack say opposite things, and what happens when documentation, implementation, and intent all disagree.

Here's an overview of our conversation.

The 20-year veteran transformation

Peter has a way of describing what Unblocked does at its core.

"Agents behave not just like individual engineers, but individual engineers starting from ground zero. You give a coding agent a task, and it will rip away using the tools at its disposal to discover context. The downside is that when it first encounters a piece of information that it thinks leads to the solution, it stops."

The result: you get an expert engineer who has no local knowledge. They'll find something that looks right and run with it.

A context engine flips this.

"You're taking that expert engineer that's like a new employee and transforming them into an expert engineer that's been at your organization for like 20 years."

That's the basic idea. Everything you need, none of what you don't.

The Font Awesome problem

Peter gave me a concrete example. Unblocked uses Font Awesome, which requires authentication to pull the NPM package.

"Literally every employee trips up on this. And for some reason we just haven't added it to the README."

They have now. But for the first few employees who hit this, Unblocked was able to reference all the past Slack conversations about the issue. The tribal knowledge that normally gets black-holed forever was suddenly accessible.

That's what a context engine does. The stuff that founding engineers have learned over years, now at everyone's fingertips.

When Jimmy says one thing and Susan says another

I asked Peter how Unblocked handles conflict resolution. What happens when two sources disagree?

He broke it down into categories.

Literal conflict: One person says this, another says that. How do you know who's right?

"Generally what we do as humans is think, okay, who's the expert in this domain area? Who's been here the longest? Who has the most trust of the team?"

Turns out those are signals you can mine for. Unblocked builds what Peter calls an expert and social graph. Not a social network, just the relationships based on how people work together. From PRs, you can see who reviews whose code, who does reviews versus who asks for reviews.

When there's a conflict, you can look up who the appropriate expert is and rank accordingly.

Old docs aren't automatically stale

Staleness is the second category. How old does a document have to be before it's irrelevant?

"The answer is not as simple as it seems. You could be like, okay, documents that are a couple years old are clearly not relevant anymore. Discard. You can't do that."

Some organizations have longstanding documents that describe old architecture that's still important to understand. Others describe best practices that have carried forward for years.

So Unblocked biases by time when there's a conflict, but doesn't blindly throw out old docs.

Source code as ground truth

The third anchor is source code.

"In a software organization, we are blessed with this one ground truth thing we have, which is source code. It kind of accurately describes the way that a system works today. So if a document is describing how a component functions and the code says no? Obviously we know what the right answer is."

Peter was clear that this is one of the hardest problems in the domain. Every time they identify an opportunity to improve it, they do. There's no silver bullet.

The "Duplicate Rashin" problem

I asked how Unblocked determines intent when someone asks a question.

"You can't just take a sentence that someone writes and assume that the literal thing they're saying is the actual intent."

Intent relies on context. Not just organizational context, but context about who the user is. What do they work on? What have they been doing recently?

Peter gave an example. He has a colleague named Rashin. If he asks "What is Rashin working on?"—there could be many Rashins in a large organization. And even the Rashin he's thinking of could be working on many projects.

"Most of the time what I'm really asking is: what is Rashin working on that's related to the thing that I care about?"

So Unblocked narrows the focus. Peter's working on these things. He's asking about Rashin. Rashin is connected to his social graph. It's probably that Rashin, working on something related to Peter's current focus.

"We're making a lot of assumptions. But that's what you do when you try to interpret intent."

If they get it wrong, the user can correct it and the conversation continues.

Private channels and ephemerality

I asked about security. How do you answer a question while respecting permissions?

Unblocked has a system called Data Shield. It reflects permissions from the source. If you remove someone from your organization in GitHub or Slack, or they don't belong to a private channel, those permissions instantly flow into the system.

For private channels specifically, they make live API calls to validate the user is actually in the channel before allowing them to interact.

What happens if someone asks a question in a public channel but has access to private data?

"The answer will be posted to them ephemerally, so only they can see it. They have to take the decision to promote that information so other people can see it."

They considered sending it as a DM instead, but that takes away the ability for people to decide how to share information. Sometimes that private context is exactly what the team needs.

The incorrect implementation problem

Peter described a weird scenario from a customer. They had an old document describing how a component should behave. Then someone did work to implement it—new documentation, new code.

But it was implemented incorrectly. The original intent wasn't captured.

"How do we determine correctness in those circumstances? They're definitely the minority of cases, but there's probably something encoded in the institutional knowledge that can bring that forward."

The thing they're working on now: how do you recognize when it's the right time to point out that something exists in a way that doesn't confuse the conversation? Maybe prompt the user to update or remove a stale document.

This is also why customers keep asking: "How do I update my stale docs?" You can use Unblocked to do it.

The overeager intern

Peter used an analogy I liked.

"If you've got this really overeager intern, and you took all those things they were saying as truth and you ran with that, you'd probably run into some trouble. They're not knowledgeable about the domain. They lack the organizational context."

This is why Unblocked contextualizes everything. Slack conversations are presented from trusted individuals, or at least flagged with context: so-and-so is talking about this thing. Seems interesting. Would you like to learn more?

"The AI needs to have the humility to know when it doesn't actually understand what ground truth is, and at least be upfront and admit that. And then point the user to the information so they can explore it themselves."

Listen to the full conversation

This post covers some of the highlights, but the full conversation goes deeper into how the social graph works, the techniques behind conflict resolution, and where Peter sees the context engine going next.

Give it a listen.

Unblocked is available now. Read our docs or reach out to see it in action on your codebase.