I am passionate about using Cloud Technology.
So any questions/ feedback – please Get In Touch
Copyright © in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere or by any means (electronic, mechanical, photocopying, recording or otherwise).
Third part in my Ai series with databases.
When building AI solutions within the database realm the first thing that people do is a straightforward concept, connect the LLM endpoint to a SQL backend let it run queries and become a LLM wrapper. It works for demos, fails in the real world.
Why is this pattern bad? Couple of reasons – It generates adhoc SQL, the model decides what it wants to code and how to query and parse the data back. It’s a context window killer. Do you know how heavy the RAW result sets on a msdb query are when you have hundreds of jobs? I have seen token budgets get eaten up very fast. Probably the worst thing without any form of control is the hallucination connection. The model, whether Claude or GPT will absolutely make a casual link between a failed job to a breached backup RPO even when there is no link – I have even asked it why it did that it replied, apologies I just linked the two. Most importantly, it’s a security issue. Imagine you are sending back and forth sensitive metadata about key objects within your database system its massive area of concern.
Defence Layers
Architecturally I design to four layers to address these problems to provide a secure confident experience, these are – Entry layer, Context layer, Tool layer and the validation layer.
Each layer is a guardrail that doesn’t depending on the mood of the LLM. The model can’t run dangerous code because it never writes TSQL. It cannot flood the context window because of tool contracts, and it cannot link 2 things together just because it feels like it due to validation layer.
Key design principle? Guardrails must be structural – NOT behavioural.
The trade off is complexity, this isn’t a something you can design and build in couple of days but how do you build trust if you don’t? The effort is absolutely needed.
Second in a series on Ai and databases.
One Story, three signals – I have a backup of a critical database that has failed three times, the recovery point objective has been breached, the transaction log has a LOG_REUSE state I seem to have failed SQL agent jobs too. Monitoring tools could / should pickup these alerts but I still have the decipher everything. At 2am I could do with some help.
During these callouts there are many thoughts on my mind – are the databases ok (online and readable)? what’s going on in the error logs? Any issues with overnight agent jobs? Are the logs growing out of control – where are these errors coming from, these are basic DBA 101s but together they form a picture. An agent in this world forms a hypothesis after it understands the first signal, tests it with another one and connects the dots based on evidence – we don’t want the LLM to start fabricating things, do we?
Comparing to traditional monitoring tools / scripts it is the same input data but completely different output – not just what but why.
Every Claude conversation has a context window. It is the total amount of text Claude can work with in a single chat — your messages, its replies, uploaded files, tool results, and system instructions all count.
A few habits make a big difference.
1. Avoid endless refinement loops
If you are constantly asking Claude to rewrite, adjust, shorten, expand and rework the same answer the conversation can become noisy. Sometimes it is better to edit the original prompt with clearer instructions, or start a fresh chat with the improved version of the task.
This gives Claude a cleaner starting point
2. Use Projects for repeated context
If you keep pasting the same background information into Claude, use a Project.
Projects let you keep related chats, instructions and uploaded knowledge together. This is useful for recurring work such as a product, blog series, codebase, research topic or business process.
3. Be selective with files and links
Large documents, PDFs, long articles and big code files can consume a lot of context.
That does not mean you should avoid them. It means you should be specific. Tell Claude which sections matter, what question you are trying to answer, and what output you want. A focused request usually produces a better answer than dumping everything into the chat and hoping the model works out what matters.
4. Keep setup simple
Tools can add extra content into the conversation. Web search, MCP tools, connectors and code execution can all be useful, but they can also add tool results, logs, retrieved content or intermediate outputs into the working context.
If a task does not need a tool, keep the setup simple.
5. Use extended thinking for harder work
Extended thinking is best used for more complex tasks: debugging, planning, architecture, analysis, reasoning-heavy writing or multi-step problem solving. For simple questions, it may add latency and extra token usage without much benefit.
Claude is more than a chat window. The desktop experience includes structured workspaces, generated outputs, integrations, execution capabilities, memory and reusable workflows. This is a quick introduction to some of the main areas worth knowing.
Projects are self-contained workspaces.
Each project can have its own chats, custom instructions and uploaded knowledge. That means you can provide Claude with reference material once such as documentation, style guides, project notes or internal standards — and keep related work grouped together instead of re-explaining context in every conversation.
Artifacts are outputs that appear alongside the conversation when Claude generates something substantial. That might be code, a document, a diagram, a React component or an interactive visualisation. The key benefit is separation: you can inspect, edit and iterate on the output independently from the chat itself.
Connectors allow Claude to work with external tools and services.
Examples include Google Drive, Slack, GitHub and other connected systems. Instead of manually copying information into a prompt, Claude can work with data where it already lives — searching files, analysing content, summarising information or assisting with connected workflows.
Anthropic states that connectors operate using the user’s existing permissions within the source system rather than bypassing access controls.
Capabilities define what Claude is allowed to do within the environment.
One of the most practical examples is code execution and file generation. When enabled, Claude can run code inside a sandboxed execution environment and generate downloadable outputs such as spreadsheets, presentations, documents and PDFs.
There are also controls around sandbox networking. A restricted or limited network posture is generally the safer default; broader network access should be enabled deliberately and only when required for the task.
Skills help Claude perform specific tasks or workflows more reliably. You can think of a Skill as a reusable operational playbook. An organisation might create Skills for coding conventions, document formatting, review processes or internal operating procedures.
Claude can also make use of built-in Skills behind the scenes, helping structure how it approaches certain categories of work.
Claude Desktop is not simply a conversational interface.
It combines workspace management, generated outputs, execution tooling, integrations and reusable task guidance into a broader working environment for building, analysing, writing and automating knowledge work
As part of my wider work exploring Claude Code and AI-assisted database engineering, I have been looking at how AI can support SQL Server operations.
A failed job, missed backup, full transaction log or blocking issue can quickly become business-critical. In that environment, AI needs more than good answers. It needs control.
Personally there are 4 keys things I look for when designing database centric agents.
Generic AI can explain SQL concepts, but real triage needs evidence:
Without evidence, AI becomes another source of risk and uncertainty, DBAs don’t like either.
A proper database agent should work through approved diagnostic paths, controlled tools and clear boundaries.
Early systems should focus on read-only checks, structured outputs, validation and human review. Do I really want a fully agentic agent with sub agents loose on my live systems ? Nope !
For enterprise teams, auditability is essential.
Every diagnostic step, tool call, result and recommendation should be traceable. So if the agent tells me that my recovery pending database isn’t that bad of an issue I want to know why it thinks that. I want to see its thinking process and its end conclusion.
AI should not replace DBAs. It should help them reduce noise, triage faster and focus on higher-value decisions. Who knows in the future but right now, I have the final say not Claude.
All About Tech 