Hacker News Reader

Comment by tptacek | Hacker News Reader

This is great. I feel like most of the oxygen is going to go to the sandboxing question (fair enough). But I'm kind of obsessed with what agent loops for engineering tasks that aren't coding look like, and also the tweaks you need for agent loops that handle large amounts of anything (source code lines, raw metrics or oTel span data, whatever).

There was an interval where the notion of "context engineering" came into fashion, and we quickly dunked all over it (I don't blame anybody for that; "prompt engineering" seemed pretty cringe-y to me), but there's definitely something to the engineering problems of managing a fixed-size context window while iterating indefinitely through a complex problem, and there's all sorts of tricks for handling it.

View on HN

Huggingface has a series on Tiny Agents[1] where they go into a minimal version of the loop with tools.

I’ve been working on a weekend project building one of these and the tools you provide are what makes the agent suitable for the task.

Even small models and non tool models can use MCP with correct prompting, but you have to edit what tools they can use.

Context is the big bottleneck to manage. Programming agents benefit from knowing shell commands, but generic agents you have to teach/trick into the right interactions, which burns context. Then out of the box an agent will want to read everything, so I have to comment which commands are expensive or cheap context wise.

My project is almost ready to explore context management methods: things like removing old files from memory, warning the agent about limits, using a second agent that does compaction.

It would be cool to eventually RLHF the agents too, but that’s unlikely with my weekend project budget.

[1] https://huggingface.co/learn/mcp-course/en/unit2/tiny-agents

I can imagine an agentic loop that updates dependencies à la Dependabot/Renovate-style by going through the changelog of a new version, reviewing new code changes, and evaluating whether it's worth it to upgrade (or even dangerous to do so, either from stability or security point of view). Too often these tools are used to blindly respin builds with the latest and greatest versions, which is what gets most people in trouble when their NPM deps become malicious.

You should write it! You might be surprised how easy it is to get something working.

Ha, well look at that, not even a day later: https://fossa.com/blog/fossabot-dependency-upgrade-ai-agent/

We have a GH workflow that spins up Claude with a prompt like this and it works quite well:

—

You are going to create a summary of the important changes for a PR created by dependabot:

1. Read the body of PR $ARGUMENTS with the `gh` cmdline tool. 2. Create a todo list for yourself for each package in PLAN.md. 3. For each todo, read the releases page(s) (add /releases to the github repo url) to cover the update range. 4. Summarize breaking changes and CVE updates, see template at the end. Grouped into Dev Dependencies and Production Dependencies. 5. For production dependencies, find code usages (with `rg`/`grep`) and determine if breaking changes will affect us. Add a list of all found usages, linking to the direct line on github (like https://github.com/solarmonkey/app/blob/master/frontend/some...). Finish each with a verdict: unsure/likely OK/*may break*/*SURELY BREAKING*! 6. Fill the table up top with the verdicts 7. Write the filled out template to `deps_update_analysis.md`. Don't add a final summary or conclusive thoughts. The template is all we need.

[snip template to fill]

I use agentic loops for document and spreadsheet (aka bullshit to interface with non engineers in the company) since my model of choice is adept at markdown and csv, and the office software can import and export those.

Reply on news.ycombinator.com