Building agents is trivial now, context is the next frontier

What remains difficult when building an agent becomes easy, but its answers are still confidently wrong? Jeff Ng, a founding engineer at Unblocked, starts with that mismatch. He recalls that six months earlier, building a production agent could occupy a team for roughly a quarter. Selecting a model and attaching tools was only part of the work; the surrounding production systems could each amount to a company or a substantial engineering function.

Durable state is one of those requirements. Agent runs are long-lived and stateful, while the infrastructure executing them can disappear. A useful checkpoint must preserve message history, tool calls, and the current position in the agent loop. Without those, a crash leaves the service unable to resume the session.

Restarting is not equivalent to resuming. It repeats token expenditure and makes the user wait through work already performed. It can also repeat side effects: an action taken before the crash may happen again when the run starts over. Persistence therefore protects more than the conversation transcript; it preserves the execution history needed to continue responsibly.

Two other requirements sit alongside persistence:

• Sandbox isolation: Agent-generated and third-party code execute on the operator’s infrastructure. Isolated sandboxes help restrict access to environment secrets and unnecessary network destinations, while protecting the shared host.
• Observability: When something fails, logs and traces must make it possible to locate the failure across the systems involved.

These are necessary production capabilities, but none gives the agent better knowledge of the task. They are the cost of getting an agent into service.

Cloud infrastructure providers such as Cloudflare, Vercel, and AWS increasingly supply the underlying primitives, while frameworks such as Flue, Vercel’s eve, and Mastra assemble them into an agent runtime. That moves effort away from supporting infrastructure and toward the logic that serves a team or customer.

Ng’s example combines Flue with Cloudflare. Once the runtime handles the supporting systems, defining an agent becomes a small set of choices:

The compact configuration is meaningful because the runtime supplies the machinery behind it. It does not, by itself, supply the facts the agent needs to make a correct decision.

The demonstration is a Linear issue enrichment agent with access to a code repository. Its workflow is straightforward:

1. Fetch the Linear ticket.
2. Determine whether it describes a feature or a bug.
3. Search the repository for relevant code.
4. Pass the findings to the agent.
5. Produce a plan of next steps.

This is a useful background task: turn a short issue report into something an engineer can act on.

The input is a support engineer’s report about degraded responsiveness in the internal agentic QA pipeline. Ng reports time to first character of three to four seconds, against an expected hundreds of milliseconds. That is the incident’s reported symptom, not a measured comparison between agent frameworks.

The agent fetches the ticket, uses its code retrieval and search capabilities, reasons over the results, and writes a recommendation back to Linear: re-enable async dispatch. The reasoning sounds sensible. Async dispatch allows more QA pipeline work to run in parallel on a single machine, so enabling it appears to address the latency problem.

But async dispatch had caused an outage a few days earlier. A support engineer had explicitly disabled it before this ticket was presented. The agent has successfully completed its workflow and updated the issue, yet its proposed fix would reverse an intentional operational decision. A plausible explanation of the code is not enough to establish that a change is safe.

The missing evidence lived outside the repository and the current ticket. Engineers had discussed the outage in Slack: what went wrong, what fixed it, and what should happen next. That discussion also produced a Linear postmortem ticket. Neither source was part of the enrichment agent’s input. The agent could inspect the implementation without seeing the explanation for its current state.

This becomes especially dangerous in a background agent. There may be nobody watching the recommendation appear, so missing organizational knowledge becomes a silent failure. The resulting ticket can misinform teammates and potentially other agents that later treat it as context.

Interactive coding sessions often conceal this dependency because the engineer supplies the missing context turn by turn. The person asks questions, catches errors, adds facts, and steers. They know why the code looks the way it does, what broke previously, and what the team decided afterward. The agent has only its instructions, its supplied tools and skills, the code, and the ticket in front of it.

Removing the human from the loop also removes that source of history and intent. Easier deployment makes unattended agents more common, but it does not replace the knowledge their users were quietly contributing. Something else has to carry that responsibility.

Ng calls the replacement a context engine: a system that provides task-relevant information, accounts for the identity and access roles of the person or agent asking, and reconciles conflicting sources. Its output should be a synthesized understanding the agent can act on, rather than a list of documents it must independently interpret.

The inputs extend beyond source code because engineering work does too. Slack contains decisions; documentation contains best practices; tickets record problems and follow-up work. The context engine connects documentation, code, tickets, and conversations, then builds a model of how the organization and its systems fit together. For a particular task, it returns a slice of that model that has been reconciled, ranked, and scoped to permissions. The intended transformation is from scattered information to grounded context.

Why not simply connect Slack, Linear, and GitHub through MCP? Those connectors make the sources accessible, but separate source results still leave the agent responsible for deciding what to believe. The distinction is between retrieving information and preparing it for a decision:

In Ng’s account, irrelevant results consume context-window space and increase context costs. When Slack and Linear disagree, the local agent must resolve that disagreement ad hoc.

This is a distinction between system responsibilities, not a restriction of MCP: Unblocked itself serves synthesized context through MCP. Two implementation boundaries matter. Its later architecture explanation allows unresolved disagreements to be surfaced rather than silently settled. Permission scoping also depends on authentication and configuration: current installation guidance warns that a token-based connection can expose team-source documents, including private Slack content. A connector alone therefore guarantees neither reconciliation nor the intended access boundary.

Ng returns to the same file and the same agent, now with the context engine connected. The additional step asks Unblocked to research the Linear ticket before the agent completes its reasoning. During the repeated run, the context engine finds the relevant Linear postmortem and the Slack conversation containing the engineering discussion. It returns a synthesized summary to the agent, so the agent no longer has to reconstruct that history from the source documents itself.

The integration boundary can be expressed in TypeScript as a function that assembles the inputs to planning. Here, researchContext represents the context service and proposeNextSteps represents the agent; neither is a particular SDK method. The important dependency is that planning receives organizational context alongside the ticket and code findings:

type Ticket = {
  id: string;
  description: string;
};

type EnrichmentServices = {
  fetchTicket(id: string): Promise<Ticket>;
  searchCode(ticket: Ticket): Promise<string>;
  researchContext(ticket: Ticket): Promise<string>;
  proposeNextSteps(input: {
    ticket: Ticket;
    codeFindings: string;
    organizationalContext: string;
  }): Promise<string>;
};

async function proposeIssueEnrichment(
  ticketId: string,
  services: EnrichmentServices,
): Promise<string> {
  const ticket = await services.fetchTicket(ticketId);
  const [codeFindings, organizationalContext] = await Promise.all([
    services.searchCode(ticket),
    services.researchContext(ticket),
  ]);

  return services.proposeNextSteps({
    ticket,
    codeFindings,
    organizationalContext,
  });
}

For the async-dispatch ticket, the additional input carries the outage discussion and postmortem that were missing from the first run. This function returns a proposal; publishing it to Linear is a separate operation.

The demonstrated recommendation then changes. Ng describes the revised advice as preventing another outage instead of causing one. The demonstrated result is a changed recommendation, not a production fix with a measured outcome. What changes the decision is the newly available history of the system, rather than a different model or a different repository.

Ticket enrichment is one application of the same underlying requirement. Ng extends it to several other workflows:

• Coding plans: Supply organizational context to Claude Code or Codex before the agent proceeds with its plan. Ng claims this can save context and tokens, without providing measurements.
• Code review: Give the reviewer the history and intent that would inform an experienced teammate’s review.
• Customer success and sales: Surface answers grounded in the organization’s knowledge for people responding to customers.

The application slide also includes code generation, triage operations, and incident management. Across these uses, the shared input is institutional knowledge that is difficult to recover from the immediate task alone.

An agent can have the tools to inspect a system and still lack the reason that system was built—or deliberately changed—that way. As deployment becomes easier, supplying that reason becomes a larger part of making unattended agents useful. Ng closes with the distinction his demonstration makes concrete: “The gap isn't intelligence, it's context.”