The current state of AI agent orchestration is a fragmented mess of prompt-engineered tool definitions and hard-coded permissions. For most development teams, adding a new capability to an AI agent involves updating a system prompt or modifying a local config file, a process that is notoriously difficult to audit and even harder to scale across a team. As agents move from simple chat interfaces to autonomous entities capable of executing code and accessing internal databases, the lack of a centralized, governed control plane has become a critical bottleneck for enterprise adoption.

The Architecture of a Centralized Agent Control Plane

Hexis emerges as an open-source solution to this governance gap, serving as a dedicated control plane for managing the skills, tools, context, permissions, and identifiers that AI agents rely on. Developed as the core engine of the Bevel platform, Hexis is designed from the ground up to be MCP (Model Context Protocol) native. This architectural choice ensures immediate interoperability with any client that supports the MCP standard, including Claude, Cline, Cursor, and ChatGPT.

From a technical standpoint, Hexis provides a centralized hub where organizations can manage their internal AI plugins and knowledge bases. Rather than granting agents blanket access, Hexis implements Role-Based Access Control (RBAC), allowing administrators to strictly define the scope of what an agent can see and execute. This security model is further hardened by a credential-less architecture: agents operate within the permission boundaries of the user executing them, meaning the agents themselves never directly hold sensitive credentials.

To deploy Hexis, the infrastructure relies on a modern stack centered around Docker Compose and Postgres 17. The environment requirements are specific to ensure stability and performance, requiring Node 22 (specifically >=22 and <23), pnpm 10, and git 2.41 or higher. The entire configuration—including skill definitions, tool manuals, and permission sets—is stored as files within a Git repository. This allows Hexis to integrate seamlessly with existing version control providers such as GitHub, GitLab, Bitbucket, and Azure DevOps.

Shifting from Prompting to GitOps Governance

While many agent frameworks treat tool definitions as static configurations, Hexis introduces a fundamental shift by treating agent capabilities as code. By utilizing Git as the storage layer, Hexis transforms agent management into a GitOps workflow. Every change to a skill or a permission update is captured as a Git commit, providing an immutable audit trail of who changed what, when, and why. This eliminates the "black box" nature of agent behavior, as any modification must pass through protected branches and a formal review process before being deployed to the team's agents.

This creates a unique feedback loop between the AI and the developer. When an agent encounters a skill error during execution, it does not simply fail or hallucinate a fix; it can propose a specific modification to the skill definition. This proposal is submitted as a pull request, which a human operator can then review and merge, effectively allowing the agent to help maintain its own capabilities under human supervision.

Communication between the agent and the Hexis control plane is optimized for efficiency via the MCP. To avoid overwhelming the agent's context window, Hexis does not push all available skills at once. Instead, it employs a lazy-loading strategy. Agents use `list_skills` and `search` to narrow down the necessary tools for a specific task, and only then do they call `get_skill` to retrieve the detailed implementation and instructions for that specific tool. For users of Cline, this integration can be established quickly via a remote streaming HTTP MCP server using the following command:

cline install mcp demo.bevel.software

For those deploying Hexis in a production environment, the setup involves configuring four essential values in a `.env` file and initiating the stack with `docker compose up -d`. A critical configuration detail for those using reverse proxies like Coolify, Traefik, or nginx is the `TRUST_PROXY` variable. This must be set to the number of proxy hops (typically 1 for a single proxy) to ensure that rate limiting is applied based on the actual client IP rather than the proxy's internal IP. While the default port is 3001, developers can override this by specifying the `APP_PORT` environment variable, for example:

APP_PORT=8080 docker compose up -d

In the development cycle, Hexis maintains high code quality through a standard suite of validation tools. Developers can verify the system using `pnpm test`, `pnpm typecheck`, and `pnpm lint`. Database migrations are handled automatically during the boot process, removing the need for manual migration scripts. As the system moves toward production, the control plane supports Single Sign-On (SSO) integration, state backups, and health check configurations, all manageable via the settings UI or environment variables.

The transition from prompt-based tool management to a GitOps-driven control plane represents a maturation of the AI agent ecosystem. By treating agent skills as versioned assets, organizations can finally apply the same rigor to AI governance that they apply to their production software pipelines.

The era of treating AI agent capabilities as ephemeral prompts is ending, replaced by a rigorous, version-controlled engineering discipline.