Context Engineering Patterns & LangChain's Sandbox Architecture

Teresa Torres - Context Engineering: 5 Familiar Strategies from Real Product Work#

Source: https://www.producttalk.org/context-engineering/ Credibility: High (detailed framework mapping PM practices to AI context management)

What happened: Teresa published a framework translating continuous discovery practices into context engineering strategies for AI products. The core insight: context engineering is product management under new constraints—many PM practices map directly to managing AI context.

The five strategies and their AI translations:

1. User interviews → Prompt engineering: Discovery interviews extract mental models from users. Prompt engineering extracts desired behavior from models. The parallel: both require iterative refinement based on what you learn from responses.

PM practice: Ask open-ended questions, listen for patterns, refine questions based on answers. AI translation: Write prompts, observe outputs, refine prompts based on model behavior.

2. Assumption mapping → Model limitation testing: Discovery maps assumptions about user needs. Context engineering maps assumptions about model capabilities. Both identify what might be wrong before it breaks in production.

PM practice: List assumptions, test riskiest first, update based on evidence. AI translation: Identify edge cases, test systematically, document failure modes.

3. Continuous feedback → Context monitoring: Discovery uses ongoing user feedback to validate direction. Context engineering uses production traces to validate model behavior.

PM practice: Weekly user interviews, support ticket analysis, usage data review. AI translation: LLM trace analysis (from Jan 20 LangSmith Insights), production monitoring, error pattern clustering.

4. Opportunity solution trees → Context hierarchies: Discovery structures problems into trees of opportunities and solutions. Context engineering structures information into hierarchies (global context, task context, immediate context).

PM practice: Map user problems to potential solutions, prioritize branches. AI translation: Structure prompts with system instructions (global), task description (branch), and immediate query (leaf).

5. Rapid experimentation → A/B testing prompts: Discovery validates assumptions through small experiments. Context engineering tests prompt variations systematically.

PM practice: Ship small changes, measure impact, iterate. AI translation: Test prompt variants, compare outputs, adopt better patterns.

Why the analogy matters: Teresa argues context engineering isn't a new discipline—it's PM work applied to a different surface. PMs already know how to manage uncertainty, validate assumptions, and iterate based on evidence. Those skills transfer directly.

Why it matters for PMs: This reframes AI product work from "learn new technical skills" to "apply existing PM practices to new constraints." For PMs intimidated by AI, the message is: you already have the skills; context windows are just a different kind of constraint than engineering capacity or user attention.

Critical questions:

• Where does the analogy break? Which PM practices DON'T transfer to context engineering?
• How do you balance "treat it like familiar PM work" versus "respect AI's unique constraints"?
• Which of the five strategies actually accelerates AI product development versus which are just conceptual mappings?

Action you could take today: Pick one AI feature you're building or planning. Apply Teresa's assumption mapping practice: list 5 assumptions about how the model will behave, rank them by risk, and test the riskiest assumption today with a simple prompt experiment.

LangChain - The Two Patterns by Which Agents Connect Sandboxes#

Source: https://blog.langchain.com/the-two-patterns-by-which-agents-connect-sandboxes/ Credibility: High (detailed technical architecture with specific implementation patterns)

What happened: LangChain documented the two fundamental patterns for agent-sandbox integration—revealing architectural choices that determine agent capabilities and failure modes.

The two patterns:

Pattern 1: Agent-controlled sandbox (tool-based)

• Agent decides when to execute code
• Sandbox is a tool the agent invokes
• Agent interprets results and decides next steps
• Example: Agent writes Python → calls sandbox API → receives output → continues reasoning

Architecture:

Agent → Tool invocation → Sandbox execution → Result → Agent reasoning

Strengths:

• Agent maintains full control over workflow
• Can retry or adjust based on execution results
• Composable with other tools (browser, APIs, file access)

Weaknesses:

• Agent must understand when to use sandbox (can forget or misuse)
• Every sandbox invocation is a separate LLM call (latency, cost)
• Context overhead—sandbox results consume agent context

Pattern 2: Sandbox-controlled agent (environment-based)

• Agent runs INSIDE the sandbox environment
• All agent actions happen within isolated context
• Sandbox provides tools; agent operates within boundaries
• Example: Agent deployed in VM with filesystem, network, tools pre-configured

Architecture:

Sandbox environment → Agent runs inside → Uses local tools → Returns results

Strengths:

• Agent can't escape sandbox boundaries (security)
• No tool invocation overhead (agent has direct access)
• State persists across agent steps (filesystem, memory)

Weaknesses:

• More complex deployment (need to provision and manage sandboxes)
• Harder to observe agent behavior (happening inside black box)
• Resource constraints apply to entire agent (memory, CPU)

When to use each pattern:

Tool-based (Pattern 1) when:

• Agent needs multiple specialized environments
• Security boundaries between tools matter
• Observability is critical (need to see every step)
• Cost optimization required (spin up sandbox only when needed)

Environment-based (Pattern 2) when:

• Agent needs persistent state across steps
• Security requires full isolation (can't trust agent with outside access)
• Performance matters (eliminate tool invocation latency)
• Agent workload is predictable (can provision resources appropriately)

Real-world examples cited:

• E2B, Runloop: Environment-based (agent runs inside VM)
• Vercel Sandboxes (from Jan 31): Tool-based (agent calls sandbox API)
• LangChain (via LangGraph): Supports both patterns

Why it matters for PMs: This documents the infrastructure decision that determines what your agent can do. The pattern you choose shapes agent capabilities, security model, observability, and cost structure. For PMs planning agent features, the question is: does your agent need persistent state and isolation (environment-based) or composable tools with full observability (tool-based)?

Critical questions:

• Can you switch patterns later, or does the initial choice lock you in?
• What's the cost structure difference between patterns at scale?
• How do debugging and error recovery differ between the two?
• Which pattern better supports multi-agent orchestration (from Jan 30 patterns)?

Action you could take today: If you're building agents that execute code, map your requirements to these two patterns. Do you need persistent state? Full isolation? Observability of every step? Cost optimization? Your answers determine which pattern fits.

Lenny Rachitsky - Claude Opus 4.6 vs. GPT-5.3 Codex: Shipping 93,000 Lines#

Source: https://www.lennysnewsletter.com/p/claude-opus-46-vs-gpt-53-codex-how Credibility: High (detailed first-person comparison with concrete project outcomes)

What happened: Lenny published a comprehensive comparison of Claude Opus 4.6 versus GPT-5.3 Codex for a real project—shipping 93,000 lines of code for a production application. The comparison reveals model-specific strengths beyond generic benchmarks.

Key findings from real project work:

Code generation quality:

• Claude Opus 4.6: More verbose, includes extensive comments and documentation inline
• GPT-5.3 Codex: Terser code, assumes developer familiarity with patterns
• Result: Claude output required less explanation but more pruning; GPT required more context but shipped faster

Context handling:

• Claude: Better at maintaining consistency across large codebases (remembers architectural decisions)
• GPT: Faster iteration but occasionally "forgets" constraints from earlier in conversation
• Pattern: Claude's advantage grows with project complexity (more files, longer sessions)

Tool use and debugging:

• Claude: More conservative—asks for confirmation before running destructive operations
• GPT: More aggressive—executes and adjusts based on errors
• Tradeoff: Claude safer but slower; GPT faster but requires more supervision

The 93,000 line breakdown:

• Total: ~60% generated directly by models, 40% human-written or heavily modified
• Claude: Better for scaffolding and boilerplate (generated ~35,000 lines with minimal edits)
• GPT: Better for algorithm-heavy logic and performance-critical code (generated ~20,000 lines)
• Hybrid approach: Used both models for different parts of the codebase

Cost and latency comparison:

• Claude: Higher per-token cost but fewer retries (higher first-attempt accuracy)
• GPT: Lower per-token cost but more iterations required
• Net cost: Roughly equivalent for this project (~$450 total)
• Latency: GPT faster per response; Claude faster to completion (fewer retries)

Why it matters for PMs: This provides real-world data on model selection beyond benchmarks. The insight: different models excel at different stages of development. For PMs planning AI-assisted development, the question isn't "which model is best?" but "which model for which part of the workflow?"

Critical questions:

• How much of the productivity gain came from the models versus Lenny's existing coding knowledge?
• What's the maintenance burden of 93,000 lines of AI-generated code?
• Does the hybrid approach (using multiple models) create consistency issues in the codebase?

Action you could take today: If you're using AI coding tools, try model comparison on a real task—not a benchmark. Use Claude for one feature, GPT for another similar feature, and compare: time to completion, code quality, and iteration count. This calibrates which model fits your team's workflow.