Looks quite like magentic [0] that I've been building, though broader in scope? I'm (clearly) a huge advocate of pydantic, structured outputs, and keeping control flow in python code (rather than inside abstractions / "chains") as much as possible, so it's great to see those values here too! I'd be interested to hear what you consider in vs out of scope for mirascope and the long-term vision. Also would be cool for one of us to do a mirascope vs magentic comparison blog post.
Hadn't seen magentic before this comment, super cool! Would love to do a comparison blog post -- I'll reach out about this separately :)
re: scope:
I think anything one layer above the base provider API is definitely in scope. A lot of these APIs are autogenerated (e.g. stainless), so I see a lot of value in building language-specific tools (starting with Python, likely JS/TS next) to improve developer experience at this single step up layer (e.g. tools, structured outputs, state across calls, streaming, etc.).
I care deeply about cutting the amount of time people have to spend on things that ultimately aren't the value adding aspects of their work (like maintaining an internal tool), and I think the (coming soon) future of AI-native applications will need this more than ever. Essentially anything that could be considered boiler-plate or unnecessary repeated code is something I want to improve without removing/reducing control and transparency -- I want to build useful abstractions that aren't obstructions.
I also thing it's important to do this through a provider-agnostic interface given how frequently a new "king" pops up.
re: long-term vision:
more support for various providers/models + tools and agentic flows are definitely top of mind here, but to be honest I'm not fully certain what this AI-native future looks like, so I'm keeping an open mind about where to direct efforts. I'm hopeful usage and feedback from building in the open will help further guide this process.
[0] https://github.com/jackmpcollins/magentic