Frequently Asked Questions About Walsenuk Stop Babysitting Agents Framework
22 answers covering everything from basics to advanced usage.
// Basics
What is the Context Ladder?
The Context Ladder is the progression of AI adoption maturity: (a) Fancy Autocomplete with no agentic loops; (b) You Are the Context Engine, where you trigger every job and correct every output; (c) Curated Context Layer of static files like CLAUDE.md; (d) Context Engine with runtime, multi-surface, personalised retrieval; (e) Fully Autonomous Agents. Most teams sit at stage (b) or (c).
What is a Research Packet?
A Research Packet is the token-optimised, conflict-resolved, permission-scoped output the Context Engine delivers to an agent before execution. It contains exactly the org-specific facts the agent needs to plan and act correctly — the canonical pattern, the shared service, the correct entry points — and nothing more. It's the opposite of dumping everything into the prompt.
What is a social graph and why does it matter for retrieval?
A social graph is a map of engineers as nodes and collaboration signals — PR reviews, co-authorship, service ownership — as edges. It's the pivot point for personalised retrieval: it turns a vague query into a precisely scoped one by knowing who's asking, which codebases they own, and who reviews their PRs. Generate it procedurally from your repo, never by hand.
What is the doom loop?
The doom loop is the babysitting cycle where an engineer repeatedly corrects an agent's output — pointing at files, explaining org patterns, re-running prompts — because the agent lacks the context to get it right autonomously. The entire framework exists to break this loop by externalising the human's context-supplying role into a machine.
// How To
How do I diagnose which stage of the Context Ladder my team is on?
Be honest about your daily behaviour. If you have no agentic loops, you're at Fancy Autocomplete. If you trigger every job and correct every output, you're at You Are the Context Engine. If you maintain CLAUDE.md or a docs repo agents read, you're at Curated Context Layer. Runtime, personalised, multi-surface retrieval means you've reached the Context Engine stage.
How do I audit my systems of record for context surfaces?
List every place useful engineering context lives: GitHub for PRs, commit history and code patterns; Slack or Teams for decisions, CTO overrides and tribal knowledge; Jira or Linear for tickets and priorities; internal docs and runbooks; and SaaS integrations. Don't assume your static repo covers this — it captures neither runtime signals nor conversational decisions.
How do I implement exhaustive retrieval instead of naive RAG?
Build retrieval that (1) constructs a structured research query from the agent's intent, (2) fans out across all systems of record in parallel, (3) runs exhaustively until no new relevant signals remain, and (4) reasons across results before returning anything. Don't stand up a single vector store and call it done — that triggers Satisfaction of Search.
How do I implement conflict resolution logic?
When two sources contradict — code in main versus a Slack thread saying it was implemented wrong — apply authority-weighting rules: recency, role (CTO outranks a peer comment), and canonicity (official doc outranks off-hand message). Surface both the conflict and the resolution to the agent with citations. Never silently pick one. Log conflicts for human review as architectural signals.
How do I structure agent execution around the Context Engine?
Use the engine at two junctures: before execution to produce a correct, org-aware plan, and at code review to evaluate output against real patterns, past decisions, and current truth. Execution runs in the middle with the plan as its harness. This three-phase loop — Plan with Engine → Execute → Review with Engine — produces merge-ready PRs.
// Troubleshooting
Why does my agent keep getting rejected at PR review?
Almost always because it's suffering Satisfaction of Search — it found a plausible approach immediately and never located your canonical implementation or shared service layer. The agent writes from scratch, ignoring existing patterns, and a senior engineer rejects it. Add a pre-execution exhaustive retrieval step that names the factory pattern, shared services, and correct entry points.
My agent has MCP access to all our tools but still produces wrong code. Why?
Access is not understanding. MCP pipes let the agent reach your data but it still doesn't know what it doesn't know — exactly like a day-one engineer unaware a shared utility exists. You need a retrieval layer that reasons across surfaces and proactively surfaces canonical patterns, not just connectivity. Pipes are necessary but not sufficient.
The agent picked the wrong approach when two docs disagreed. How do I fix it?
You're hiding conflicts instead of resolving them. When sources contradict and you let the agent choose, it picks wrong and produces confidently wrong output. Implement conflict resolution that detects contradictions, applies authority-weighting (role, recency, canonicity), and delivers the settled truth with citations in the research packet before the agent ever acts.
My context answers feel stale even though I cached them. What went wrong?
Caching context answers is the mistake — cached answers decay almost immediately in active codebases. A cached correct answer becomes a confident lie by the next day because something in the code, a Slack decision, or a ticket changed. Remove answer caching and optimise for latency through better retrieval architecture instead.
// Comparisons
How is a Context Engine different from naive RAG over a docs store?
Naive RAG triggers Satisfaction of Search: it stops at the first plausible chunk and produces confident but wrong output. A Context Engine fans out across all systems of record, runs exhaustively, resolves conflicts with authority-weighting, enforces permissions, and compresses to a token-optimised packet. RAG gives you a plausible snippet; the Context Engine gives you settled, scoped, current truth.
Is a Curated Context Layer like CLAUDE.md enough?
No. Static content has no runtime signals, goes stale, and requires manual maintenance. CLAUDE.md and agents.md are better than nothing but they can't capture conversational decisions, CTO overrides in Slack, or who owns which service today. They're an intermediate stage on the Context Ladder, not the destination.
How does the Context Engine approach compare to just using a bigger model?
A bigger model with no org context still doesn't know your factory pattern, your shared service layer, or the CTO's Slack override — it will confidently reinvent them. The bottleneck is context, not model capability. Investing in exhaustive, conflict-resolved, personalised retrieval up front improves plan quality, code accuracy, and merge-readiness far more than raw model horsepower.
Why not just stuff everything into a large context window instead of building an engine?
Because large context windows don't help agents reason — they cause them to fail. A million-token dump degrades reasoning quality and inflates cost, while a small high-signal packet produces better plans and cheaper runs. Token optimisation is what makes background agents economically viable; brute-force context is what makes them uneconomical and unreliable.
// Advanced
How do I enforce data governance in a Context Engine?
Carry auth context — an OAuth model — through every retrieval call. Private Slack DMs, restricted channels, and confidential data must never surface to a requester lacking permission, even if the query would benefit. Design the engine to return only what the requesting identity is authorised to see. For orgs of 20+ people this is not optional and must be built in from day one, never retrofitted.
Can the Context Engine serve more than just background agents?
Yes, and this is where compounding leverage comes from. The same engine can power Ask Engineering Slack channels that auto-detect questions, score confidence and respond, plus ticket enrichment, incident triage, and human engineers asking ad-hoc questions. A single well-built engine serves both agent and human surfaces across the org.
Why should the social graph be generated procedurally rather than maintained by hand?
Because manual maintenance decays like any static doc and never keeps pace with real collaboration patterns. Point an automated tool at your code repo to generate the graph from PR reviews, co-authorship, and service ownership. This keeps it accurate and current, so retrieval always scopes to the right people, codebases, and history for the specific engineer asking.
How does token optimisation actually improve agent output?
The engine reasons across all retrieved surfaces, strips redundancy, resolves conflicts, and returns only the minimum high-signal content the agent needs. This prevents the reasoning degradation caused by bloated context and cuts cost per run. Smaller, curated packets produce better plans and merge-ready code — the compression step is a feature, not a limitation.
What role does the social graph play in personalised retrieval?
The social graph is the pivot point that turns a vague prompt into a precisely scoped research query. By knowing who the engineer is, which codebases they own, who reviews their PRs, and what they mean by an ambiguous request, the engine scopes retrieval to the right services, people, and history — rather than treating all engineers and queries as identical.