Senior AI Engineer

Your agent framework solved the runtime. It still does not know your company. Agent frameworks now package durability, sandboxing, channels, and evals. They do not provide the organizational knowledge an agent needs to produce work that survives review. Agent frameworks can now handle much of the infrastructure needed to run an agent in production. They give you durable execution, state, tools, sandboxes, channels, and evals. They cannot give an agent the knowledge that belongs to your company. That knowledge explains why the code works as it does, the intent and business needs, which decisions still apply, and what a reviewer will reject. Supplying it is a separate engineering problem. Jeff Ng, Founding Engineer at Unblocked, first gave this talk at the AI Engineer World's Fair 2026. An agent framework can keep an agent running through a deploy, stream its output, and connect it to Slack. It still cannot explain why your checkout service retries on 409. It does not know that Account means one thing in billing and another in provisioning. That knowledge exists, but it is spread across code, pull requests, issues, docs, runtime signals, and conversations. An agent that misses part of it can produce clean, plausible work that comes back from review riddled with corrections. Building the agent itself has become much easier. A useful prototype can now fit into a weekend. Pick a framework, add instructions and a few tools, and you can have something that runs durably and responds through the channels your team already uses. The harder question comes next. Why does its work still need so much review and revision? Frameworks have packaged the runtime. Several frameworks now provide infrastructure that teams recently had to assemble themselves: - Vercel's eve makes an agent a directory. It includes durable workflows, isolated sandboxes, channels, approvals, subagents, and evals. - Cloudflare Think provides persistent sessions, streaming, durable recovery, workspace tools, and subagents on Cloudflare Workers. - Flue, from the creators of Astro, handles durable sessions, sandboxes, tools, skills, channels, and deployment across several runtimes. - Mastra provides typed agents, workflows, memory, workspace tools, and observability for TypeScript applications. No matter which you pick, you still have infrastructure choices to make. Fortunately, you no longer have to build every part yourself before the agent can do useful work. The runtime cannot know your organization. eve has skills/ for reusable guidance and connections/ for MCP servers and HTTP endpoints. Think has persistent memory and workspace tools. Mastra has memory and retrieval. Flue lets you define skills and tools. These systems tell you where context can go. They cannot tell you where your company's context comes from. That limit is reasonable. A framework cannot know that your payments service retries because of an incident two years ago. It cannot know that the current migration plan lives in a Slack thread written by someone who has since left the company. The framework gives knowledge somewhere to go. Your team still needs to collect it, connect the pieces, deconflict sources that disagree, and keep it current. Teams maintain company knowledge by hand. Stripe's internal assistant, Kai, shows how quickly an agent framework can get a system running and how much harder it is to make that system useful across a company. LangChain reports that one engineer built the first version in a week using Deep Agents. Stripe then connected Kai to its data warehouse, Slack, and Google Workspace. More than 100 teams contributed over 1,000 skills, and Kai gained access to more than 500 internal MCP tools. As Kai gained access to more company knowledge, choosing what to give the model became harder. Stripe found that model quality dropped when the system prompt contained more than 150 skills. The team is now building a hybrid selection system that filters the catalog before the model chooses which skills to use. Kai shows the limit of an agent framework. The framework runs the agent and gives it access to information. It cannot determine on its own which information matters for a specific request. More access can make that decision harder. Uber's uSpec faces a narrower version of the same problem. Its skills contain validation rules, schemas, and reference material for seven implementation stacks and three accessibility APIs. Uber can curate this context in advance because the domain and expected output are clearly defined. Most engineering work is not so neatly bounded. The reason for a line of code may be split across a pull request, an issue, an incident report, and a Slack thread. A later decision may also supersede an earlier document. The agent must find the relevant sources, connect them, and determine which information still applies. Agents need a context engine that retrieves company knowledge from the systems where work happens and identifies the evidence that is relevant and current. Connectors give access, not understanding. The obvious shortcut is to connect the agent straight to GitHub, Jira, Slack, and Confluence. Then let the model assemble the answer. That works well when the agent knows exactly what to fetch. It works less well when the answer crosses systems. Unblocked wrote a longer explanation of the difference. With separate connectors, the agent becomes the integration code. It searches each system, compares the results, and decides which source is current. It pays for that work in model turns and tokens every time it receives a question. Connectors return documents from individual systems inflating the agents context window with erroneous data. A context engine finds the relevant evidence across those systems, relates and ranks it server side, then returns a supported answer with only what matters and links. Take the question, "Why does checkout retry on 409?" A useful answer might need all of this: * The current retry code * The pull request that added it * The incident report that explains the failure * A later Slack discussion that rejected a simpler fix Finding the code is search. Explaining the decision requires the other three sources too. Unblocked measured the cost of that gap in one Kotlin SDK test. The agent with synthesized context finished 83% faster and used 48% fewer tokens. It scored 9.5 out of 10 for quality and following team conventions. The agent without that context scored 2 out of 10. This was one vendor-run test, not a universal benchmark. Unblocked published the method and open-sourced a context-engine-simulator so you can run the same comparison on your own code. Treat context as a dependency. The Unblocked public API exposes nine context operations under /api/v1/context/*: * research returns a synthesized answer across connected sources. * search/{code,documentation,issues,messages,prs} searches one source type. * query/{issues,prs} accepts natural-language criteria with optional project, repository, and person filters. * get/urls retrieves content from links you already have. The TypeScript SDK gives those operations generated request and response types: bashbun add @getunblocked/sdk typescriptimport {UnblockedClient} from "@getunblocked/sdk"; const token = process.env.UNBLOCKED_API_TOKEN; if (!token) {throw new Error("UNBLOCKED_API_TOKEN is required");} const unblocked = new UnblockedClient({ token}); const research = await unblocked.context.research({ query: "Why does the checkout service retry on 409?", instruction: "Focus on the current implementation and the decisions behind it.", effort: "medium",}); The response has a Markdown summary and the sources that support it. The API quickstart documents the response and the narrower search and query operations. Make sure you keep the SDK on a trusted server. Never put an Unblocked API token in browser code. Personal tokens are scoped to one account. Team tokens can read all documents in the team's connected data sources. You can restrict either token type to selected data sources. In eve, the same request becomes an agent tool: typescript// agent/tools/get_context.ts import {defineTool} from "eve/tools"; import z from "zod"; import {unblocked} from ".../lib/unblocked"; export default defineTool({ description: "Answer questions about this codebase, its history, and the decisions behind it using the team's code, pull requests, issues, documentation, and conversations.", inputSchema: z.object({ question: z.string, async execute({ question}) {return unblocked.context.research({ query: question});},}); The agent can now ask why the code works as it does. You do not have to copy every decision and discussion into a skill file. Think, Flue, Mastra, and other runtimes can use the same server-side function. Start with a rejected change. Take one agent-generated change that a reviewer sent back. List the evidence the reviewer used to correct it. Was the answer already in the code? Did the reviewer rely on a pull request, issue, incident report, design document, or conversation that the agent never found? If the evidence was spread across several systems, the agent was missing organizational context. Keep stable procedures in skills. Use connectors for direct lookups. Use a context engine when the answer depends on evidence spread across systems and changes over time. The API quickstart shows how to create a scoped token and add context.research to an agent. Use that rejected change as the first test. Ask for the evidence the reviewer had, then check every source behind the answer. Stay in the loop. Emerging techniques for building with AI at scale and how software development is changing from the Unblocked team.

Your agents lack context. Here's how to fix "You're absolutely right." How to build the context engine AI agents need to produce organization-aware, permission-safe, and genuinely useful code. A talk by Unblocked Founder & CEO Dennis Pilarinos from LeadDev London (LDX3). Dennis Pilarinos, CEO of Unblocked, gave this talk at LeadDev London (LDX3). Every AI coding tool can generate code. Very few can generate the right code for your organization, because they're missing context. They don't know why your team chose Redis over DynamoDB, what got decided in a Slack thread last night about the auth migration, or which architectural patterns your principal engineers actually enforce in review. Building a context engine. This talk is a practitioner's guide to building a context engine: the reasoning layer that continuously synthesizes organizational knowledge across disparate sources into unified, queryable understanding for humans and agents. Dennis walks through the problems you actually have to solve: * Searching globally and exhaustively before you can reason * Reasoning across systems that don't agree with each other * Maintaining identity-scoped permissions, so every user and every agent sees only what they should * Personalizing results based on who's asking and what they're working on These are the engineering challenges that make naive RAG fall short, drawn from real lessons building this at scale. Slides. Access isn't understanding. A context engine is what closes that gap. See how Unblocked delivers it to your agents. Open source tools. A few OSS tools Unblocked has built to help teams understand the value of a context engine and start building their own: * Context Engine Simulator: a local tool that A/B tests whether pre-gathered organizational context helps AI coding agents complete tasks faster, cheaper, and better. No accounts needed, runs entirely with your preferred agent and optional MCP connectors you and your team use. * Engineering social graph: a CLI tool that builds a weighted collaboration graph from your GitHub PR history. Point it at a repo, and it maps who reviews whose code, detects teams from review patterns, identifies domain experts for every code area, and flags knowledge silos. Then it renders an interactive visualization you can open in a browser. * Repo rules agent: a CLI tool + skill that turns CLAUDE.md, AGENTS.md, .cursorrules, and ~40 other rules-files scattered around your repo into a queryable index coding agents can consult on demand. Stay in the loop. Emerging techniques for building with AI at scale and how software development is changing from the Unblocked team.