miguelspizza
Joined 3 years ago
Joined 3 years ago
Maybe it’s the small sample size, but from what I’ve seen, the thing hurting velocity more than anything is the fact that teams have too many “cooks”.
The way work is delegated is a bit broken when in reality the engineer who knows the code base or problem best should scope the work and just delegate it to their agents.
I can’t image how things look on the BI side.
It is just the right mix of size, capability and speed to make it generally useful for adhoc bulk classification tasks.
For those wanting to run it in browser: https://huggingface.co/alxnahas/strands-decider-2B-webgpu
MCP started out as this sudo browser replacement protocol for AI integrations. Similar to how a browser opens tabs and loads in JS, the idea was that MCP hosts load in MCPs and interact with them that way. Thus the original spec shipped as a stateful server client protocol with prompts, resources, a bunch of other stuff... and tools (the only thing anyone really ended up using). If you want to learn more about the original idea behind it, the creators did a pretty good podcast where they go through the conception and their design partnership with the Zed guys.
It became pretty clear early on that that way people wanted to use it was basically "I heard if I download this thing called an MCP the AI can manage my Jira tickets". so it's been almost 2 years now of rolling back all the opinions of the original protocol (statefulness, esoteric features) and bringing it closer to OpenAPI + JSONRPC + OAuth. Since the July spec release, you will start seeing alot more of this: https://redocly.com/docs/realm/content/api-docs/openapi-exte...
The biggest "win" of MCP is that the hype behind it let the Oauth guys swoop and use it to formalize a bunch of Oauth specs into a coherent story for API auth.
The XSW part of the article was new to me though and kinda shocking
The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.
Now that MCP is stateless we can start building what is actually useful: extending API’s for agents.
When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s
This is not a dig at MCP, the original vision of MCP was much different from how the community used it.
One way to think about WebMCP, as the article notes, is as web accessibility for agents. But since it functionally allows developers to expose any function on their website to an agent via RPC, the more interesting use cases are the ones that use the browser as a sandboxed execution environment.
https://duckboard-webmcp.alexmnahas.workers.dev/ is an example of this, and I would love to see more.
Maybe instead of skills that require users to download arbitrary binaries to their computers, the skills could instead point to a domain that comes preloaded with that binary in Wasm and lets the agent interact with it over WebMCP?
This is also why I advocate against using AI as a writing partner. No matter the argument you lay out, a fresh context window will always have the “a few good things and a few bad things” feedback. There is no higher order opinion to align with.
This sort of audacity is a large part of the reason people increasingly hate AI
Maybe if we give these things their own identity people will stop letting their AIs post as them in linkedin
Very very good, nice work.
What are your plans for the library?