Building an agent that consults documents, answers questions, or performs a task is becoming increasingly accessible, but making it a reliable service requires addressing other issues: who can use it, what information it can access, what actions it is permitted to perform, and how to intervene when something goes wrong. As the number of agents increases, these decisions become operational and governance challenges.
Consider an organization with assistants for purchasing, operations, customer service, and development. Each team brings its own models, tools, and information sources. Dependencies overlap. A change to a permission, a table, or an API can affect multiple services. The volume of conversations only partially explains this complexity.
Scaling requires a shared capacity to authorize, monitor, evaluate, and maintain these systems throughout their lifecycle. At ALTIA, we support clients with data and AI services on Databricks, where operation and governance are integral to the work. The platform provides relevant components, but transforming them into a sustainable service requires clear architecture, integration, and accountability. Unity Catalog, Unity Gateway, and MLflow address different aspects of this challenge. Omnigent adds a complementary perspective for specific agent-based environments. Understanding its functions helps determine what is needed and how to deploy it to production.
Every agent needs a manager and boundaries.
The first step is to have an operational inventory. For each agent, we need to know its purpose, business owner, support team, users, data, tools, models, and dependencies. We also need to know the environment in which it runs, its level of autonomy, and the criteria that justify keeping it active. This inventory must accompany the deployment. An agent without an owner, allocated budget, or retirement procedure leaves a maintenance obligation that someone will have to assume. When there are dozens of services, relying on the informal knowledge of their developers makes managing changes and incidents difficult.
Controls should be proportionate to their impact. Consulting an internal policy, proposing a response, and modifying an order require different authorizations. It's advisable to explicitly separate reading, recommendation, and execution, establishing which operations require a person's intervention. For example, a purchasing assistant can locate contracts and prepare a comparison, but authorizing them to change conditions in the management system requires an additional decision, with validations on the parameters and scope of the operation. A generic permission to use the tool is too broad if it allows both viewing and modifying.
The organization must agree on these boundaries between business, data, security, and operations. Then, these boundaries must be translated into identities, permissions, policies, and executable checks. An instruction within the prompt can guide the agent, but the authorization of an action must be verified in the system executing it.
Unity Catalog: Governing assets and the identity that uses them
Unity Catalog provides a common foundation for governing data and AI assets. Its model allows you to assign permissions on registered tables, views, volumes, functions, models, and services, making it easy to integrate agent access into the organization's governance structure. The design process begins with an often overlooked decision: which identity each component uses. A service might use a technical identity or execute certain requests on behalf of the user. Databricks Apps supports both models: delegated authorization allows you to apply user permissions when properly configured and used.
The difference has practical consequences. If the entire application queries data with a very broad technical identity, this alone does not limit the information retrieved. We must design and test that entire journey, from user input to resource access. To apply rules consistently, Unity Catalog offers row and column controls, as well as attribute-based policies and governed tags that allow us to express common criteria across asset sets, with the requirements and limitations of each feature.
Implementing these capabilities requires classifying information, agreeing on who maintains the tags, and verifying effective permissions. In a document retrieval wizard, indexes, copies, and caches must also be reviewed: a change in permissions at the source must have a defined handling procedure in these components.
Lineage provides another piece of the puzzle: it helps to understand dependencies and analyze the impact of changes on compatible assets, since reconstructing a specific execution requires supplementing it with application traces. Data lineage and agent call logging address different questions.
From AI Gateway to Unity Gateway: Control AI traffic
When different teams consume models and tools, we need a common point to apply controls over those calls. The evolution of AI Gateway appears in current documentation as Unity Gateway, integrated with Unity Catalog. It's important to distinguish it from the AI Gateway associated with previous Model Serving endpoints because its scope and configuration differ. Its function is to govern the traffic that flows through it: access to models, tool services, usage limits, and consumption tracking. It includes MCP services, the protocol used to connect agents with external tools and sources. Centralization helps prevent each application from managing the same access and consumption decisions separately.
This control depends on the architecture. If an agent retains credentials that allow them to call a provider directly, that route falls outside the gateway. Implementation must consider connections, secret management, and authorized outbound paths, in addition to configuring the service itself. In organizations already using the previous gateway, this evolution requires migration planning. Existing permissions and configurations are not automatically transferred to the new experience. Services must be reviewed, clients adapted, necessary controls recreated, and call paths verified before requiring the new channel. This intervention combines architecture, security, and business continuity, and should be approached in phases according to the dependencies of each application.
Service policies add controls over requests and responses. Databricks documents mechanisms for allowing, denying, or requiring approval of interactions, along with protections against certain content and risks. These policies are still in beta, and their adoption should be tailored to the criticality of the case and their availability. These controls must be combined with validation of each action. A content filter alone does not determine whether a contract modification is valid, nor does it replace the rules of the purchasing process.
Cost also requires a service-oriented perspective. Request limits and consumption tracking help control it, but the full budget includes models, computing, data retrieval, storage, evaluation, and support. Our approach is to measure the cost per task completed with quality: a cheap call can end up generating more expense if it leads to retries, corrections, or manual work. Unity Gateway allows you to configure frequency limits and budgets with alerts and consumption blocking, within its coverage area. We need to verify which modalities and providers are included and how they are accounted for. Budgets are not equivalent to an exact billing ceiling: for example, requests that are in progress can continue even after the threshold is reached. Financial design needs to combine these mechanisms with monitoring and the ability to intervene.
The success of an agent strategy should be measured by the tasks it reliably completes, within agreed-upon permissions, and at a sustainable cost. Operating 100 agents requires the ability to explain how they work, detect when they deviate from the norm, and take timely action. This is the work that transforms AI into a lasting business capability. Let's discuss what your organization needs to take that step.
