Stop babysitting your agents — Brandon Waselnuk, Unblocked

Analyzed: 2026-05-27

Actionable Insights

• Build a “context packet” before agent execution. For each high-value task, generate a small packet with relevant repos/files, owned services, architectural patterns, recent PRs, Slack/docs decisions, and likely reviewers. Start with a script that collects README, AGENTS.md/CLAUDE.md, recent merged PRs, and grep results for the target service. Evaluate by comparing first-pass PR acceptance and tokens spent.
• Do not call naive RAG a context engine. If your retrieval only returns semantically similar docs, add entity relationships: service → owner → API → incidents → decisions → PRs. Tools to consider: Neo4j/GraphRAG-style approaches, LangChain context-engineering patterns, and code graph indexes. Caution: graphs need freshness and conflict resolution, not just ingestion.
• Use social/ownership signals to resolve ambiguity. The talk’s social graph point is operational: when code, docs, and chat conflict, the likely owner/approver matters. First step: map files to CODEOWNERS, recent PR authors, and Slack/channel references; show why each source was trusted.
• Compress context aggressively. The output to the coding agent should be “small but sufficient”: top 5 files, 3 decisions, 3 risks, 2 reviewers, 1 implementation path. Evaluate with ablations: agent with MCP access only vs. curated packet.
• Make context provenance visible. Include citations to docs, PRs, and conversations in the agent prompt or side panel. This lets engineers reject stale or irrelevant context early.

Core thesis

Agents fail less because they get larger context windows or more tools; they fail less when organizations provide curated, conflict-aware, runtime context.

Big ideas / key insights

• The human engineer is currently the “context engine” for most coding agents.
• Static context files are useful but incomplete; runtime information from code, docs, tickets, conversations, ownership, and PR history matters.
• Access is not understanding: MCP connectors alone can flood an agent without helping it choose.
• Social graphs can help identify authority and relevance when sources conflict.

Best timestamped moments with interpretation

• 1:16–3:49: The speaker reframes engineers as context engines and proposes runtime synthesis.
• 4:49–7:22: Three myths: access, naive RAG, and huge context windows are not enough.
• 8:24–8:55: Social graph as a pivot for meaning and conflict resolution.
• 15:33: Screen shows node/edge social graph, grounding the ownership/relationship claim.

Practical takeaways / recommended workflow

• Convert the talk into one small experiment before adopting the whole worldview.
• Keep a baseline: current manual workflow, failure rate, token/cost/time, and reviewer acceptance.
• Add guardrails where the video shows automation: approval gates, source logging, rollback, RLS/permissions, and regression tests.
• Re-run after one week with real work, not demo prompts; compare shipped output quality and review burden.

Comment insights

The comment section is skeptical. The highest-liked comment calls it “mostly a sales pitch rather than engineering,” and another says the talk should have shown more of the engine. A more constructive commenter reframes the useful insight as “context-and-accountability,” not prompting. Several comments joke about the website returning 503, which weakens confidence in product maturity but not necessarily the architecture thesis.

Deep research on the main claims

External context-engineering sources from LangChain, Atlan, and Neo4j support the broader claim that RAG is only one component; agents need context selection, compression, isolation, provenance, and structured relationships. Unblocked’s own context-engine page claims it connects codebase, docs, and conversations into a knowledge graph; that is aligned but vendor-provided. Contradicting evidence: many teams get meaningful gains from simple AGENTS.md, repo maps, and targeted search before building a full graph. A context engine can become expensive shelfware if ownership data is stale or access controls are sloppy.

My verdicts on major claims

• Naive RAG is insufficient for coding agents — Agree, high confidence. Similarity search misses ownership, recency, and causal relationships. Practical takeaway: add graph/provenance before adding more documents.
• MCP/tool access is not understanding — Agree, high confidence. Connectors increase reachable data, not ranking quality.
• Social graph is important — Mixed, medium confidence. Useful for enterprise ambiguity, overkill for small repos. Overclaimed if used as a universal requirement.
• Context engines reduce babysitting — Mixed, medium confidence. Plausible, but the talk offers more framing than measured results.

Screen-level insights

• 0:46: Agenda slide sets up myths/lessons and the product framing.
• 10:26: Slide discusses multiple surfaces for humans/agents to interact with the context engine, matching the runtime-context thesis.
• 15:33: Graph visualization shows developers as nodes/edges; it visually supports using collaboration patterns as context signals.

My read / why it matters

The talk’s value is the architecture framing, not the product pitch. For most teams, start smaller: context packet + provenance + CODEOWNERS before buying/building a full context engine.

Verification notes

Four verification passes were applied before publishing: (1) source/evidence audit, checking transcript-backed claims against named sources; (2) transcript/comment/frame fidelity audit, ensuring timestamps and screen descriptions match extracted evidence; (3) hallucination/overclaim audit, downgrading unsupported “changes everything” style claims to practical hypotheses; and (4) Actionable Insights audit, confirming the top section is concrete, workflow-ready, link-backed where possible, and includes evaluation criteria and cautions. Named external sources checked: official product/docs pages where available; Claude Code hooks docs; Supabase pricing and RLS docs; LangChain/Atlan/Neo4j context-engineering explainers; EXO site/GitHub-facing materials; Railway/Hermes docs; public X recommendation-code commentary. I treated web snippets as corroborating context, not as stronger evidence than the transcript. Residual uncertainty: I did not execute the referenced products/tools live; claims about current product behavior should be rechecked in your environment.