Viktor.comAn AI coworker that actually does the work
Promoted
Bevel
Infrastructure for Enterprise Deployment of Agents
364 followers
Infrastructure for Enterprise Deployment of Agents
364 followers
We're building the infrastructure for deploying AI agents in enterprises. From the team behind UTCP, the open tool-calling protocol as an alternative to MCP.
UTCP
Hey Product Hunt! 👋
We're launching Hexis because we've seen everyone (including ourselves) putting skills and context into GitHub. Versioning, PRs, review; it works for a bit. But then non-technical people have to learn the whole workflow. GitHub was built for software development, and it breaks down when you use it at scale for something it wasn't built for.
Hexis is a layer on top of Git. It keeps the core (versioning, PRs) and adds a non-dev friendly UX on top, and allows file-based access management (that just doesn't work with Github/Gitlab)
Users in companies can simply connect any agent of their choice through an MCP server, and can use skills, suggest changes, and submit new ones without ever touching a Git workflow.
Admins manage which context, tools, and skills each person, team, or agent has access to. They approve requested changes and review submitted skills.
P.S: In Aristotelian philosophy, 'hexis' is a skill you don't just perform once, but genuinely possess.
UTCP
Hi team!
Really proud of what we’ve built here.
Over and over, people we’ve talked to have mentioned how hard it is to share and connect to skills, tools and context in their organizations.
Specifically for two reasons:
Sharing skills between coworkers is slow and clunky when you have to share files and folders
Using GitHub to store and distribute skills is a big learning curve for non-technical users
By open sourcing our work, we hope you have now a simple way to upload, share and improve on your team’s context, skills and tool!
Would love your feedback ❤️
The access control angle is the interesting part to me. I load skills through a per-directory scoped Skill tool day to day, and the one thing that trips me up is resolution order when the same skill name exists at two governance levels (say a team-wide skill and a project-local override). Does Hexis pick the more specific one automatically, or is that a conflict an admin has to resolve by hand?
@abdullah_javaid3 On skill creation we enforce unique names, so we dont allow skills with the same name to be created. If it still happens because they were not created via the interface, then we add a number at the end of each to differentiate, and the agent can see the path where its saved which corresponds to the group it belongs to
@razvan_ion_radulescu Makes sense, forcing uniqueness at creation is simpler than resolving it at runtime. The path-based fallback for the edge case is a reasonable escape hatch. Thanks for the detail.
FetchSandbox
the Git-as-source-of-truth angle is the right call for enterprise. versioning and PR reviews are already the trust layer devs understand, so layering agent skill governance on top means you're not asking orgs to adopt a new trust model from scratch. curious how you handle conflicts when two teams submit competing versions of the same skill, does it go through a standard PR review flow or is there a separate governance step for that?
@rnagulapalle because each team can be represented as a separate group, and each group manages its own skills, our governance model allows each team to have their own version of skills that can evolve independently based on the usage and needs of that group (each individual skill owner in each group gets user friendly PRs that they approve or reject).
If a user is a member of multiple groups each with similar skills either they or their agents get to choose which skill fits best for the task at hand.
It is crazy how easy this makes switching the agent I'm working in, and how easy it makes creating background agents for various tasks!
You can also test the demo before looking into self-hosting directly at demo.bevel.software