What's the purpose of this? There is no replacement for MCP.
We need a protocol for calling tools that works with structured outputs, this is what we have.
Almost all the points are not about what DSPy is mainly supposed to offer.
What's supposedly great at is automatic optimization, for everything else... who the hell puts Python in production just to make some API calls?
There are "frameworks" available in all the better languages, but the constructs behind are not that complicated. And why does DSPy even try to compete with LangChain/Graph/crap?
All vendors will have to implement test time code execution, solution exploration, etc. as it's a low hanging fruit with huge gains, so I see it as a great hire.
Love Bun, happy for you guys!
Hi Rob, thanks for your thoughts!
We're not planning on expanding to watching expiring domains yet, we're focused more on finding domains that were never registered.
But what you're interested in can be done by watching all the registered domains that you're interested in and either catching them when they expire (ex. https://www.expireddomains.net) or by registering a backorder (higher success rate but you have to pay, ex. https://www.gname.com/backorder)
> So my argument is that removing the context that is entirely irrelevant for the agent improves performance dramatically.
100% agree on building the optimal context, just have not seen parallel agents do better at sequential tasks. the documentation agent may have better initial context about how to write documentation, but it doesn't have the context of the changes, apart from what is passed to it / can explore. if we don't spawn a new session, and instead throw it a /document command - that would still get all the guidelines and rules for writing documentation, and it should have the same weight since it's at the bottom of the context.
for me the highest 'model jump level' performance booster is externalizing context and controlling the process - having claude initialize a plan file with a pre-defined template that makes it use that as its to do list and documentation place, and getting it to use that as its primary working area
> If you don't discuss hooks and subagents, i'm not sure what you're doing right now.
Agents have their own context and can be useful for tasks that can be parallelized, which is a minority of tasks. How are they critical to better performance for you?
ah, deep agents = agents with planning + agents as tools => so regular agents.
i hate how LangChain has always tried to make things that are simple seem very complicated, and all the unnecessary new terminology and concepts they've pushed, but whatever sells LangSmith.