Databricks’ security-review system uses seven narrow agents—and refuses to infer its way to approval

Databricks has published an internal case study of an agent-based security-review workflow that is useful beyond security teams. Its central design choice is to split one consequential process across seven bounded agents rather than give a single general agent broad reviewer authority. The workflow covers intake, risk assessment, requirements, specialized reviews, validation, follow-up and learning, with Lakeflow Jobs orchestrating the steps and Unity Catalog holding standards, evidence, outputs and decisions. Source: Databricks

Make uncertainty change the route

The most transferable rule is not about model selection. When information is missing or contradictory, the system asks for clarification, assigns the more conservative risk tier or sends the case to a person. Databricks says it does not let the model “infer its way to approval.” Automated completion is limited to predefined, well-understood lower-risk request classes, and supporting evidence must be concrete enough to verify—such as a linked design document, a declared data-classification level or configuration showing that an approved control is present. Source: Databricks

That is directly relevant to production data agents. A generated SQL query can be syntactically valid while the request remains ambiguous, the relevant data policy is unknown or the user’s claimed business definition lacks evidence. Treating uncertainty as a routing signal is safer than asking one model to resolve every gap inside its answer.

Seven jobs, not one persona

The published architecture gives each agent a narrow responsibility. The intake agent converts a plain-language description into a structured request and asks context-dependent questions. The risk agent assigns a tier and records supporting evidence. The requirements agent maps the request to standards. Specialized agents handle request-specific logic, while a validation agent prepares checklists for higher-risk work. A workflow agent manages clarifications and escalations, and a learning agent compares reviewer edits with earlier output to identify improvements. Databricks says reviewer corrections are used to refine standards, prompts and workflow logic; the agents do not change production behavior by themselves. Source: Databricks

The implementation also uses different hosted models by workload: Claude Haiku for lightweight classification, Sonnet for most review work and Opus for the heaviest reasoning. But the post argues that scope, evidence, escalation and human authority matter more than the model itself. Source: Databricks

What the case study does—and does not—prove

Databricks says eligible routine reviews that previously waited days can now complete in minutes, and that an operational dashboard tracks request volume, risk mix, automated completion, escalation, cycle time and estimated reviewer time saved. The public post does not disclose the underlying counts, automation rate or measured time savings, so readers cannot independently assess the magnitude of the outcome. It should be read as a vendor-authored architecture report, not a benchmark. Source: Databricks

Even with that limitation, the control pattern is concrete: define which cases automation may finish, require inspectable evidence, make uncertainty fail closed, preserve human control over exceptions and record every input, output and decision in one governed system of record. For teams deploying analytics agents, those boundaries are a stronger starting point than a more elaborate system prompt.