Databricks Provisioning Replaces Shared Workspaces With an Agent-Ready Vending Machine

Databricks has replaced a strained shared-workspace model with a provisioning system serving more than 5,000 active users across three clouds. The new Databricks provisioning system gives field engineers isolated environments that expire automatically instead of leaving administrators to coordinate access manually.

The company calls the internal application the Field Engineering Vending Machine, or FEVM. Its arrival creates a clear tension between two infrastructure models. One asks people to share long-lived environments and negotiate conflicts. The other creates temporary, governed resources for each task, including tasks initiated by AI agents.

That shift matters because Databricks now has more than 7,000 people in its go-to-market organization. Field engineers often need administrative control to build demonstrations, reproduce customer issues, and test preview features. Shared workspaces became harder to govern as that group expanded from fewer than 1,500 people three years earlier.

The immediate story is an internal infrastructure overhaul. The larger story is about who controls cloud provisioning when agents can request resources, deploy code, load data, and run workflows. FEVM turns natural-language intent into cloud infrastructure, but it also moves administrative action closer to autonomous software.

Databricks Provisioning Moves From Shared Capacity to Temporary Environments

Databricks has made isolated infrastructure the default unit of work for its field engineering organization.

Under the earlier model, a small collection of shared workspaces supported much of the field organization. Manual maintenance remained manageable when field engineering had fewer than 1,500 people. That arrangement became unstable as the wider go-to-market organization grew beyond 7,000 employees.

This group also has unusual access requirements. A typical enterprise workspace can rely on a few administrators who manage many users. Databricks field engineers frequently need administrator-level control because their jobs involve configuration, testing, and customer-specific demonstrations.

Several engineers working inside the same environment can interfere with one another. A change made for one demonstration can affect another engineer preparing for a customer meeting. Catalog, database, and workload limits also become immediate operational constraints when many teams share capacity.

Cost attribution weakens at the same time. A shared workspace can reveal total consumption without clearly showing which engineer, customer scenario, or experiment created it. Unexpected activity then requires manual investigation across logs and systems.

FEVM changes the operating unit from a workspace shared by a group to an environment associated with a purpose and owner. An engineer chooses a template, cloud provider, and region. The request can include additions such as notebooks, Lakebase resources, or packaged assets.

The system then provisions the environment and records its lifecycle. Builder environments have a default lifetime of 90 days, while other resource types can use different time-to-live settings. A time-to-live policy defines when a temporary resource should expire and be removed.

According to the company’s detailed FEVM account, Slack notifications report when provisioning finishes, when expiration approaches, and when deletion occurs. That visibility turns cleanup from an informal responsibility into a recorded system event.

FEVM also manages some resources independently. A catalog can survive after its attached workspace disappears, then reconnect to another workspace in the same region. This separation prevents one resource’s lifecycle from unnecessarily controlling everything around it.

The important change is therefore not a faster request form. Databricks has put creation, ownership, expiration, and deletion inside one governed process. That process applies whether a human clicks through the interface or an agent calls the underlying service.

Scale Turned Administrative Access Into the Central Problem

The pressure came from a workforce that needed broad control without accepting the disorder that broad control usually creates.

Field engineering teams operate differently from most internal business groups. They must respond to customer situations quickly, often with configurations that cannot wait for a central platform team. Restricting every engineer to a narrow user role would slow work that depends on testing administrative features.

Yet granting thousands of people broad access inside shared workspaces creates its own bottleneck. Every user gains flexibility, but each change increases the chance of contention, unclear ownership, or accidental interference. Platform administrators then spend more time coordinating activity that the access model was supposed to accelerate.

FEVM addresses that contradiction by moving control into isolated environments. Engineers retain the ability to configure infrastructure, while centrally maintained templates define the starting conditions. Isolation limits the blast radius of each experiment without forcing every request through a manual ticket queue.

Databricks says the system has already handled more than 2,600 active deployments across AWS, Microsoft Azure, and Google Cloud. It also processed nearly 1,200 provisioning requests during one day of BuildCon, an internal engineering event.

Those figures come from Databricks and have not received independent validation. They still show the workload pattern the company designed for. Demand arrives in bursts, involves many users, and creates resources that should not remain active indefinitely.

The system had more than 5,000 active users when Databricks published its account on July 23, 2026. The company said it had not encountered a scalability issue at that point. That claim describes internal experience, not a performance guarantee for customer deployments.

This scale also changes the meaning of infrastructure self-service. A small platform team can tolerate informal exceptions and direct support. Thousands of users require repeatable templates, explicit ownership, automatic cleanup, and records that administrators can inspect later.

Comparable developer portals, including Backstage-based systems, often present approved services and templates through a shared catalog. Cloud providers also offer service catalogs for standardized infrastructure. FEVM follows that broad self-service pattern, but adapts it to Databricks field work and agent-driven requests.

The competitive pressure is therefore aimed less at a single vendor than at the manual shared-environment model. Internal platform teams that continue using tickets and long-lived sandboxes now face a visible alternative. They can expose approved, temporary environments without giving up centralized policy.

However, temporary infrastructure does not eliminate governance work. It relocates that work into templates, identity controls, lifecycle policies, and audit records. Platform engineers must maintain those components carefully because more users can invoke them more frequently.

Databricks acknowledges this operational reality. The company says integrating Git workflows, corporate identity, Slack, email, and multi-cloud Terraform required more effort than building the application interface. That admission is more instructive than the vending-machine metaphor.

A polished request box is only the visible edge. The difficult work sits behind it, where identity must follow requests, permissions must remain bounded, and deletion must occur without removing resources that should persist.

The Mechanism Connects User Intent to Multi-Cloud Infrastructure

FEVM matters because it treats a use case, rather than a raw workspace specification, as the provisioning request.

An engineer does not have to begin by listing every required resource. The user describes a goal, such as preparing a financial services demonstration or reproducing a support issue. FEVM maps that goal to a vetted template and exposes configuration choices for cloud and region.

The application uses a React frontend and a Python backend deployed through Databricks Apps. The application platform runs applications inside Databricks and connects them with services such as Unity Catalog, SQL, and OAuth authentication.

Terraform performs the underlying cloud provisioning. Terraform is an infrastructure-as-code system, meaning teams define resources in versioned configuration rather than creating them through unrelated manual steps. Its declarative workflow can manage resources through provider APIs across AWS, Azure, and Google Cloud.

When FEVM receives a request, it selects the relevant Terraform template and sends it to a Git-based runner. The workflow adjusts permissions, provisions requested additions, and records the resulting resources. This design keeps the user experience separate from the infrastructure execution layer.

Lakebase stores state and configuration for the system. Lakebase is Databricks’ managed Postgres service, and its documentation lists application state for AI agents among its supported uses. FEVM records what each resource is, who owns it, why it exists, and when it expires.

That state record is essential. An agent can request several dependent operations much faster than a human navigating separate consoles. Without a reliable inventory, automation can create infrastructure more quickly than administrators can understand or remove it.

The interface also offers a template catalog. Examples described by Databricks include stable serverless environments on AWS, multi-cloud configurations, and environments with Lakebase autoscaling already configured. Templates allow central teams to encode approved defaults before requests arrive.

This structure creates a controlled path from intent to action:

• A human or agent states the use case.

• FEVM selects an approved resource pattern.

• The requester chooses permitted parameters.

• Terraform creates the cloud resources.

• Lakebase records ownership and lifecycle state.

• Notifications expose provisioning and deletion events.

• Expiration policies remove temporary infrastructure.

Each step narrows ambiguity. Natural language can express the goal, but the approved template determines what infrastructure the system will actually create. That boundary distinguishes governed agent access from an unrestricted chatbot connected to cloud credentials.

The mechanism also supports compound workflows. Databricks describes a scenario where an engineer asks an agent to create a workspace, deploy local Databricks Asset Bundles, upload data from Amazon S3, and run a hydration script for a dashboard.

A hydration script populates a new environment with required data or configuration. From the user’s perspective, one request can trigger the entire sequence. From the platform team’s perspective, every action still needs authenticated tools, approved parameters, and observable state.

This is where Model Context Protocol enters the design. MCP is an open standard that lets AI applications connect to tools and data sources through a common interface. The official MCP overview describes it as a way for agents to access external workflows and take actions.

Databricks says FEVM uses MCP as a central control point for chat interfaces, outside services, and agents. Centrally published Claude skills can bypass the graphical interface and call FEVM APIs. A skill file tells the agent how to invoke the approved workflow.

That does not mean the language model provisions infrastructure directly. The agent submits a request to a controlled service, which applies templates and identity rules. Terraform, Git workflows, and FEVM’s backend perform the consequential work.

This separation is the core engineering decision. Natural language handles intent, while deterministic infrastructure systems handle execution. The model can help select and coordinate tools, but it does not replace the state management or lifecycle controls beneath them.

Agent-First Access Raises the Cost of a Bad Template

The same abstraction that makes safe requests easy can distribute a configuration mistake across thousands of users.

Databricks says new templates are vetted, hardened, and repeatedly tested. The company also notes that its team operates under security exceptions because FEVM automates administrative actions against real backend infrastructure.

That disclosure identifies the main uncertainty. FEVM concentrates authority behind a convenient interface. If permissions, identity mapping, or a template are wrong, an agent can invoke the flawed path consistently and at high frequency.

A manual process introduces friction, but that friction sometimes gives an operator time to notice an unusual request. Automation removes that pause. The replacement must use policy checks, constrained parameters, approval boundaries, and complete audit records instead.

Template quality therefore becomes a security boundary. A template can decide which network paths exist, which identities receive access, what data becomes available, and which resources survive deletion. Review quality matters as much as deployment speed.

Natural language adds another uncertainty. A request may be incomplete, ambiguous, or based on an incorrect assumption. FEVM must translate intent into a known use case without silently expanding the scope of what the requester asked for.

Databricks has not published detailed measurements for failed requests, policy denials, incorrect template selection, cleanup errors, or mean provisioning time. Those measures would reveal more about operational quality than the number of deployments alone.

The company also has not described how frequently humans must intervene after an agent starts a multi-step workflow. A successful infrastructure request can still produce an unusable environment if data loading, bundle deployment, or downstream scripts fail.

Cost visibility needs similar scrutiny. FEVM associates resources with owners and purposes, which improves attribution. However, the public account does not provide before-and-after cloud spending, idle-resource reductions, or the cost of operating the platform itself.

Automatic expiration can reduce abandoned infrastructure, but a 90-day default remains long enough for expensive resources to accumulate. Different workload types need different limits. Extension policies also need review so temporary environments do not become permanent through routine renewals.

Multi-cloud support expands the challenge. AWS, Azure, and Google Cloud have different identity systems, quotas, regional services, and failure modes. A common request interface can hide those differences from users, but the platform team must still manage them.

Platform limits present another pressure point. Databricks notes hard limits involving Unity Catalog and Lakebase resources. Centralized lifecycle management helps avoid those ceilings, but it does not remove them. Demand can still outgrow available capacity or create regional contention.

Lakebase itself supports transactional application state, automatic scaling, and isolated branches, according to its Postgres documentation. FEVM’s reliability still depends on how its own schema, reconciliation processes, and recovery logic use those capabilities.

Databricks says the team rearchitected FEVM twice, including changes to the database schema, frontend, and state management. That history suggests the design required significant iteration. It also cautions against treating the current architecture as a simple reference implementation.

The company used AI to accelerate coding but says humans retained control over architecture. That division is sensible for a system managing privileged infrastructure. Generated code can speed implementation, while human review remains responsible for boundaries and failure recovery.

FEVM’s reported scale proves that employees want faster provisioning. It does not yet prove that agent-originated requests deliver the same reliability, security, or cost control as carefully reviewed human requests. Those claims require longer operating data and clearer metrics.

The Real Opponent Is the Long-Lived Shared Workspace

FEVM replaces coordination with isolation, but only by making central platform policy more important.

Shared workspaces initially appear efficient. Teams reuse common infrastructure, avoid repeated setup, and keep resources in one visible location. Those advantages weaken when most users need broad control and customer work requires incompatible configurations.

At Databricks’ current scale, shared environments turn coordination into hidden labor. Engineers must avoid collisions, administrators must trace ownership, and teams must decide who can change common resources. A critical demonstration can depend on another user not modifying the same environment.

Isolated provisioning reverses that relationship. Each engineer receives a purpose-built environment without negotiating with everyone else. The platform team standardizes templates and lifecycle rules rather than mediating individual workspace conflicts.

The shift also changes how companies should evaluate utilization. A shared environment can appear efficient because many people use one workspace. Yet that metric ignores waiting time, configuration drift, failed demonstrations, and investigation effort.

Temporary environments can look less efficient because the system creates more workspaces. They can still produce lower operational waste when ownership is clear and cleanup happens automatically. Databricks has not published enough cost data to establish that result, but the design makes it measurable.

This pattern resembles ephemeral development environments used in software delivery. Teams create a clean environment for a branch, test, or review, then remove it after the work ends. FEVM applies a similar lifecycle to data and AI field engineering.

The agentic element intensifies the case for isolation. A person working through a graphical interface usually performs operations sequentially. An agent can coordinate multiple tools and create several resources from one instruction.

Putting those operations in a crowded shared workspace would increase the chance of unexpected interaction. An isolated environment gives the workflow a bounded location. It also gives administrators a clearer unit for attribution, expiration, and deletion.

However, isolation can create sprawl if inventory and cleanup fail. The answer is not isolation alone. It is isolation paired with centrally managed state, ownership, notifications, and lifecycle enforcement.

This is why the vending-machine label is both useful and incomplete. A vending machine presents a small catalog and delivers a predictable item. FEVM must also authenticate the requester, interpret intent, create distributed infrastructure, monitor limits, and eventually reverse every change.

The platform resembles an internal control plane more than a simple application. A control plane is the management layer that decides what resources should exist and coordinates their lifecycle. FEVM sits between users or agents and the underlying clouds.

That position gives Databricks a direct testing ground for its own application, database, governance, and agent technologies. It also creates an incentive to present successful internal use as evidence for the broader platform.

Readers should separate those two claims. FEVM can be a credible internal solution without proving that every enterprise can reproduce it easily. Databricks’ field organization has specialized expertise, deep platform access, and authority to maintain integrations across corporate systems.

Other enterprises may rely on separate data platforms, identity providers, ticketing systems, policy engines, and cloud accounts. Their integration work can exceed the effort required to build the user interface. Databricks’ own account says that integration produced much of FEVM’s engineering difficulty and value.

The lesson is not that every company needs an identical vending machine. It is that agent-driven infrastructure requires a governed service boundary. Long-lived shared workspaces and ad hoc credentials become harder to defend once software agents can initiate complex workflows.

Three Signals Will Show Whether FEVM Is Ready for the Agentic Era

The next test is whether Databricks can expand agent access while preserving predictable security, cleanup, and operational outcomes.

The first signal is the planned expansion of FEVM’s natural-language interface. Databricks wants engineers to describe customer situations while the system identifies suitable infrastructure. Better intent handling would strengthen the case that use-case provisioning can replace manual specification.

The useful evidence will not be another demonstration of a successful request. Databricks should report how often the interface selects the correct template, asks for clarification, rejects unsupported requests, or requires human correction.

Low correction rates would support the agent-first model. Frequent misclassification would show that a catalog search remains safer than open-ended language for privileged infrastructure actions.

The second signal is the broader MCP integration for tool-based access. Databricks says shipping that integration is one of its next priorities. MCP would let more agent clients reach FEVM through a common tool interface instead of requiring a dedicated graphical workflow.

The key question is how FEVM scopes authority across those clients. Strong identity propagation, constrained tools, clear approvals, and complete audit trails would reinforce the design. Broad credentials or unclear delegation would weaken it.

Security teams should also watch whether agent actions remain distinguishable from their human sponsors. A useful audit record should connect the employee, agent session, selected template, requested purpose, resulting resources, and later deletion.

The third signal is expansion across the broader go-to-market organization. More users will test whether templates remain understandable outside the original field engineering audience. They will also create new workload patterns and support demands.

Adoption figures alone will not settle the question. The stronger measures are provisioning success, time to a usable environment, policy-denial rates, expired-resource cleanup, cost per use case, and human intervention frequency.

Databricks can strengthen its case by publishing those operational outcomes over time. It can weaken it by focusing only on active-user and deployment totals while leaving failures, costs, and security exceptions unexplained.

For developers, FEVM shows how agents can act through infrastructure tools without receiving unbounded cloud access. For enterprise buyers, it offers a concrete test for agent governance: every action should have an owner, purpose, policy path, and expiration rule.

Knowledge workers should care because the same pattern will reach other business systems. Agents will request access, assemble project environments, retrieve context, and coordinate tools. The quality of the control layer will matter more than the fluency of the chat interface.

Teams building similar workflows also need durable documentation outside the provisioning service. A searchable knowledge base can preserve template decisions, incident findings, and operational context for engineers reviewing agent actions.

Databricks provisioning is already operating at an unusual internal scale, but its most consequential phase lies ahead. Watch whether natural-language requests remain bounded, whether MCP access preserves identity, and whether wider adoption improves outcomes without expanding risk.

The practical question for every platform team is now clear: can your infrastructure explain who requested each resource, why it exists, and when it will disappear? If an agent cannot operate inside those boundaries, faster provisioning simply creates faster uncertainty.