Agentic data operations

AI Database Assistant

A permission-aware AI Worker that turns business questions into inspectable database analysis.

01 / System briefMCP · FastAPI · PostgreSQL
AI Database Assistant project previewOperational system / 01

Start with the work that is painful enough to change.

Database analysis was trapped behind specialist queries and approval loops, slowing the route from a business question to evidence.

Primary userOperations or business analyst
System ownerData and operations team
Decision-makerOperations manager
Frequency

Event-driven whenever a decision needs evidence from operational data.

Friction

The analyst must translate a business question, find the right specialist, wait for a query, and interpret the result.

Cost of the status quo

Slow decisions, repeated handoffs, and limited visibility into how an answer was produced.

From a fragmented handoff to a controlled operating path.

Before

  1. 01Business request
  2. 02Specialist handoff
  3. 03Manual query design
  4. 04Result review
  5. 05Decision

After

  1. 01Business intent
  2. 02Context assembly
  3. 03Governed AI Worker
  4. 04Verified query
  5. 05Evidence + review

Make the job, constraints, and definition of done explicit.

Job to be done

Investigate a permitted data question and return a concise, evidence-backed analysis.

Inputs
  • Business question
  • User role and permissions
  • Relevant schema and business definitions
Output

A traceable answer with the approved query path, result evidence, and any escalation required.

Done means

The request is authorized, the selected operation is safe, execution succeeds, and the answer is grounded in returned data.

Why AI belongs here

The work begins with ambiguous business language, requires schema-aware investigation, and needs the system to choose the next safe read operation based on intermediate evidence.

What stays deterministic

Authorization, query validation, row limits, execution policy, and the final evidence trail remain deterministic software responsibilities.

A worker is more than a model response.

01Request specification
02Schema and policy context
03AI Worker
04Approved MCP tools
05Validation
06Human outcome
Worker responsibility

Interpret the question, assemble only the relevant data context, propose a bounded read operation, and explain the evidence returned.

Worker actions
  • Classify the request
  • Inspect permitted schema context
  • Plan a read-only operation
  • Present evidence and uncertainty
Always available context
  • User permission scope
  • Query policy
  • Business glossary
Retrieved only when needed
  • Relevant tables and fields
  • Approved schema metadata
  • Prior workflow state when available
ToolPurposePermissionBoundary
Schema inspector

Understand allowed data structure

Read-only

Only approved metadata

Query executor

Run a validated analysis query

Restricted

Read-only, scoped, and limited

Evidence formatter

Return an inspectable finding

Output only

No database writes

Give the system room to reason. Keep the consequences governed.

01

Permission-aware routing

The worker receives a constrained tool surface based on the requester's allowed scope.

02

Validated operations

The model proposes; typed validation and execution policy decide what can run.

03

Escalation over guessing

Missing context, unsafe intent, or ambiguous results become review points rather than fabricated answers.

Make the system inspectable before asking people to trust it.

What the operator can observe
  • Request classification
  • Selected context
  • Proposed operation
  • Validation result
  • Execution status
What the system should be evaluated on
  • Correct tool selection
  • Permission compliance
  • Query safety
  • Evidence-grounded response
  • Clear escalation
Engineering lesson

Tool access is not the bottleneck by itself; the worker needs the right business definitions and schema context before it can make a useful plan.

Next iteration

Promote recurring investigation patterns into reusable skills and add scenario-based evaluations for ambiguous analyst requests.

Intended outcome

Natural-language analysis without surrendering control.

This system briedev.hamzasajid@gmail.comonal design: the work to improve, the boundaries that keep it safe, and the evidence needed to operate it responsibly. It does not claim unmeasured benchmarks.

Discuss a similar system