Talk by Jeff Ng (Unblocked) arguing that building agents has become trivial while context is the remaining frontier. Opening example: an agent enriching Linear tickets recommended re-enabling async dispatch in Unblocked's QA pipeline because time-to-first-character had degraded — unaware a support engineer had disabled that setting days earlier after it caused an outage. The agent had the ticket and repository but not the Slack thread or postmortem, so it reasoned soundly from incomplete context. Ng contrasts this with six months earlier, when building an agent took a quarter of a year due to checkpointing, sandbox isolation, and observability work — plumbing now absorbed by cloud primitives and agent frameworks, leaving a model, instructions, tools, and a sandbox. He argues MCP provides access but not understanding, and demonstrates rerunning the same agent against a context engine spanning docs, code, tickets, and conversations, which flips the recommendation from repeating the outage to preventing it. # Video Identity Observations — Jeff Ng, Unblocked ## Speaker & Channel Self-Identification - **Explicit role claim:** The speaker opens with *"my name is Jeff. I'm a founding engineer at Unblock"* — a direct self-description tying the presenter to the company **Unblocked** (also rendered "Unblock" in the transcript). - **Company-affiliated presentation:** The talk functions as a company showcase. The speaker references *"what we're trying to solve at Unblocked"* and directs the audience to *"booth P16 along with the rest of my team."* ## Intended Audience - **Software engineers and AI-agent builders:** Evidence includes: - *"we're running more and more agent-generated code as well as third-party code"* - *"Everyone here does uh coding with uh cloud code or code X"* — assuming the audience uses agentic coding tools. - *"we all use agents locally"* - **Engineering-organization context:** The demo is built around Linear tickets, Slack discussions, code review, and *"your customer success team as well as sales"* — addressing teams building agents for development workflows. - **Conference setting:** The talk is delivered to a live event audience, with mentions of *"additional breakout sessions later tomorrow."* ## Claimed Scope of the Channel/Content - **Topic scope (stated):** *"how building agents has actually gotten pretty easy. But unfortunately, they still get things confidently wrong"* — framing the presentation around agent infrastructure maturity and the remaining context problem. - **Product scope (stated):** The channel content showcases Unblocked's **"context engine"** — defined as *"a system that provides task-relevant information based on who you are and what matters"*, which *"resolves all the conflicts across multiple data sets"* and *"delivers a synthesized understanding that an agent can act on."* - **Positioning vs. alternatives:** Explicitly contrasts with MCP: *"MCP is great at access, but access isn't understanding."* - **Claimed thesis:** *"The gap isn't intelligence, it's context."* ## Demonstrated Presentation Patterns (Observable) - **Live-demo format:** Walks through a working Linear issue-enrichment agent built with *"flu [Flux] and Cloudflare"* — showing both a failure case (wrong recommendation due to missing context) and a corrected run using the context engine. - **Vendor evangelism pattern:** The talk demonstrates a problem (agents failing without context) and then resolves it with the speaker's own company's product, ending with booth and follow-up session promotion. - **Technical-practitioner tone:** Uses production-engineering vocabulary (checkpoint/state persistence, sandbox isolation, observability, tokens, latency, side effects) rather than introductory material. ## Claims vs. Demonstrated Evidence | Creator claim | Evidence demonstrated | |---|---| | Agent building is "trivially easy" now | Screenshot/code walkthrough of a minimal agent definition (model, instructions, tools, sandbox) | | Context engine fixes the failure | Live second run where the recommendation *"has been updated... from breaking and causing another issue to actually preventing a another outage"* | | Applies beyond issue triage (coding, code review, CS/sales) | Stated as potential use cases; only the Linear issue demo is shown | ## Cross-System Identity Notes - Consistent identity across title and transcript: **Jeff Ng / Unblocked / agent context engineering** — no contradictory signals in the provided material. # Delivery Observation: Jeff Ng — "Building Agents Is Trivial Now, Context Is the Next Frontier" ## Tone - **Conversational and low-key**: steady, informal conference-talk register with frequent filler words — "you know," "uh," "um." - **Self-deprecating honesty about failure**: he uses his own demo's incorrect output as the pivot point of the talk: > "Sounds great, right? Unfortunately, uh this is wrong." ## Vocabulary & Framing Devices - **Rhetorical question → answer structure**, used repeatedly to advance the argument: - > "Where did things go wrong?" - > "So, I guess the next question is, why don't we run into this locally?" - > "The obvious next question is, why can't we just do this with MCP, right?" - **Punchy contrastive aphorisms**, the talk's most quotable delivery habit: - > "MCP is great at access, but access isn't understanding." - > "Scattered context comes in, grounded context comes out." - > "The gap isn't intelligence, it's context." - **"Tax" metaphor** for infrastructural overhead: > "They're all taxes one has to pay in order to get an agent out there to play the game." ## Teaching Habits - **Enumerated structure** ("A, B, C") when defining agent components: > "A, deciding which model you want to use. B, the instructions or, you know, the system prompt. C, the tools..." - **Live demo with deliberate failure**: walks through a Linear issue-enrichment agent, shows it succeed, then reveals the answer was wrong — the demo doubles as the problem statement and the product pitch. - **Signposting transitions**: "So, next thing...", "Thankfully, things have changed quite a bit.", "So, back to the original problem I had earlier." - **"Before/after" demo structure**: the same agent is re-run with the context engine to show the recommendation flipping from harmful to correct. ## Recurring Phrases - **"you know"** — extremely frequent connective throughout. - **"context"** as the anchor term, repeated deliberately as the thesis. - **"Unfortunately"** as a recurring pivot word: > "unfortunately, they still get things confidently wrong" ... "Unfortunately, that's actually quite expensive as well" ... "Unfortunately, uh this is wrong." ## Communication Patterns - **Narrative self-inclusion**: frames insights through personal experience — "I was shocked at when I first took a look at the documentation." - **Plain-language definitions**: > "A context engine is a system that provides task-relevant information based on who you are and what matters." - **Sales close**: talk ends with booth call-to-action ("booth P16") and pointer to breakout sessions — a vendor-presentation pattern, though delivery stays understated. ## Uncertainty Notes - No timestamps beyond transcript line markers; filler-word frequency is estimated from the transcript, not audio. - The demo pauses ("Sorry about that.") suggest a live technical hiccup, but the cause is not observable from text alone. # Observation Document: "Building Agents Is Trivial Now, Context Is the Next Frontier" **Speaker:** Jeff Ng, founding engineer at Unblocked (self-identified in transcript) ## Central Claims - **Building agents has become easy; context is the remaining hard problem.** Six months ago, building an agent "required a team's effort and basically a quarter"; now frameworks and cloud primitives make it trivial. - **Agents still get things "confidently wrong"** because they lack organizational context, not intelligence. > "The gap isn't intelligence, it's context." ## Supporting Reasoning ### 1. Agents are more than models and tools An agent is "the models, the tools, and everything required to build out a production service." Previously necessary systems included: - **Checkpoint and state persistence** — agent runs are long-lived and stateful while infrastructure is ephemeral; crashing without durability loses message history, tool calls, and loop position. Restarting is expensive (lost tokens, latency) and risks **doubled side effects**. - **Sandbox infrastructure** — agent-generated and third-party code runs on your infrastructure; isolated sandboxes prevent reads of environment secrets, unnecessary network access, and taking down the shared host. - **Observability** — answering "where did this fail?" requires tracking logs/traces across half a dozen systems. Ng emphasizes: **none of these improve agent capabilities** — "they're all taxes one has to pay." ### 2. The ecosystem matured Cloud providers (Cloudflare, Vercel, AWS) built primitives; frameworks (Flu, Vercel Eve, Astra) use them. Defining an agent now requires only: model choice, instructions/system prompt, tools/skills, and sandbox location. ### 3. Demonstrated failure: Linear issue enrichment agent Ng built an agent that fetches a Linear ticket, classifies it (feature/bug), searches code, and proposes next steps. - **Test case:** degradation in their agentic QA pipeline — time to first character was 3–4 seconds vs. expected hundreds of milliseconds. - **Agent's answer:** re-enable async dispatch. - **Reality:** this was **wrong** — re-enabling async dispatch had caused an outage days earlier, and a support engineer had explicitly disabled it before the ticket was filed. > "Where did things go wrong?... The agent I had written, it didn't have a full picture." Missing context: the Slack discussion after the outage and the resulting postmortem Linear ticket. Because it ran as a **background agent**, it would "make that mistake silently in the background misinforming both my teammates and potentially other agents." ### 4. Why this doesn't happen locally Humans act as the context layer — asking questions, catching errors, supplying missing facts each turn. A person knows "why the code is the way it is, what broke last time, and what we've decided to do about it." The agent only has instructions, given tools, the code, and the ticket. As background deployment grows, missing context becomes a point of failure. ### 5. Proposed solution: a context engine Definition (per Ng): a system that: - Provides **task-relevant information** based on who you are and what matters - **Resolves conflicts** across multiple data sets - Respects access/permission rules - Delivers a **synthesized understanding an agent can act on**, "not just a list of documents" How it works: connect docs, code, tickets, conversations → build a model of the organization → agents receive only reconciled, ranked, permission-scoped slices. "Scattered context comes in, grounded context goes out." ### 6. Why MCP alone is insufficient Ng argues MCP is "great at access, but access isn't understanding": - Hands the agent raw results, leaving it to decide what to believe - Floods the context window with irrelevant data; context costs rise - Leaves conflict resolution (e.g., Linear vs. Slack MCP disagreeing) to the agent "somewhat ad hoc" ### 7. Corrected demo result With the Unblocked context engine connected, the same ticket workflow surfaced the postmortem and Slack discussion as a synthesized summary; the recommendation changed from "breaking and causing another issue to actually preventing another outage." ### 8. Other claimed use cases - **Coding:** hydrating agent plans (e.g., with Claude Code/CodeX) saves context and tokens - **Code review:** makes PRs look reviewed by an expert/team - **Customer success and sales:** surfacing correct answers - Generally: giving agents "institutional and tribal knowledge" ## Qualifications and Notes - Ng speaks as a Unblocked employee promoting its product; the "context engine" is Unblocked's own offering (booth P16, follow-up sessions mentioned). - No independent evidence presented beyond the speaker's own demo and anecdote; the outage details are his account. - Framework names transcribed as "Flu," "Vercel Eve," "Astra" (possibly AI SDK / Vercel AI / Mastra); recorded as spoken. # Speaker Attribution & Provenance Record ## Video - **Title:** Building Agents Is Trivial Now, Context Is the Next Frontier — Jeff Ng, Unblocked - **Video ID:** `01a15ca7-c86a-7cff-b565-9b2a8b17cafa` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Jeff** (Jeff Ng, per title) | **Creator / Presenter** — self-identified founding engineer at Unblocked | *"Hi all. Uh my name is Jeff. I'm a founding engineer at Unblock, and I'm here to talk to you…"* | - No other speakers appear in the transcript; the talk is a single-presenter conference session. ## Referenced Third Parties & Products (as mentioned by speaker) - **Infrastructure providers:** Cloudflare, Vercel, AWS - **Frameworks/tools:** Flu ("phlow"?), Vercel Eve, Astra, MCP (Model Context Protocol), Slack MCP, Linear MCP, GitHub MCP, Cloud Code, Code X (transcribed phonetically) - **Platforms:** Linear (issue tracking), Slack, GitHub ## Promotional Segments (flagged) - **Product demo:** Live demonstration of the speaker's own Linear issue-enrichment agent built with Flu/Cloudflare ("I've actually gone and built out a issue enrichment system specifically for Linear"). - **Unblocked promotion:** Introduction and pitch of the **Unblocked context engine** — "a system that provides task-relevant information based on who you are and what matters" — including a second demo "we're currently prompting Unblock to do some research on the ticket." - **Use-case pitch:** Coding, code review, customer success/sales applications of the context engine. - **Closing promotion:** *"I'll be at booth P16 along with the rest of my team"* and mention of follow-up breakout sessions on the context engine. ## Third-Party Claims - Claim that cloud providers and frameworks have removed agent-infrastructure complexity (checkpointing, sandboxing, observability). - Claim that MCP provides access but not understanding (conflicts, context-window flooding, cost). - Claims about the Unblocked demo outcomes (finding postmortem ticket, Slack discussion, corrected recommendation) — vendor-demonstrated, not independently verified. ## Availability & Metadata Limits - No curated metadata was supplied beyond title and transcript. - **Comment availability:** Not indicated. - **Cited sources:** None cited beyond the demos; internal Slack/Linear artifacts referenced in the demo are not publicly linked. - Speaker surname "Ng" and company "Unblocked" derive from the title; transcript itself only gives first name "Jeff" and "Unblock." \>\> Hi all. Uh my name is Jeff. I'm a founding engineer at Unblock, and I'm here to talk to you about how building agents has actually gotten pretty easy. But unfortunately, they still get things confidently wrong. So, 6 months ago, it required a team's effort and basically a quarter to build out an agent. Um an agent is more than just models and tools. It's the models, the tools, and everything required to build out a production service. Here are some examples of the different systems that were necessary in order to build something out. Each one of these was basically its own company or at least a company function. Not going to go through each one of these, but you know, a few that stood out to me. First one, checkpoint and state persistence. Agent runs, they're typically long-lived and stateful. Um unfortunately, uh infrastructure itself though, those that's ephemeral. Crashing without durability can actually lead to a lot of state loss. And that state kind of includes things like message history, tool calls, as well as, you know, where you are in the loop. Without these things, you can't resume the session. Uh one option is, you know, maybe you want to restart the session. Unfortunately, that's actually quite expensive as well. Uh you lose out on all the tokens that you had originally used, um as well as, you know, latency. Uh from a user experience standpoint, you've already triggered that session. Now, you have to wait for the whole thing to go again. And lastly, side effects. Your agent might have performed some side effects, and now there's a chance of those doubling up. So, next thing, sandbox infrastructure, right? So, as we all know, we're running more and more agent-generated code as well as third-party code. This gets all run on your infrastructure, and due to that, there are some complexities. Uh because of that, we want to introduce isolated sandboxes, which help prevent uh unnecessary reads of environment secrets, unnecessary network access, you know, just in general, we don't want to take down the shared host. And then, observability. How do we answer the question, "Where did this fail?" Typically, this includes tracking logs and traces from across half a dozen systems. Everything I've mentioned here, none of this actually improves an agent's capabilities. They're all taxes one has to pay in order to get an agent out there to play the game. Thankfully, things have changed quite a bit. Um the whole ecosystem has matured quite a bit, and cloud infrastructure players such as Cloudflare, uh Vercel, AWS, they've gone and taken some of that complexity away and built primitives that these frameworks, Flu, Vercel Eve, Astra, with these together, you know, they've taken a lot of complexity away, and you can focus more on building the actual agent itself. The core logic that actually helps you and your team and your customers. So, here's an example of one. Uh I played around with Flu and Cloudflare, and as you can see on the left-hand side, you know, we basically handle everything as mentioned before. So, the primitives plus the framework lead to a situation where it's actually not that much code to define an agent. Uh one of the things I was shocked at when I first took a look at the documentation. To get in the details, all you really have to do when defining agent is A, deciding which model you want to use. B, the instructions or, you know, the system prompt. C, the tools that you want to ask the agent to have access to. Skills, the things I can do. As well as the sandbox location, where things are being run. So, uh to give you an example of this, I've actually gone and built out a issue enrichment system specifically for Linear. So, what this does is given a Linear ticket and access to your code repository, it'll go out, you know, fetch the Linear ticket, determine whether or not it's a feature or a bug. From there, it'll do some code searching, provide all that context to the agent, and then come up with a plan of next steps. On the left-hand side here, this is a issue that one of my colleagues, uh support engineer, had posted, I think, a month ago. Uh to summarize it, what had happened was we had some pretty serious degradation in our agentic QA pipeline. Time to first character was taking 3 to 4 seconds when it should realistically be in the hundreds of milliseconds. So, let's see what happens when, you know, we put this through the system. So, as you'll see here, I've set up the agent to go fetch the agent. I've given it the skills and tools to actually go and fetch the code, search the code, and query against that. That's being passed back to the agent, which is doing some reasoning against that right now. And then, just wait a little bit. At this point, we've updated the Linear issue ticket. The recommendation here is to re-enable our async dispatch, which makes sense. It allows us to run a lot more of our QE pipeline in parallel on a single machine. Sounds great, right? Unfortunately, uh this is wrong. This had actually caused an outage a few days ago in one of our uh support engineers had explicitly disabled this uh before this ticket was uh shown. So. Where did things go wrong? Why was the uh you know, why did I get it wrong? The agent I had written, it didn't have a full picture. It was missing the context from the Slack discussion that happened after the issue where the engineers came together, uh went through the actual outage, what went wrong, what was the fix, and the next steps. It also was missing the postmortem uh linear ticket, which came as a result of that. In general, it had a narrow understanding of the problem. This concept of missing knowledge and intent that's stored across an organization and different systems is something that comes back and back again. And since this was deployed as a background agent, this is going to make that mistake silently in the background misinforming both my teammates and potentially other agents. So, I guess the next question is, why don't we run into this locally? You know, we all use agents locally, we don't necessarily run into these issues. Well, you, the human, the engineers, we currently act as that context layer. When working with an agent, you know, you're there to ask questions, catch any errors, and supply the missing facts on every single turn. A person knew why the code is the way it is, what broke last time, and what we've decided to do about it. The agent though, it only has what's on the right-hand side, right? It has instructions, the tools and skills we specifically gave it, the code, as well as the ticket in front of it. When an agent is in the loop, well, sorry, when a human is in the loop with the agent, we're there to catch the steer. Ultimately, we're there to babysit the agent. But as agents have gotten trivially easy to deploy as I showed earlier with flu, Cloudflare, the without the human in the loop, this issue becomes more and more prevalent. This missing context becomes a sign of failure. You know, all that intuition and knowledge that we've had as humans needs to be replaced. Something needs to carry the load. So, that thing, that's a context engine. A context engine is a system that provides task-relevant information based on who you are and what matters. It also resolves all the conflicts across multiple data sets. It understands your access rules or the agent's access rules and only uh respects that and only provides information that's relevant. And most importantly, it delivers a synthesized understanding that an agent can act on, not just a list of documents that I have to reason upon itself. So, how does this context engine work? Well, let's take a step back. What does an agent actually need? An agent needs Clearly, it needs context outside of just your source code. Think about everything that you need to work day-to-day. It's not just the code. It's, you know, the Slack discussions where decisions are made, the documentation where we show all the best practices. All that is important to your day-to-day process, and that's true for your agent as well. So, what we do here is we connect everything. The docs, code, tickets, conversations. We then build a model of your organization, of your system. And we piece how all these things work together and make it generally available to your agents. From that model, the agents are only provided a a of that data which has been reconciled, ranked, and scoped to your permissions. Scattered context comes in, grounded context comes out. The obvious next question is, why can't we just do this with MCP, right? You could connect a Slack MCP, a Linear MCP, a GitHub MCP, and with that, all that data is accessible. MCP is great at access, but access isn't understanding. An MCP hands the agent the raw results, and you know, you're now dependent on that agent to actually decide what to believe in. You end up flooding the agent with irrelevant data, filling up the context window, and you know, overall context costs just go up. It also leaves the local agent to handle conflicts in data. You know, your Linear MCP and your Slack MCP may come back with different results. You're just leaving the agent to make that decision somewhat ad hoc at the moment. So, back to the original problem I had earlier. This is the same file, same engine, but now we've connected the context agent. Uh what we do here is is we're currently prompting Unblock to do some research on the ticket and provide that context to the agent. So, let's see that in action. Sorry about that. So, here we go. Uh we're doing the very similar thing. We're fetching the Linear ticket. But, you'll notice here that we're actually calling the Unblock context engine. And what's done here is actually it's found the relevant Linear postmortem, as well as a Slack conversation where we've had the entire discussion between the engineering teams. And as part of that, we've returned a understanding, and that's now been provided to the agent as a summary. So, the agent no longer has to actually reason from those documents. Uh at this point, you'll notice here the agent now has been updated. Uh the recommendation has gone from breaking and causing another issue to actually preventing a another outage. So, the example I've shown here is issue ticket management, but this context layer can actually go a lot further. Uh for example, coding. Everyone here does uh coding with uh cloud code or code X. Using an Unblocked context engine to actually hydrate the agent plan goes a long way in terms of saving context and tokens. Uh code review. It makes the PRs look as if they've been reviewed by an expert or an team. Who doesn't like that? As well as surfacing the correct answers to your customer success team as well as sales. In general, there are many instances where you might want an agent to have institutional and tribal knowledge of your organization. Just want to leave you on this. I think this quote encapsulates what we're trying to solve at Unblocked. The gap isn't intelligence, it's context. So, thank you. Uh I'll be at booth P16 along with the rest of my team. If you guys have any questions. There will be additional breakout sessions later tomorrow, I believe, that goes a lot more in depth about actually how the context engine works and you know, how you can benefit from that. Cheers.