Vol. 01·Databricks Agentic Architecture

How DwaraOne
is composed.

A Databricks-powered conversational HR front door for the agentic enterprise. Context, tools, transactional state and memory — arranged as one governed loop.

§ 01 · The loop
31
governed agent tools
8
full policy documents
6
lifecycle stages per transaction
SHA-256
chained audit entries
Read this in 30 seconds
Ready — live in this preview Partial — working, narrower scope Planned — designed, not built
  1. 01
    Context

    An HR ontology joins policy, roster, leave, LMS and identity into one governed view.

  2. 02
    Tools

    The agent picks from scoped read and write tools — never free-form SQL.

  3. 03
    State

    Writes land in Lakebase Postgres, then merge into Delta under Unity Catalog.

  4. 04
    Proof

    Every state change is appended to a hash-chained audit log you can replay.

Live governance · session-scoped
Open reasoning trace
0
Turns this session
0
Tool calls
0
UC tables touched
31 · 8
Tools registered · policies loaded
§ 00

The pieces

What each one actually does here
Unity Catalog
Every read Agent Brahma makes resolves to a governed gold view employee_360, leave_eligibility, training_due — and every answer cites its source on the card.
Genie Spaces
Three configured spaces stand behind natural-language analytics, so leadership questions become governed queries rather than exports.
Policy Knowledge
Eight full policy documents joined with employee_360 at question-time. Tenure, base, and dependents change the answer: six years of service means 24 leave days, not 22.
Agent Tools
Task Me Anything — every tool is a real write against Databricks, hash-chained into the audit ledger. 31 governed tools. Every write is a two-step intent — preview, then explicit confirmation — never a direct mutation. Preflight checks simulate consequences against roster, blackout windows, and crew coverage before anything is proposed.
Lakebase
Confirmed submissions insert into airhr_ops.requests; every state change appends to a SHA-256 hash-chained audit_log; a merge job carries the ledger into Delta under the same governance.
Agent Memory
Persona-scoped transcripts persist per role, and tool results ride along in conversation history — Agent Brahma remembers what his own tools told him a turn ago.
§ 01

The trust boundary

Surfaces outside · agent + substrate inside
Layered architecture · closed loop
Surfaces · outside boundary
Employee
Manager
Org Head
Trust boundary · Unity Catalog
Context
  • Genie Spaces
  • HR Ontology
  • Policy Knowledge Base
Agent
Agent Brahma — DwaraOne Concierge
readspreviewssubmitsapprovalspolicynext-best-actions
Lifecycle
  1. 01 · preview
  2. 02 · confirm
  3. 03 · submit
  4. 04 · approve
  5. 05 · audit
Substrate · Databricks
  • Gold Views
    employee_360 · leave_eligibility · training_due
  • Lakebase
    airhr_ops: requests · approvals · audit_log
  • Delta merge
    state → gold materialization
  • Unity Catalog
    lineage · policies · access
↺ hash-chained audit · SHA-256

Every arrow crosses a governed boundary — Unity Catalog tables, Mosaic AI Agent Tools with audit flags, and a Lakebase-ready transaction ledger. Nothing bypasses lineage.

§ 02

Capabilities

Ready · Partial · Planned — no hand-waving
*
Demo transparency
Today's demo runs on seeded Gold views and an in-memory request ledger. The Lakebase persistence, live Mosaic AI tool registration, and per-user memory store are the production gaps listed above — each is a scoped follow-on, not a rewrite.
§ 02.5

Databricks Free Edition

The substrate — what each primitive powers in DwaraOne

Everything on this page runs on the Free Edition today. Nothing below is aspirational — each primitive is wired to a specific DwaraOne surface, and the paid-tier delta is SLA and private networking, not capability.

01Unity Catalog
Row- and column-level governance on every Gold view Agent Brahma reads — including the masked attrition_heatmap for Org Heads.
How · A single catalog (airhr_one) owns schema, grants, masking functions, and lineage. Every server route resolves through it.
Why · One place to prove who can see what — the answer to every audit question is already recorded.
02Delta Lake · Gold views
airhr_one.gold.employee_360, team_readiness, experience_summary, policy_catalog — the substrate Agent Brahma reasons over.
How · Silver → Gold jobs materialize agent-shaped views (joined, denormalized, typed) so tools never assemble facts at question-time.
Why · Consistent answers across Employee, Manager, and Org Head — same view, different lens.
03SQL Warehouse (Serverless)
Every server route under /api/airhr/* — profile, manager readiness, org metrics, policy check.
How · Parameterized statements via the Statements API, warehouse 94af1bc5b884becc, 30-second wait timeout, results mapped into typed adapters.
Why · No always-on cluster, no leaked credentials in the browser — reads scale to zero between requests.
04Genie Spaces
Three role-scoped spaces — Employee, Manager, Org Head — behind natural-language Q&A.
How · Each space is pinned to the Gold views its persona is allowed to see; Agent Brahma routes the question to the space that matches the caller's role.
Why · Leadership analytics without exports — the query is governed the same way the dashboard would be.
05Vector Search
Policy retrieval behind the Policy Navigator and Agent Brahma's get_policy_document tool.
How · Policy chunks indexed with metadata (region, band, dependents); a tokenized keyword fallback covers cold-start and out-of-vocabulary queries.
Why · Answers are grounded in the exact clause — with a citation on the card, not a hallucinated paraphrase.
06Workflows · Jobs
Scheduled Gold refresh, telemetry rollups into agent_health, and periodic audit-log compaction.
How · Jobs API orchestrates Silver→Gold, ledger→Delta merges, and eval-set replays; all runs emit lineage events into system tables.
Why · The substrate keeps itself fresh — no cron on a laptop, no snapshot drift between demos.
07Lakebase (Postgres OLTP)
The request ledger, consent ledger, and the SHA-256 hash-chained audit spine.
How · Confirmed submissions insert into airhr_ops.requests; every state change appends to audit_log; a merge job carries both into Delta under the same catalog.
Why · OLTP-grade writes and analytics-grade history share one governance boundary — no ETL detour.
08MLflow · Model Serving
Reasoning traces, prompt versions, and Agent Brahma's eval sets — surfaced on the Org Head agent-health panel.
How · Every conversation logs prompt version, tool sequence, retrieval hits, and user corrections as MLflow runs; regressions are caught before the next release.
Why · The agent becomes a measured artifact, not a black box — quality is a gold view.
09AI Gateway
Single governed egress for language and voice — Gemini for reasoning, ElevenLabs for speech — from server code only.
How · Requests are proxied with per-tenant keys, PII redaction rules, and cost caps; browser code never sees a provider secret.
Why · One place to switch models, cap spend, and prove nothing sensitive left the boundary.
10Lineage · System Tables
The why-this trace, SLA countdowns on request cards, and the agent-health data source.
How · system.access, system.query, and lineage tables are read the same way as any Gold view — so provenance is queryable, not folkloric.
Why · Every decision Agent Brahma renders can be reconstructed from data Databricks already keeps.

The full agentic loop — reason, ground, act, audit — closes inside this Free Edition footprint. Moving to a paid tier changes SLAs, private networking, and warehouse size; it does not change the capability surface above.

§ 03

Research foundations

Applied form of two published papers

DwaraOne is the applied form of two published papers. Data Engineering-Driven World Models for Consequence-Aware Agentic Systems describes how governed data becomes the world model an agent reasons over — here, that is the preflight layer simulating leave requests against roster, crew coverage, blackout windows, and balance before execution. Data Engineering-Driven Hierarchical Planning for Consequence-Aware Agentic Systems describes decomposing intent into governed sub-plans — here, that is the life-event journey and the preview → confirm → submit → approve → audit lifecycle every transaction runs. The gold views on Databricks are the engineered substrate both papers assume. And the loop closes on itself: the hash-chained audit log records every request as a state, every decision as an action, and every transition as an outcome — exactly the state–action–outcome history the world-models research requires as training data, meaning DwaraOne generates the substrate for its own future learned intelligence as a byproduct of governance. Every conversation is also an observation: DwaraOne logs its own resolutions, retrieval misses, and corrections into the same governed ledger — the first loop of a governed self-improvement system, where the agent’s quality becomes a measurable gold view rather than a black box.

"One door. Every HR journey. Governed on Databricks." — Brahma Reddy