A first-person account published on the Databricks blog describes replacing part of an internal security review queue with a multi-agent system built entirely on the company's own platform, arguing that the previous automation "had simply reached its limits" and was still consuming expert reviewer time on predictable cases. The post, titled "How I built agent-based security reviews on Databricks," describes a working system built in under two hours, versus what the author says would have taken weeks by wiring together separate services.
The architecture is a set of seven focused agents rather than one general-purpose reviewer: an intake agent that runs the conversational front door, a risk assessment agent that assigns a tier and defaults to a higher tier when evidence is incomplete, a requirements agent that maps requests to standards, specialized review agents for cases like browser-extension threat modeling and third-party vendor assessment, a validation agent that builds per-item checklists, a workflow agent handling reminders and escalations, and a learning agent that periodically compares reviewer edits against agent output to surface prompt and standards improvements. The author writes this was deliberate: "I deliberately avoided building a single agent with broad authority to act as a security reviewer." Each agent, the post says, has a bounded responsibility, so that its behavior "remains inspectable and testable, and a change to one does not silently affect another."
The stack names four Databricks components doing distinct jobs. Unity Catalog serves as the system of record, holding standards, request data, evidence, model outputs and decisions as governed tables under one permission and lineage model. Databricks-hosted foundation models supply the reasoning layer, with a tiered split by task: Claude Haiku for lightweight classification, Claude Sonnet for "most review work," and Claude Opus "reserved for the heaviest reasoning." Lakeflow Jobs orchestrates the notebook-based agent workflows on serverless compute. Two separate Databricks Apps handle the human-facing surfaces: a conversational intake app that turns plain-language requests into structured tickets, and an executive dashboard that reads the same Unity Catalog tables to report on volume, risk mix, automation rate and time saved.
On operational reality, the post is thin on hard metrics beyond the two-hours-versus-weeks build comparison. It states that eligible routine requests "that once waited in the queue for days can now be completed in minutes," but does not attach a specific cycle-time figure, an automation rate percentage, or a request volume — the dashboard's underlying numbers are described only as existing and are shown in the post with, in the author's words, "some of the internal-only data redacted." Readers evaluating this as a pattern to lift get an architecture, not a benchmark.
The trade the author is explicit about is scope, not accuracy: automation is confined to "predefined request classes" — well-understood, lower-risk categories such as a routine internal integration on an approved single-sign-on pattern handling no sensitive data — and everything else routes to a human by default. The system treats an unsupported claim as a gap rather than a pass: "an assertion with no evidence is treated as missing information," and when evidence is missing or contradictory the agents post a clarification request or hand off to a reviewer "with the open questions attached," rather than inferring approval. Reviewer corrections feed back into prompts and standards, but explicitly do not let the agents change production behavior on their own — a governance choice that trades autonomy for auditability.
What the post leaves unresolved for anyone trying to replicate it is exactly the part a platform team would need to budget for: no cost figures for model inference across three Claude tiers at whatever volume this queue runs, no error or false-escalation rate, and no detail on how the risk-tiering thresholds were validated before they were trusted with automated completions. The account is a design pattern and a governance philosophy — bounded agents, evidence requirements, conservative default-to-escalate — not a cost or accuracy case study.
The takeaway for teams building similar internal tooling: copy the boundary logic before the architecture — decide which request classes are eligible for automated completion and what counts as acceptable evidence first, then wire the agents, rather than building a general reviewer and hoping its risk judgment holds.