Hacker News Reader

It's actually about context management. Calling a MCP tool will load a potentially huge json on your context window, maybe triggering a compaction. Using a subagent for that is less bad, but still expensive (and you wouldn't run every tool call on a subagent)

But if you had a mcp client cli, you can just pipe it to jq or whatever and extract what you need. or chain multiple tool calls into a single one. None of this will make the agent receive the intermediate text passed between those (the agent might want to save the intermediate results into temporary files however)

But shell scripting sucks. Javascript or Python is better suited for handling json and things like that. That's what is being called codemode.

Ok so.. it makes a lot of sense to integrate agents and programming languages. But right now, harnesses are more or less interchangeable and you can hop to another one very quickly. The more coupling between all those moving parts, the hard will lock-in hit. (just picture the mess that is Claude Code having a severe lock in on the ecosystem)

A little nit here, bash isn't the most elegant language, but shell languages have a very nice feature that makes them easier for Agents to write: they're executed left to right, in the same order the tokens are generated. Python/Javascript can execute out of token order (e.g. foo(bar(baz(bak(bat))))), which is more error prone. Additionally, shell is very terse and designed for duct-taping things together.

I think something like nushell is probably a better direction than trying to use python/javascript as a shell.

Maybe shell scripting doesn't suck (for agents). It sucks for people because it's very error prone (even though it's my favorite language actually), and my guess is that something like Typescript will measurably decrease tool call error rate just because the compiler can catch type errors etc. But, maybe bash is so "in distribution" that this doesn't matter

Well, as you're already referencing Python... Ynow that's solvable, right?

Pretty old libs around that played around with those concepts, especially in Python

https://pypi.org/project/plumbum/

I agree with most of what you said, but wanted to add that another point is there is a different level of trust in code executing from the harness, and code executing from the bash shell by the agent.

I block all network access from bash calls, but want to provide certain tools that can call certain services in a specific way. I can have a tool (or mcp) that does just that, and runs outside of the sandbox.

Yup this is 100% the best security measure we recommend clients & others, so they get better control over that single-point-of-access

It's more like this:

Right now when a model wants to call 1 or more tools, there is a fixed json schema to describe the tool calls.

Codemode is like: Why don't we just let the model write a program to call the tools and compose them however it wants? The key is that the programming language exposed to do this (usually javascript) will have APIs available to do some things internal to the harness (like call tools/mcp).

I agree. Harnesses are quickly becoming the next systems programming frontier. The OS analogy is apt and often made--just like browsers have been compared to becoming "platforms" and "OSes". Another analogy that is obvious is threads/processes and agents and sub-agents: all the concurrency, shared resource access, cooperative multitasking, etc problems are emerging again.

It will take some time to shake out, but lots of old ideas are new again. Personally, I'm mining lisp machines, homoiconicity, actor models, and other ideas for my harness designs.

> Maybe the answer is to partner LLMs with Common Lisp

Autolith (https://autolith.rocks/) and some other CL-based harnesses allow the LLM to modify their own harness within the session.

As a slight aside to this point...

Actually think this one-language-focus is the way forward, instead of training AIs for all languages under the sun it would be incredible to have models solving all issues via one very well understood/and-tooled-for language. I'm aware that the model training cross-benefits from different languages so obviously provisions would have to be made for the benefit of this to show.

> no simple system level picture

proceed to drop the word homoiconicity... Of course I know what it means without looking up

> Dan Ingalls who said "An operating system is a collection of things that don't fit into a language. There shouldn't be one."

Anil Madhavapeddy's take on such setups: A compiler that just refuses to stop.

  MirageOS is a system written in pure OCaml where not only do common network protocols and file systems and high-level things like web servers and web stacks can all be expressed in OCaml but the compiler just refuses to stop ... compiler, instead of stopping and generating a binary that you then run inside Linux or Windows, will continue to specialize the application that it is compiling and ... emit a full operating system that can just boot by itself.

https://signalsandthreads.com/what-is-an-operating-system / https://archive.vn/yLfkq

Still too many words in my opinion. It's really just 2 things.

1. Search: The server publishes its tools via a query interface and with gradual level of detail. This way an LLM can discover the tools it needs without loading the ones it doesn't into context. Saves context.

2. The LLM sends glue code when it needs to use multiple tools together. Said code gets executed by the MCP server itself, and it returns the result. Saves tool calls, which saves tokens.

On point 2: Imagine there's 2 tools in the server. One lists customers the other gives sales for a given customer. For a task like "add all the sales for the customers whose name begin with A".

With traditional MCP: the LLM has to use the MCP like a regular HTTP API: first get the customers (1 tool call). Then for every customer begining with A, get their sales (N tool cals). Then add all of the sales (potentially 1 tool call).

With code mode the LLM sends a single program. The program has code that does things like `customers = call_tool("get_customers"); for each c in customers do if customer.name.begins_with("A") then ...` etc etc. That code is sent to the server for execution. So for the LLM it counts as a single tool call.

On the downside, the "code execution" on the Server means that it is executing untrusted code coming directly from LLMs. In order to offer this confidently your MCP servers really needs a very tight sandbox in which to execute this "glue code".

Pardon my ignorance but I truly want to understand this. Don't harnesses and LLMs already do this? Like, I have seen an LLM via pi write and execute some python code to complete a task instead of running a regular bash command. Is this the same principle only more elaborated? Is codemode being presented to the LLM as yet another tool just like read,write,bash and so on?

Yes and no.

Yes part: LLMs have had the capability to generate code, including glue code, to do several steps in a single program.

No part: until some months ago, MCP servers were not prepared to use that glue code at all.

Your LLM could generate the code it wanted, and you could execute that code wherever you wanted, including letting the LLM run it. but every call to any of the tools exposed by the LLM is meant to be consumed by your LLM in the old paradigm. If said program makes 80 tool calls, your LLm would still have to send them, and parse their responses, consuming tokens.

In code mode the glue code is sent to the server, which executes it, and returns the final result. It’s a single invocation and a single response, instead of 80 like before

> Maybe the answer is to partner LLMs with Common Lisp or Scheme ...

That LLMs proved to everyone that piping programs at the CLI was indeed the one true way to do things was already quite delicious.

If now LLMs were to then make the world move to Lisp would really be the icing on the cake.

I'm all for it!

In terms of token and attention efficiency, lisp's syntax is actually not quite optimal. Ironically, something like xml where you can munge the delimiters together with the tag as a single token for common cases (e.g. '<tr>' and '</tr>' vs '(' 'xyz' ')') is better.