Agent runs leave a surprising amount of useful material behind: commands, failed approaches, decisions, setup state, and small discoveries that never reach the project documentation. Several projects make that history reusable without dragging all of it into the next prompt.
Searching old coding sessions
cass, short for coding-agent session search, searches sessions accumulated across several coding-agent tools.
Those logs can contain commands, failed attempts, file paths, decisions, and explanations that exist nowhere else. If you have many sessions spread across several tools; cass puts a search layer over that fragmented local history.
Search makes otherwise-lost work retrievable. Deciding which findings belong in project documentation is still a manual step, and probably should be.
A narrower browser loop
Dev Browser is Sawyer Hood’s lower-context alternative to his Playwright MCP workflow.
The context cost of browser tools is easy to underestimate. Accessibility trees, DOM snapshots, screenshots, and tool definitions can chew up a ton of context before the agent even reaches the application code.
A smaller interface will be less general, but that may be an advantage for coding work. The common loop is usually: open the local page, inspect a problem, use a few controls, read the errors, and verify the fix.
Memory with hooks and SQLite
This Claude Code memory plugin uses hooks, SQLite, meaning-based search, and keyword search.
The components and the pipeline are straight forward. Hooks capture events, SQLite stores them, and two retrieval methods provide different routes back through the history.
Memory quality remains the harder problem. Keeping everything makes retrieval noisy and can preserve obsolete instructions. A useful system needs deletion and correction, along with some way to distinguish a durable lesson from a one-off detail.
Armin Ronacher’s comparison of Claude Skills and dynamic MCP tool loadouts comes at context use from another angle. His claim is that Skills work better in his workflows. In the comparison, a Skill packages instructions and supporting files, while MCP exposes external capabilities and data.
Skills and MCP can complement each other. A skill can describe when and how to do a task while an MCP server performs the external operation. They differ in discovery, context cost, reliability, and maintenance.
Too many tools
HKUDS open-sourced AnyTool, which the project describes as a universal tool-use layer for agents.
It targets the same selection problem raised by just-in-time tool discovery methods. Giving agents access to tools is getting easier; choosing among them is getting harder. A large catalog adds context overhead and creates more chances to select an almost-right action.
A separate tool-selection service can reduce that load, but it becomes one more component to test. A useful trace should show which tools it considered, why it chose one, and whether it missed a capability the task needed.
Setting up long-running work
This post summarizes an Anthropic runtime pattern for long-running coding agents that separates an initializer agent from the coding agent doing the implementation.
Setup has different failure modes from implementation: installing dependencies, reading instructions, establishing state, and preparing a clean handoff. Making initialization an explicit phase lets that state and those artifacts be inspected before coding starts, and should make later runs more repeatable.
A good initializer leaves the repository and task understandable to the next agent instead of relying on hidden conversational context.
Reusable model-based reviewers
The Agent Skills for Context Engineering repository added skills that use an LLM to review and score output. Packaging the review procedure as a skill keeps its instructions reusable and near the workflow being checked.
The examples and scoring rules show how the reviewer works. Putting the reviewer in a skill makes it portable. Comparing its scores with human reviews on real examples will tell us how well it actually performs.