What do the calls being sequential have to do with tokens? Do you just mean that the LLM has to think everytime they get a response (as opposed to being able to compose them)?
LLMs can use CLI interfaces to compose multiple tool calls, filter the outputs etc. instead of polluting their own context with a full response they know they won't care about. Command line access ends up being cleaner than the usual MCP-and-tool-calls workflow. It's not just Anthropic, the Moltbot folks found this to be the case too.
That makes sense! The only flaw here imo is that sometimes that thinking is useful. Sub-agents for tool calls imo make a nice sort of middle ground where they can both be flexible and save context. Maybe we need some tool call composing feature, a la io_uring :)
No, I don't think you're thinking about this right. It's more like hacker news would expose an MCP when you visit it that would present an alternative and parallel interface to the page, not "click button" tools.
You're both right. The page can expose MCP tools like via a form element which is as simple as adding an attribute to an existing form and completely aligns with existing semantic HTML - eg submitting an HN "comment". Additionally, the page can define additional tools in javascript that aren't in forms - eg YouTube could provide a transcript MCP defined in JS which fetches the video's transcript
I think that rest and html could probably be already used for this purpose BUT html is often littered with elements used for visual structure rather than semantics.
In an ideal world html documents should be very simple and everything visual should be done via css, with JavaScript being completely optional.
In such a world agents wouldn’t really need a dedicated protocol (and websites would be much faster to load and render, besides being much lighter on cpu and battery)
> html could probably be already used for this purpose
You’re right, and it already is, and tools like playwright MCP can easily parse a webpage to use it and get things done with existing markup today.
> BUT html is often littered with elements used for visual structure rather than semantics.
This actually doesn’t make much of a difference to a tool like playwright because it uses a snapshot of the accessibility tree, which only looks at semantic markup, ignoring any presentation
> In such a world agents wouldn’t really need a dedicated protocol
They still do though, because they can work more better when given specific tools. WebMCP could provide tools not available on the page. Like an agent hits the dominoes.com landing page. The page could provide an order_pizza tool that the agent could interact with, saving a bunch of navigation, clicks and scrolling and whatnot. It calls the order_pizza tool with “Two large pepperoni pizzas for John at <address>”, and the whole process is done.
I've been having much the same thoughts. What will work look like, say, 10 years from now? I'm beginning to think that we might have all the knowledge worker type jobs largely filled, or filled with significantly less workers, (hopefully) more free time for everyone, and the remaining people working in more physical positions.
In many ways, I think this is probably better for society than the opposite, since in general there are fewer knowledge workers than not.
It will only in the same way computers and machines that automated past work such as farming and textiles has created lots of free time for today's workers.
Wow, I wouldn't have thought that it would be possible to do this (at least, not ergonomically, although now that you mention it I guess I don't see why not). That would be amazing to see.
I was sort of thinking about a similar idea recently. What if you wrote something like a webserver that was given "goals" for a backend, and then told agents what the application was supposed to be and told it to use the backend for meeting them and then generate feedback based on their experience.
Then have an agent collate the feedback, combined with telemetry from the server, and iterate on the code to fix it up.
In theory you could have the backend write itself and design new features based on what agents try to do with it.
I sort of got the idea from a comparison with JITs, you could have stubbed out methods in the server that would do nothing until the "JIT" agent writes the code.
Fascinating concept, you essentially frame the backend not as a static codebase, but as an adaptive organism that evolves based on real-time usage.
A few things that come to my mind if I were to build this:
The 'Agent-User' Paradox: To make this work, you'd need the initial agents (the ones responding and testing the goals) to be 'chaotic' enough to explore edge cases, but 'structured' enough to provide meaningful feedback to the 'Architect' agent.
The Schema Contract: How would you ensure that as the backend "writes itself," it doesn't break the contract with the frontend? You’d almost need a JIT Documentation layer that updates in lockstep.
Verification: I wonder if the server should run the 'JIT-ed' code in a sandbox first, using the telemetry to verify the goal was met before promoting the code to the main branch.
It’s a massive shift from Code as an Asset to Code as a Runtime Behavior. Have you thought about how you'd handle state/database migrations in a world where the backend is rewriting itself on the fly? It feels to me that you're almost building a lovable for backend services. I've seen a few OS projects like this (e.g. MotiaDev) But none has executed this perfectly yet.
It’s funny I’ve been pondering something similar. I’ve started by writing an agent first api framework that simplifies the service boundary and relies on code gen for sql stubs and APIs.
My next thought was to implement a multi agent workforce on top of this where it’s fully virtuous (like a cycle) and iterative.
The "JIT" agent closely aligns with the long-term vision we have for this framework. When the orchestrating agent of the working swarm is confident enough to produce more sub-agents, the agent graph(collection) could potentially extend itself based on the responsibility vacuum that needs to be filled.
No? It sounds like they rejected the need for a connection pooler and took an alternative approach. I imagine they were aware of connection poolers and just didn't add one until they had to.
Imho (in my harsh opinion, in this case) unless you're a prodigy you're probably not a very good programmer at this point. Now granted people learn more quickly outside of university I think because it tends to be more focused, but I don't think I know anyone that I would have called a good programmer a year in.
But feel free to call yourself a programmer, I'm not going to gatekeep it :)
Distributed tracing is a term for tracing that span between systems. With distributed tracing you can follow request traces across your various services. With pg_tracing enabled in postgres this would extend to your database.
Yeah, this is for integration with OTEL standard distributed tracing. So you configure some OTEL compliant endpoint for postgres to send trace spans to and that endpoint will collect traces from different services and store them for later retrieval.
reply