Agent Bricks Grows Up, Build vs Buy After DAIS 2026
Pull-quote: “The question after DAIS 2026 is no longer whether to build an agent platform. It is which parts of the one you already built you should now delete.”
Why this matters
Every enterprise that shipped agents in the last two years also shipped, by accident, an agent platform: a memory store bolted onto a cache, a document parser, a sandbox made of prayer and containers, and glue code between whatever harness the team preferred and the data. At DAIS 2026, Databricks announced an expanded Agent Bricks that absorbs most of that accidental platform, and cited 100,000+ custom agents already built on it. For anyone budgeting agent work in 2026, the build-vs-buy line just moved.
What was announced
Facts below are as announced at DAIS 2026; status flags matter.
| Capability | What it does | Status |
|---|---|---|
| Agent Memory Services | User preferences, conversation history, sessions, backed by Lakebase | Announced at DAIS 2026 |
| Document Intelligence | Extraction and classification for PDFs, invoices, contracts | GA |
| Databricks Sandbox | Isolated VMs where agents execute code with governed data access | Announced at DAIS 2026 |
| Managed external MCP integrations | Connect agents to third-party systems without custom glue | Announced at DAIS 2026 |
| Expanded model choice | Kimi (Moonshot AI) and Grok (via the SpaceX/xAI partnership), alongside OpenAI, Anthropic, Gemini, Qwen | Announced at DAIS 2026 |
| Omnigent meta-harness | Compose and govern agents across harnesses (Claude Code, Codex, custom frameworks) | Open source (Apache 2.0); managed version in beta |
The strategic tell is the any-harness posture. Databricks is not asking teams to abandon their agent framework; Omnigent sits above existing harnesses and applies composition, collaboration, and centralized governance across them. Agent Bricks keeps compatibility with frameworks including the OpenAI Agent SDK, CrewAI, and LangGraph. The platform wants to be underneath your choices, not instead of them.
The build-vs-buy line, redrawn
Before DAIS 2026 (you built) After DAIS 2026 (platform-managed)
──────────────────────────── ──────────────────────────────────
Memory store + session state ──► Agent Memory Services (Lakebase)
PDF/invoice parsing pipeline ──► Document Intelligence (GA)
DIY code-execution isolation ──► Databricks Sandbox
Per-vendor MCP glue ──► Managed MCP integrations
──────────────────────────── ──────────────────────────────────
Still yours: evaluation, domain tools, prompts, the harness itselfWhat does not move across the line is the part that was never infrastructure: your evaluation suite, your domain tools, and the judgment about what an agent is allowed to decide. A managed platform makes bad agents cheaper to run, not better.
What we would do with a client estate
First, inventory the accidental platform: every Redis-as-memory, every homegrown PDF extractor, every “temporary” container sandbox. Each is now a candidate for retirement, with the caveat that anything not yet GA (Sandbox, memory services, the managed Omnigent) gets a pilot workload, not a production migration. Second, standardize agent-to-data access on MCP now, because both the managed integrations and the governance story assume it. That matches how we ship our own tooling: AlchemyLake installs into a Databricks workspace as an Asset Bundle app exposing 13 MCP tools, so the same contract serves agents, apps, and the CLI. Third, keep the harness decision reversible; the platform now explicitly supports that posture, so lock-in at the harness layer is a self-inflicted wound.
Closing
DAIS 2026 turned Agent Bricks from a builder kit into a platform with memory, documents, execution, and model choice managed underneath any harness. The right response is not excitement; it is a deletion list. Retire the accidental infrastructure as each piece reaches GA, keep evaluation and domain logic in-house, and spend the reclaimed budget on the only thing the platform cannot buy you: agents that are actually right.