Context Engineering Is the Hard Problem

Getting an agent to run and keeping it useful are different jobs. The plumbing gives it a place to work. Context gives it a chance to do the right work.

My argument is that teams should spend more time on the second job. A better model cannot inspect a submodule that was never cloned. A larger context window does not tell the agent which architecture note is obsolete. A successful tool call does not establish that the answer was relevant.

The April version of this essay said context engineering was a problem nobody had productized. That was too broad. Augment ships repository-context retrieval over MCP, and Anthropic's Managed Agents architecture separates durable session history from the model's working context. Products can supply useful pieces of the system. The remaining question is who makes those pieces reflect your organization correctly.^[1][2]

Anthropic describes context engineering as the ongoing selection and maintenance of information available at inference time. That includes instructions, tools, retrieved data, and conversation history. Its engineering guidance treats retrieval, compaction, and persistent notes as complementary techniques, with tradeoffs in relevance and information loss.^[3]

That is the frame for this essay: an engineering argument, informed by conversations with teams, rather than a measured claim about the causes of most agent failures.

The Wrong Type Is an Environment Problem Worth Fixing

Consider a straightforward ticket: swap one field for another in an existing type. The agent produces a plausible PR, but creates a new type because it never found the correct definition in a shared submodule.

The first diagnostic question should be whether that definition was available. Then ask whether the agent had a useful way to navigate to it, and whether the tests exposed the mistake. Only after that can you judge how well the model reasoned with the information it had.

A developer's familiar workspace can hide how much setup matters. Shared dependencies, generated code, a working language server, and a running application are part of the development environment. A newly provisioned agent workspace needs an explicit equivalent for the task it is doing.

The submodule detail is concrete. Git provides clone --recurse-submodules to initialize and clone them, or submodule update --init --recursive after cloning. Which paths and credentials the agent should receive is a repository setup decision, not something to leave implicit.^[4]

This does not prove that context causes every bad PR. It gives you a preventable failure to eliminate.

Context Has Three Layers

Structural context. Does the agent have the relevant repository, submodules, shared libraries, and build instructions? A concise repository guide should explain where important definitions live and how to work with them. It should point to source rather than attempt to copy the entire codebase into an instruction file.

Navigational context. Can it find the definition behind a name, the callers of a function, or the implementation behind an interface? Text search is a useful primitive. Symbol navigation and dependency indexes answer additional questions. I would choose the tools by the mistakes they prevent, not assume either grep or a graph wins every task.

Operational context. Can it run the checks that tell it whether the change works? A test command, application server, linter, or browser session can turn an assumption into observable feedback. If the required service is unavailable, the agent should report that limitation instead of treating unexecuted code as verified.

These layers are a practical diagnostic framework. They do not replace model capability. They help separate missing evidence from bad reasoning.

The Maintenance Burden Splits in Two

Infrastructure and context have different maintenance rhythms. An execution environment can become repeatable once it is configured, although dependencies, security updates, and capacity still require work. Context also changes whenever the organization changes: a shared type moves, a policy is revised, a service is retired, or the team changes its preferred workflow.

In the conversations behind the original essay, engineers described reviewing agent PRs, updating instruction files, and adding verification steps. Those accounts motivated the argument; they are not a representative survey or a promise that infrastructure stabilizes in a week.

The practical question for an agent platform is who owns this loop. Who notices stale guidance? Who decides a correction should become a test rather than another paragraph in a prompt? Who removes the old rule when it conflicts with the new one?

Every correction need not become permanent memory. Sometimes the best fix is a deterministic check. Sometimes it is a better tool description. Sometimes the agent needs less context because two documents disagree.

The Harness Is Part of the Product

I still think the harness deserves more attention than the prompt. Tool access, persistence, recovery, permissions, and review determine what an agent can actually accomplish.

Anthropic's Managed Agents design makes this distinction explicit. It stores recoverable events outside the active context window and lets the harness retrieve them as needed. The session remains durable while the harness controls what the model sees. That is a useful separation between retaining evidence and presenting all of it at once.^[2]

A product can implement that machinery. It cannot decide, without configuration or feedback, which internal policy is authoritative or which historical workaround should be forgotten. The harness needs both retrieval mechanisms and a way to correct the knowledge they retrieve.

At Tembo, we're building around this separation: run coding agents such as Claude Code, Codex, and Pi in cloud environments connected to repositories, tickets, and team tools, with work returned for review. Tembo also offers self-hosted deployment for teams operating the platform inside their own infrastructure.^[5]

Disclosure: I'm Tembo's CEO and co-founder.^[6] My product thesis is that execution, context connections, and review need a shared home where the team can keep improving its workflow as individual agents change. When evaluating a platform like Tembo, ask how a correction to one task becomes a better setup for the next: an updated repository instruction, a maintained integration, a reproducible environment, or a new verification step. Those are concrete decisions a buyer can inspect.

Memory Ships; Reliable Organizational Learning Takes More

The original essay described Claude Code memory as an append-only file and suggested useful memory was barely shipping. Current documentation supports a more concrete account: Claude Code maintains editable project memory files, uses MEMORY.md as an index, and reads topic files when needed. The startup index is bounded to the first 200 lines or 25KB, whichever comes first, and the system prompts it to consolidate material near that limit.^[7]

That is a real capability. It is also different from guaranteeing that an agent recalls the right fact, recognizes when the fact changed, and applies it only to the people allowed to see it.

Research is testing those harder questions. The May 2026 LongMemEval-V2 preprint evaluates environment experience through 451 questions about state, workflows, gotchas, and premise awareness. Its best reported method reaches 72.5% average accuracy in that evaluation, with substantial latency costs. That result is evidence of both progress and remaining limitations; it is not a score for every commercial memory product.^[8]

My preferred starting point is a bounded workflow. Define what the agent should remember, how a changed fact supersedes an old one, and how you will test whether retrieval improved the result. “Remember how to run this service's integration tests” is an easier outcome to evaluate than “understand the company.”

Narrow scope does not make learning automatic. It makes errors visible enough to fix.

Personal Context Needs Shared Policy

People work differently. I favor personal preferences and working context when those differences matter: one person wants a brief explanation, another wants a detailed review; one team uses a different test harness from its neighbor.

That does not require a separate physical agent process for every person. Nor does it mean shared agents are fundamentally broken. A shared service can maintain separate identities, permissions, and preferences. The design requirement is to keep those boundaries clear.

Personalization should not let an individual override organizational access controls or invent a new definition of a passing build. Keep preferences adjustable and critical policies enforceable.

Claude Code's documentation makes a useful distinction here: instruction and memory files guide model behavior but are not enforced configuration. It recommends a tool hook when an action must be blocked regardless of the model's choice. The general design lesson is to separate advice from enforcement.^[7]

Build Versus Buy Is a Maintenance Decision

One CTO I spoke with for the original essay tried to buy a solution. His engineer said, “code is cheap, I'll just build it,” and produced a working system in days. That is an anecdote about a particular team, not a universal implementation estimate.

The interesting question starts after the prototype. Who operates it when credentials expire? Who handles a model change? Who tests whether a retrieved policy is stale? Who helps the next team use it without inheriting the first team's assumptions?

A paid product has to earn its price through capabilities or maintenance that the customer would otherwise own. A prototype and a durable service are different things to evaluate, even when both produce an impressive first demonstration.

The Case for Forward-Deployed Engineering

The Palantir analogy remains useful to me. Its Q4 2023 business update described AIP Bootcamps in which customers built alongside Palantir engineers using their own operational use cases. That is a documented example of hands-on implementation, rather than evidence that every agent deployment requires the same commercial model.^[9]

My hypothesis is that embedded engineering has an advantage when the hardest work is discovering an organization's data, exceptions, and approval paths. The engineer helps turn those details into a repeatable system and teaches the customer how to maintain it.

It is expensive. It also needs an exit condition: the customer should gain a maintainable workflow, not a permanent dependence on someone manually supplying the missing context. Teams with strong internal platform capabilities may do this themselves; standardized workflows may fit a self-serve product.

The buying question is ownership. Someone has to keep the context useful. The contract should make clear who that is.

The Map Is Your Job

Before blaming a model for an agent's failure, inspect its workspace. Check the files it could access, the instructions it loaded, the tools it used, and the feedback it received. Then improve the part that failed and rerun a comparable task.

My bet is that this loop will keep mattering even as models and context products improve. Repository maps, memory systems, and managed harnesses reduce work. They do not remove the need to decide what is correct for your team.

The codebase is the territory. The agent needs a map. Your job is to keep that map useful.

Companion Essays

The original argument also appears in these shorter posts. They retain their own publication history:

• The Agent Made a New Type Instead of Finding the Real One
• Three Layers of Agent Context, and Most Agents Have Zero
• The Submodule Problem Is the Whole Problem in Miniature
• Two Maintenance Curves: Infrastructure Decreases, Context Never Stops
• The Harness Is the Product. The Prompt Is Cheap.
• Agent Memory Is Unsolved. Workflow-Scoped Learning Is Not.
• Each Person Needs Their Own Agent Instance
• Controllability Is Not Optional
• Agent Build Versus Buy: Why Engineers Keep Building It Themselves
• The Forward-Deployed Model Is the Only One That Actually Works
• The Codebase Is the Territory. The Agent Needs a Map.

— Ry