The hosts define context engineering as getting all and only the relevant context into each LLM call. That spans prompt engineering, RAG, memory, conversation history, and structured output. Irrelevant tokens measurably lower task success, even where needle-in-a-haystack retrieval is “solved”. Following Karpathy’s “LLM as OS” (context window = RAM), the pillars are write, select, and compress. Practices drawn from Manus’s and LangChain’s blog posts:
- sub-agents that read big files and return only an answer or snippet;
- a stable prompt prefix for KV caching;
- logit masking instead of swapping tool sets;
- the file system as memory before any vector DB;
- “recitation” via to-do files and plans;
- manual hooks that inject guidelines;
- keeping tool errors in context, and richer API errors for agents;
- focused compaction, or dump-to-files then reset. Pitfall: jumping to multi-agent systems; most successful agents are a single agent plus narrow helpers. Check: if reading your traces means lots of scrolling past noise, your context engineering needs work.
Show: langtalks
Concepts: context-engineering · agent-memory · multi-agent-orchestration · llm-cost-optimization