# Building Agents Is Trivial Now, Context Is the Next Frontier — Jeff Ng, Unblocked

## Executive summary

While cloud primitives and frameworks have made defining AI agents trivial—reducing complexity from requiring dedicated systems for checkpointing, sandboxing, and observability—the primary failure point remains missing organizational context. The speaker argues that simple access layers (like Multiple Connectors/MCPs) are insufficient because 'access is not understanding.' A Context Engine solves this by connecting disparate data sources (docs, code, tickets, conversations) to provide a synthesized, task-relevant understanding that agents can act upon, preventing critical errors and outages.

## Key takeaways

- Agent Development Complexity Has Decreased: Six months ago, building an agent required significant effort to solve infrastructure problems like state persistence (checkpointing), isolated sandboxes, and observability. Modern cloud primitives (e.g., Cloudflare, Vercel) have absorbed this 'plumbing,' simplifying agent definition to selecting a model, instructions, tools, and sandbox location.
- The Context Gap is the New Bottleneck: Agents struggle with institutional knowledge—the decisions, failures, and postmortems stored across different systems (Slack threads, documentation). An agent lacking this full picture can make confidently wrong recommendations, potentially causing outages.
- Context Engines Provide Synthesized Understanding: A Context Engine goes beyond simple data access by building a model of the organization. It reconciles conflicting results across multiple datasets (docs, code, tickets, conversations) and delivers a synthesized understanding that an agent can act on, rather than just raw documents.

## Technical details

- Agent Architecture Components: Defining an agent now primarily involves selecting: A) The model, B) System instructions (the prompt), C) Tools/Skills the agent has access to, and D) The sandbox location for execution.
- Infrastructure Challenges Solved by Cloud Primitives: Historically required systems included checkpointing/state persistence (to maintain message history and tool call state across ephemeral runs), isolated sandboxes (to prevent unauthorized reads or network access), and observability tools (for tracking logs and traces).
- Context vs. Access Layer Limitations: Simple Multiple Connectors (MCPs) are excellent for data *access*, but they fail at providing *understanding*. They hand the agent raw, un-reconciled results, forcing the agent to handle conflicts ad hoc and potentially flooding the context window with irrelevant data.

## Practical implications

- Build engineers can now focus less on solving infrastructure plumbing (state management, sandboxing) and more on defining the core business logic of their agents.
- Implementing a Context Engine is crucial for mission-critical agents that must operate reliably in complex enterprise environments, ensuring recommendations are based on full organizational history (e.g., postmortems).
- The shift requires moving from simple data integration (MCPs) to sophisticated knowledge graph modeling and synthesis.

## Topics

AI Agents, Context Management, Build Engineering, LLM Orchestration, CI/CD, Linear, Cloudflare / Vercel, Flu

Source: https://www.youtube.com/watch?v=HvMyYLTfvhg