Comment by dvt | Hacker News Reader

Comment by dvt | Hacker News Reader

I think this space is very untapped. Models are interesting, but I am absolutely obsessed with some things I've been researching/working on for the past few years:

Fractal tool discovery: tool taxonomy where an agent can "drill deeper" to find what specific tool it's looking for. Helps if/when polluting context with a zillion (mostly unnecessary) tools.

Leveraging splay trees: this is my favorite data structure and I think relatively unused in the context of agents/harnesses. A lot of times, recently-used workflows/tool-chains will be used again, so having those at the top of the search hierarchy is an awesome optimization.

Virtual containerized notebooks: models working in sandboxed (WASI) Python notebooks is incredible. Even local models (if given enough time) will usually converge on a good solution. Being able to mount tools/resources/fs is again, imo quite untapped. Some problems here are running native things (thing numpy/pandas) in containers is a nightmare (or impossible).

Anyway, happy to see other folks seriously doing stuff in this space. If anyone wants to collaborate on anything don't hesitate to reach out :) I'm also actively looking for a job or some contract gigs.

Fun times ahead.

> Helps if/when polluting context with a zillion (mostly unnecessary) tools.

Ugh, I can't help but respond to this one point. The fact that this is even an issue in the current year just tells us how screwed the software field is in a lot of ways. I don't mean that in existential terms, but of how divided we've become in terms of what's happened to human reasoning. On the one hand, you have people who apply deep thinking to develop the sort of approaches you described, and there's the exponentially growing segment of not-even-programmers who seem to never ask themselves whether any of their ideas have any sort of consequences.

Take MCPs for instance. Sure, I guess it can sometimes make sense to have a stateful API that is optimized for agents. Yet, more often than not, these MCPs frontload a ton of context where it's not needed, and solve problems where none existed. Merely sticking an API (MCP) in front of an API (CLI, REST, GraphQL) without a benefit that can be explained in a single sentence is lunacy and demonstrates a real lack of complex thinking.

MCP’s make sense because, people want to click the + icon on chatgpt or claude to connect their data. nobody cares if you can do it manually

> tells us how screwed the software field is in a lot of ways

But, you just very clearly described why human software engineers are in higher demand than ever before.

It's always been "screwed" in the sense that everyone else sucks at wielding the power.

What we're actually witnessing is a watershed moment where a lot of technologically illiterate people are getting left behind. Those of us on the literate side are left to fight amongst ourselves and the powers that be for control over the future. We have actually been doing an alright job all things considered (else this conversation wouldn't be happening). Politicians are aging out and we're the adults in the room now.

Your point is valid for individual developers or small teams of technical folks.

However, MCPs are a godsend to anyone trying to manage access to systems (especially SaaS systems) in a large organization that includes a ton of non-technical employees. We use at least a couple of SaaS products where RBAC is severely limited in what it can govern or where API keys do not have any kind of governance so handing one out is basically handing out read/write on the entire system. Being able to configure an MCP to only have read endpoints enabled it a very useful piece of duct tape. Obviously it would be great if the underlying API was just designed with proper governance but that's out of the user's control.

Isn't that what codemode is for?

mcp with 2 tools: execute(code) and search(query)

all other tools, mcps, apis, whatever are encapsulated by the one interface. new tools don't bloat the agent's context, and it can write its own code to perform more advanced and batch operations against the available tools (executed within a sandbox).

executor is a great implementation of this - https://executor.sh

opencode v2 also provides its own native implementation

Have you had workflows/benchmarks to test this on? I'm primarily interested if there are real use cases that would benefit.

Fractal tool discovery is a fascinating idea! Have you worked on implimenting this into any agent harnesses already to any success? My first impression is allowing the agent to fork itself, not unlike launching a subagent, then returning it's response back to the main agent.

I've also explored s/Fractal tool discovery/Skill tree approaches, seems to work pretty well when you stick the equivalent of XREFs in the frontmatter.

What makes it fractal?

It's kind of self-expanding/looping; fractal is just a cute name I like, but it's technically a directed cyclic graph (since you always have/want cycles).

I think recursive fits better, but I get it.

It’s more so the divide and conquer. Recursion vs iterative is tangential.

But not fractal, because that implies self-similarity independent of scale

I've always referred to it in UX terms. "Progressive Disclosure" -- It pulls more context as needed.

In this way, I tend to think of the context environment on an agent is the "agent nav" -- it presents context, allows progressive disclosure, and if poorly designed, makes the agent flounder as a poorly designed UI/UX does.

i have found agents to be excellent at using CLIs, which are fractal-like. i built this reddit ads api cli and my agent immediately starting introspecting it in a "drill deeper" manner:

https://github.com/genei-Ltd/reddit-ads-cli

bonus if it spits out Double Kill, Mega Kill, GodLike! when saving tokens

Reply on news.ycombinator.com