이미지: METAL LAB 생성
Summary
- Databricks has publicized an AI agent orchestration case study from accounting and advisory firm CLA (CLAconnect)
- CLA used Lakebase Postgres as its backbone, implementing durable job queues, retries, and rate-limit-aware scheduling
- The approach reportedly replaces the queue, scheduler, cache, and monitoring stack typically needed for long-running AI agents with a single database
- 발표 주체
- Databricks (X 게시, 2026-08-10)
- 사례 기업
- CLA (@CLAconnect)
- 핵심 기술
- Lakebase Postgres — Databricks의 Postgres 기반 오케스트레이션 백본
- 구현 기능
- 내구성 있는 작업 큐, 재시도, 레이트리밋 인식 스케줄링, 실시간 모니터링
- 배경 문제
- 장시간 실행 에이전트는 통상 큐·스케줄러·캐시·모니터링 도구 스택이 계속 늘어난다
- 관련 동향
- AWS도 Bedrock AgentCore로 유사한 에이전트 인프라 문제를 다루고 있음
Why is an accounting firm talking about databases
On August 10, Databricks used its X account to introduce how accounting and advisory firm CLA (CLAconnect) runs its AI agents in production. What stands out is the approach CLA took. Rather than discussing a new AI model or benchmark, the case addresses an infrastructure problem: how to keep agents running reliably over long stretches of time.
According to Databricks, long-running AI agents typically require an ever-expanding stack of queues, schedulers, caches, and monitoring tools. Unlike a chatbot that answers one question at a time, these agents carry out multi-step tasks over minutes or hours, need to retry after failures, and must throttle calls to external APIs. CLA reportedly solved this problem the Databricks-native way — using Lakebase Postgres as its orchestration backbone.
What Lakebase does
Lakebase is a Postgres-based database service offered by Databricks. According to the announcement, CLA used it to implement a durable job queue (a queue that preserves state even if a job is interrupted midway), retry logic for failures, rate-limit-aware scheduling, and real-time monitoring. Instead of bolting on a separate message queue system, workflow management tool, and cache server, CLA handled all of these functions within a single database layer.
| Component | Typical stack | CLA's Lakebase-based approach |
|---|---|---|
| Job queue | Separate message queue system | Lakebase Postgres table |
| Retry handling | Workflow management tool | In-database retry logic |
| Scheduling | Separate scheduler | Rate-limit-aware scheduling |
| Monitoring | Separate dashboard | Integrated real-time monitoring |
Why "long-running agents" are a problem
As AI agents evolve to research documents and complete tasks by moving across multiple systems on behalf of humans, more and more single tasks now take hours instead of seconds. Such agents need to resume from where they left off rather than starting over after a failure, must pace their calls to avoid getting blocked for hitting external APIs too aggressively, and need to let humans check progress in real time. When these three requirements overlap, development teams inevitably end up stitching together separate queues, schedulers, caches, and monitoring tools.
AWS is grappling with a similar problem. In early August, the AWS ML Blog published a case study on building a bridge that lets an agent running on Bedrock AgentCore access an MCP server on a user's local machine. The internal financial assistant featured in that post reportedly handled more than 41,000 conversations in the year since its launch. Different cloud providers frame it differently, but the common theme emerging is infrastructure for reliably managing long-running agents.
Reading this alongside Databricks' recent moves
Databricks recently announced it is relaunching its "Data + AI World Tour," spanning 20 cities and aiming to draw a combined audience of 40,000 attendees. The CLA case study fits into that broader push. It reads as an attempt by Databricks to demonstrate, through a real customer example, that it can address not just data platform needs but also agent operations infrastructure within its own ecosystem.
So what actually changes
Until now, running a long-running AI agent meant development teams had to separately select and combine a queue system, scheduler, cache, and monitoring tools. The CLA case shows that this combination can be compressed into a single Postgres-based service. For organizations already using Databricks, this means they can build out agent operations infrastructure without standing up a separate infrastructure team. That said, this is a single case study presented by Databricks, and whether the same approach applies equally to agent workloads of different scale or industry remains to be seen.
