Monospace from Directus - The governed API layer for every app, person, and agent
by•
Monospace sits between enterprise data and everyone who builds on it. Connect any data source, and your developers, business teams, and AI agents get live, read-write access to it. All under the same granular permissions model, with no data copied or moved. Your oldest databases weren't built with AI or modern apps in mind. Monospace generates interfaces directly from them, as they are, introspecting the schema and queries in real time, so they don’t need to be rebuilt.
Replies
I'm thrilled that Monospace is finally out for the world to use it!
I've been contributing to its frontend for the past months and it's been hard keeping it internally because it simply rocks!
It's free, it's full of powerful features (extensions and custom connectors, SSO support, Partial Introspection, UI views and builders, Native AI support, ...)
PLEASE let us know if you find anything that still needs fine-tuning, or if you find it awesome!
@rebaar S/O for the launch!
Sounds like an improved API management for layer for AI era applications. All the best with the launch.
@gokuljd Thank you! And yes, that is basically it. No more insecure impromptu APIs stood up by agents just to connect one more system into your projects. Are you gonna try it out?
@gokuljd thanks for your support, Gokul! see it on your own data at monospace.io and add your review here: producthunt.com/products/directus/reviews
Do you think companies should rebuild old databases for AI, or build an API layer on top of them?
Congrats @benhaynes & team!
Keep it up @fmerian !
@benhaynes @fmerian @hamza_afzal_butt I don't think companies should rebuild old databases at all. This is where Monospace actually comes into play. You can hook it up to any existing, old database and give your agents (and users) a well defined, permissioned layer on top of it. We automatically introspect the old data systems and you decide what to make available through the API.
You can keep your old systems in place and use Monospace as the fresh lick of paint for making sure AI does not overstep its bounds and you're not seeing a massive sprawl of "one off" integrations.
thanks for your continuous support, Hamza! you rock
Looks promising! 🤞 I'm thinking about how this will enable business to create internal apps or work with data across all connected databases and services. Are there any guardrails for less-technical users to make sure that they won't ruin anything by just testing the platform out?
@wojciech_cichon thanks for the question! Absolutely - any user is bound by the roles and policies assigned to them. This covers permitted actions on connected data sources (such as create, read, update, delete), with additional row/field level filters to go even more granular if necessary (e.g. can read table orders but has restricted access to user email). We would promote least privilege access based on the underlying job the user, app, or agent needs to do.
Heya! 👋
Super excited to finally lift the curtains on Monospace! We've spent the last decade building Directus and helping people out with their data and content management needs. Monospace takes what we've learned during that time and applies it to a problem that we keep seeing: data scattered across systems, with every new app or AI agent needing another integration and another set of access rules.
The fact that Monospace can deliver your data as a single unified governed API without having to copy over all your data into it's own system is magical ✨
Love to hear what you're connecting to in your projects, and where giving an app or agent access to that fleet of data sources is difficult today :)
@rijkvanzanten finally, indeed! you announced Monospace in public preview last July, curious how were the first impressions from your early users?
Love the idea of one way to access data across different systems...
Really impressive launch! Curious to see where you take this.
The permissions and governance piece feels especially useful.
@laurenkp Thank you! Also very excited to take it much further!
@hanneskuettner curious what's on your product roadmap? 👀
@hanneskuettner @fmerian I think it's available by request here https://monospace.productlane.com/request
After 5+ years of building tools like Directus and testing many tools on the market, it takes a lot to truly blow me away.
But, Monospace completely did.
Not saying this just because I’m on the team but I’m saying it as a builder who knows the pain of fragmented data. Being able to manage data from multiple sources in a single place, wrapped in a sleek, intuitive UI? Game changer.
The developer experience is next-level and performance is next level speed.
@joselcvarela re: developer experience. what are the developer tools that have a great DX from your perspective? the products that inspired you while building Monospace and/or that you enjoy using as a developer?
What projects is Monospace best suited for?
@bengeekly Thanks for the question! Any application or internal tool development that might need to utilize data from more than 1 system. Alternatively, any agent governance use case where you want to permit controlled/scoped access to live data, without providing direct or source system access. Other projects we've seen are for sharing your first-party data with external partners in a controlled way, and consolidating backends across multiple teams in larger organizations.
@bengeekly in this context, would it suit @Mailwarm? anything else @Directus should build/improve/fix from your perspective??
The idea of generating live interfaces straight from existing databases without copying data is a smart angle. Curious how the permissions model handles really old schemas that were never designed for AI agents.
@karimbenkeroum Monospace is fully in charge of authorizing operations before they reach underlying datasources, which means you can setup permissions on each collection to make sure AI agents can't mess with your data even for older databases.
granular permissions model is the key claim here. does that go down to row/field level per agent, or just table-level access? asking because the agent attack surface is different from a human dev's - an agent can get tricked into requesting data it technically has access to but shouldn't touch in that context.
@galdayan policy(CRUD) based access to row and field level for each collection where policies are grouped into roles and roles assigned to human or AI agents
@jonathan_wagner3 that's good to hear, role-based with per-collection row/field policies is the right primitive. only follow up - if a human and an agent share the same role (say both "editor"), is there a way to scope the agent tighter than the human, or does it have to inherit the full role?
@galdayan generally same role has same permissions though we do support dynamic variables for current user so possible to do some scoping that way, but I would lean toward separate roles if they need divergent permissions.