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.
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. We 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.
We 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. We 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/*:
researchreturns 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/urlsretrieves content from links you already have.
The TypeScript SDK gives those operations generated request and response types:
bashbun add @getunblocked/sdktypescriptimport { 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.
