Prompt Engineering Is Table Stakes. Context Engineering Is the Next Frontier.

Salesforce published something last week that I've been thinking about: they're drawing a distinction between prompt engineering (optimizing the question) and context engineering (optimizing the conditions under which the question is answered).

If you've been building with AI agents for more than a few months, this distinction probably resonates. I can tell you from experience: most agent failures aren't bad prompts. They're missing context, wrong context, or context the agent can't access when it needs it.

What Context Engineering Actually Covers

Context engineering is the practice of designing the information architecture around your agent. Specifically:

• Which data sources the agent can see — and when
• Which knowledge bases are current — and how to refresh them
• How much context fits in a single turn — and what happens when it doesn't
• What gets retrieved at query time — and how to verify retrieval quality

The last point is where it gets practical. Most RAG (Retrieval-Augmented Generation) setups optimize for recall — getting everything that might be relevant. But for agents, precision matters more. If you retrieve 50 documents and the agent has to synthesize them, you've added latency and noise. If you retrieve exactly 3 documents that directly answer the question, the agent is faster and more accurate.

The OpenClaw-Specific Context Problem

OpenClaw's memory system handles session state and file-based context. But when you're building agentic workflows, you have to think about context across several layers:

1. Session context — what's in the current conversation (OpenClaw handles this)
2. Agent memory — what the agent knows about this user/project from prior sessions
3. Tool context — what state the agent needs about external systems before calling tools
4. Domain context — domain-specific knowledge that should be available to the agent

Most agent failures I've seen come from gaps in the third layer. The agent can technically call the CRM API, but it doesn't know enough about the CRM's state to call it correctly. The tool works but the agent doesn't have the context to use it well.

A Concrete Example

I built an agent that manages server infrastructure. It has access to a monitoring tool, a deployment tool, and a log viewer. Sounds straightforward.

The failure mode: the agent would call the deployment tool without knowing the current deployment state. It would try to deploy when a deployment was already in progress. It would restart services that were already restarting. The tool worked. The context was missing.

The fix was adding a state check at the beginning of the workflow: "Before calling any operational tool, check the current state of the target system."

This isn't a prompt change. It's a context engineering change — ensuring the agent has the information it needs before it attempts operations.

The Practical Framework I Use

When I'm designing a new agentic workflow, I now ask:

1. What does the agent need to know before it can take the first action? (Initial context)
2. What does the agent need to know before each major tool call? (Pre-tool context)
3. What happens when context is missing or stale? (Context failure handling)
4. How does the agent verify context quality? (Context validation)

The last question is the one most people skip. If the agent retrieves context from a knowledge base, how does it know the retrieval is correct? This is where the MCP tool contract helps — the MCP server provides the context, and if the MCP server has a schema, the agent can at least validate that the returned data matches the expected structure.

---

Context engineering is harder than prompt engineering because it's specific to each workflow. But it's also more valuable — fixing a context gap can make an unreliable agent reliable without changing the model or the prompt at all.