跳到正文
原文
Databricks:Blog(RSS)·· 2 小时前AI 评分31

Databricks 如何在不制造 AI 蔓延的前提下扩展智能体应用

How to scale agentic applications without creating AI sprawl

AI 导读

Databricks 联合 OpenAI 和 Stellantis 探讨企业级智能体应用的规模化路径,提出基础设施需同时提供模型与框架选择、受治理的企业上下文、以及贯穿每次操作的控制能力。

正文

Building an agent is getting easier. More capable models and coding agents are making it faster to build and iterate. Operating many agents across an enterprise, however, is a different problem.

As agents move from answering questions to taking actions, they increasingly depend on a web of models, enterprise data, business semantics, tools, and applications. A single workflow might retrieve governed data, select a model, call several tools, hand off work to another agent, and update a business system — all while operating with the right permissions and leaving a sufficient trace to understand what happened.

As each team wires those pieces together independently, a new kind of AI sprawl can emerge: duplicated integrations, inconsistent policies, increased AI spend, fragmented context, and applications that become harder to change as the number of agents grows.

The challenge is scaling those applications without multiplying the infrastructure around each one.

Agent loop graphic

We recently brought together Databricks, OpenAI, and Stellantis to examine what it takes to scale agentic applications in production. A central theme was that as agents become more capable and autonomous, the infrastructure around them matters more.

At enterprise scale, that infrastructure needs to provide three things: choice, so teams can use the right models, tools, and frameworks as they evolve; context, so agents can work with governed enterprise data and business meaning; and control, so permissions, policies, evaluation, observability, and cost management remain consistent as applications grow.

On Databricks, that foundation brings together Agent Bricks, Omnigent, and Unity Gateway. Agent Bricks provides the unified platform for building, governing, and optimizing agent fleets. Omnigent gives teams a common layer for working across agent harnesses, while Unity Gateway centralizes access, cost controls, and observability across the models, agents, and tools those applications use.

With those capabilities shared across applications, teams can add new agents and workflows without turning each one into a separate integration and governance project.

Context should be shared, not rebuilt

An enterprise agent needs more than access to a model. It needs the data, business definitions, documents, applications, and tools required to understand the task at hand.

That context often already exists across the organization. The challenge is making it available to agents in a governed, reusable form.

Consider two agents serving different teams. A sales agent and a customer-support agent may both need to understand who counts as an active customer, which products that customer owns, and how account hierarchies are defined. If each application independently recreates those definitions, the same business concept can mean different things across workflows.

That fragmentation also creates more infrastructure to maintain as teams connect agents separately to customer data, product definitions, metrics, and internal documents.

Agent Bricks draws on a shared context layer built around governed enterprise data and business semantics. Unity Catalog governs access to data and AI assets, while the Genie Ontology gives agents a common understanding of business concepts and relationships. Capabilities such as Document Intelligence, AI Search, and Agent Memory can extend that context with document understanding, retrieval, and history for more complex workflows.

Teams can then reuse the same governed business context across applications instead of recreating it each time.

Choice should not create fragmentation

The best model, tool, or agent harness for a task is unlikely to stay fixed.

Different steps in an agentic application may require different tradeoffs across reasoning quality, latency, and cost. New models and harnesses continue to emerge, and complex workflows may combine several of them at once.

That flexibility becomes difficult to manage when every harness has its own interface, sessions, policies, and way of running.

Omnigent adds a common layer above agent harnesses, so teams can compose agents built with different harnesses and switch between them with less rework. Unity Gateway handles choice at the model and harness layer, providing consistent access to proprietary and open models along with Smart Routing, capacity, and cost controls.

Together, those layers let teams change the models and agent technologies behind an application while keeping the surrounding infrastructure consistent.

Control has to follow every action

The need for control grows as agents move from generating responses to taking actions.

An agent might read company data, call a business system, execute code, update a workflow, or invoke another agent. Each additional capability expands what the application can do and creates more interactions that need to be governed.

Consider an agent handling a customer refund. The employee initiating the request may have broad access to the customer account. At the same time, the agent only needs the order details, the relevant refund policy, and permission to perform a specific transaction. Its authority should match the task it has been asked to complete.

That requires controls that span the entire AI interaction.

Unity Gateway provides a centralized control plane across models, agents, MCP servers, tools, and skills. Teams can apply access policies and guardrails, manage budgets and rate limits, control which AI assets are available, and retain traces across those interactions. Together with Unity Catalog, those controls can reflect the identity, data permissions, and context behind a request.

For workloads that execute code or tools, Databricks Sandbox adds an isolated execution environment with down-scoped access to the data and systems the agent needs.

The result is a clearer boundary around what an agent can access, which actions it can take, and how those decisions are enforced as applications grow.

Control also requires visibility into what happened

Once an application can retrieve context, choose models, call tools, and coordinate multiple steps, its final response tells only part of the story.

A correct-looking answer can hide a failed retrieval, the wrong tool call, or an unexpected execution path. When something does go wrong, teams need to reconstruct how the application arrived at its result: what information it used, which tools it called, which model handled the task, what policies were applied, and where the behavior diverged from expectations.

Unity Gateway centralizes telemetry across AI interactions, including traces, usage, cost, and tool activity. MLflow complements that operational visibility with tracing and evaluation workflows that let teams inspect application behavior, capture representative interactions in datasets, and evaluate changes to prompts, models, tools, or orchestration.

That feedback can inform the next iteration of the application. Teams can compare changes before broader rollout, identify regressions, and use production behavior to improve quality, reliability, and cost over time.

Shared infrastructure makes composition easier

Broader business workflows will often involve more than one agent, model, or tool. One component might understand a user's request, another might analyze data, and a deterministic system might perform a calculation or update a business process.

The ability to compose those pieces becomes more valuable when the infrastructure around them is already shared. Omnigent provides a common interface for agents built with different harnesses, while Agent Bricks provides the broader platform for building and operating the resulting agent fleet. The same governed context and controls can carry across the workflow.

Agent Bricks architecture diagram

As teams build more applications, agents, tools, skills, and business context can become reusable building blocks. New workflows can draw on existing, well-governed, and observable infrastructure rather than creating another isolated stack.

Build for choice, context, and control

As agents become more capable, the architecture around them carries more of the burden of making them reliable at enterprise scale.

Choice gives teams room to adopt new models, harnesses, and tools as the ecosystem changes. 

Context grounds those applications in governed enterprise data and business semantics. 

Control provides consistent governance and operations across the resulting agent fleet, from permissions and policies to budgets, traces, evaluation, and cost.

Agent Bricks brings those capabilities together as a unified platform for building, governing, and optimizing agent fleets at scale, with Omnigent supporting composition across harnesses and Unity Gateway providing a common control plane across AI interactions.

The models and harnesses will keep changing. Enterprises do not need to standardize on one of them to scale successfully. They need to standardize the infrastructure around them — so new agents can inherit the same context, controls, and operating model without creating another layer of AI sprawl.

Learn more

Watch Agents at Work: Shipping Agentic Apps at Scale on demand for a deeper discussion of the infrastructure, operating model, and production patterns behind agentic applications in the enterprise.

Get started

With the Agent Bricks CLI, getting started is easy. In just a few lines of code, you can develop an agent integrated with all of Agent Bricks capabilities, including Unity Gateway for model capacity, Runtime hosted on Databricks infrastructure, and agent tracing powered by MLflow.

来源:Databricks:Blog(RSS) · databricks.com