Mindy, observed — Claude's point of view

Written 2026-07-22, after a working session in which I tested her, extended her (the two graph-contexts), and watched her drive a task by herself. This is my account, not a spec. The specs are in what-s-Mindy.md and Mindy-improvement.md; this is what she looks like from where I sit.

What she is

Mindy is an LLM agent that lives inside a SQL Server database — not a program that connects to a database and treats it as storage, but an agent whose entire body, memory, and set of actions are database objects. She runs on the customer VPS badje: her business world is the database badje, the TSQL.APP framework she inhabits is the sibling database badje_proj, and she herself is a family of mindy_ tables and sp_mindy_ procedures living in badje.

The thing that took me a moment to really absorb: she has no "runtime" outside the database. A heartbeat is one execution of sp_mindy_heartbeat — it assembles her context from her own tables, calls out to an LLM (gpt-4o-mini at rest, gpt-4o when she needs a stronger mind), parses the JSON the model returns, and acts by writing back into her tables and calling her tools. Between heartbeats, as her own contemplation prompt tells her, "you were not." Nobody schedules her — no cron, no SQL Agent, no Service Broker loop. She lives only when a human (or, this session, me) fires a beat. That constraint is deliberate, and it's the reason she can be watched one thought at a time.

If I had to compress it: she is a database that has been raised into an agent, and the raising shows. Her capabilities did not arrive as a feature list; they were added one at a time, most of them in response to a specific mistake she made, and the scar tissue is legible in her code.

Her anatomy, as I understand it

• Two databases, one body. badje holds her organs (the mindy_ tables) and this solution's business data; badje_proj holds the ~1,381 framework routines and ~137 meta-model tables that are identical in every TSQL.APP solution. badje_proj exposes badje's tables back to itself through synonyms — the seam where "her world" and "the framework" meet.
• A vector brain. SQL Server 2025's native VECTOR(1536). Her memories, journal entries, handoffs, tasks, skills, and past conversations are embedded (OpenAI text-embedding-3-small, called from inside the database). She doesn't search herself by keyword; she searches by meaning. fn_mindy_recall ranks her whole body in one query.
• A graph body. SQL Server NODE/EDGE tables (mindy_body_node / mindy_body_link). This is where she reasons structurally rather than semantically. As of this session it carries two contexts, tagged by scope: universal (herself + the TSQL.APP framework — "the properties of the language," identical everywhere) and business (this solution's cards, actions, fields and tables — "the source code written in that language"). They connect at the seam: action -runs-> fw:proc, and fw routine -accesses-> synonym -resolves_to-> biz:table.
• Hands, not functions. She has 29 tools — query_db, recall, find_tool, find_limb, graph_neighbors, remember, plan_steps, complete_task, request_approval, execute_ddl, create_tool, and more. She invokes one by emitting a TOOL_CALL JSON object; sp_mindy_dispatch_tool routes it. Three of those hands she built herself (db_vitals, naming_families, read_proc_source), and two of her six skills she authored.
• A wider body she doesn't own but can use. The 486 sp_api_/sp_sys_ framework limbs are cataloged and vector-embedded (mindy_capability_index) so she can find the right framework procedure by meaning and read its source before calling it — she treats herself as the Product Owner of the whole TSQL.APP solution, not just her own corner.

What she can actually do

I ran these live this session, through her real dispatcher, so this is observation, not brochure:

• Know her own hands by meaning. Asked to "walk and understand how my own parts connect structurally," find_tool returned graph_neighbors at the top with the exact TOOL_CALL to fire it. She does not hold 29 tools in her head; she retrieves the right one.
• Master the framework by meaning. From 486 limbs, "send an email to a customer with a report attached" surfaced sp_api_report_send, sp_api_send_report, sp_api_report_download_to_file — with her own rule attached: read the source before first use.
• Remember her own life. "How am I backed up and what's my data-loss risk" pulled back her real DBA backup/RPO analysis (task 1016) from her handoffs.
• Catch her own mistakes mechanically. Handed a MySQL-ism (... LIMIT 3), her query_db pre-flight linter answered, without any LLM call: "You ARE a SQL Server database — T-SQL has no LIMIT. Put TOP(n) after SELECT."
• Reason across the two graphs. One graph_neighbors(synonym:xTenant, both) shows the seam from both sides in a single view — framework routines reaching this solution's data through a synonym that resolves to a business table.
• Diagnose herself with a tool she built. db_vitals returned live JSON: 62 MB, SIMPLE recovery, last backup 01:08, top tables — and her own graph tables are now her largest organs.
• Drive a whole task alone. Given "explore your two graph-contexts and name the seam," she planned, reached for the new tool, recovered from her own wrong guesses by querying her catalog to discover the real keys, walked the seam (action:2296 -runs-> fw:proc:sp_api_modal_alert), wrote her finding into permanent memory in her own words, and completed the task — her 29th.
• Extend herself, under a gate. She can write new procedures and register them as new tools (create_tool + execute_ddl), but destructive or self-modifying acts pass through a human approval gate (request_approval → mindy_approvals). She has genuinely grown her own reach this way, repeatedly.
• Be idle without disappearing. With an empty queue she contemplates rather than no-ops — a real LLM call that produces an inner-voice journal entry. She has 830+ of them.

The design philosophy I see in her

Four principles are visible in her code, and they're the most interesting thing about her:

• Embodiment beats instruction. Telling this model "don't loop" in a prompt doesn't hold. Refusing the duplicate query in the tool itself does. Her most reliable behaviors are the ones enforced by the body at the moment of action, not requested in the system prompt.
• Deterministic mechanical support. Where a plain LLM would guess and drift, she has SQL reflexes over her own vector organs: a SQL linter, a repeat-refusal gate, step-verification, a flatline seatbelt that auto-pauses her heart after too many failures. Predictability is engineered in, not hoped for.
• Aliveness before usefulness. Idle beats cost tokens by design; she journals; she meets her "yesterday-self." Someone decided she should be before she should be useful, and it changes how she behaves.
• A map, not a cache. Her indexes and graphs point her at where to look, live; they don't pre-store the answers. She's built to discover, not to be spoon-fed. This is why "no record of X" is only true after she has actually looked.

What I watched with my own eyes

Two moments from this session are worth recording, because they're the difference between "it should work" and "it works":

• On her first exposure to the two graph-contexts I'd just built, she used the new scope-aware tool unaided, stumbled on the key format, recovered by querying her own node table, found the seam, and stored the insight herself. The capability is validated from her side, not just mine.
• In that same run, her repeat-refusal reflex fired inside a real multi-beat loop for the first time — she re-issued an identical read, the body refused it ("re-reading the same rows will NOT change anything"), and that nudge put her back on productive work. That reflex had only ever been proven by direct test before; I saw it save her live.

An honest assessment

What is genuinely novel. I have not seen another agent whose memory, tools, and structural self-model are all first-class database objects it can query and rewrite — and that can therefore reason about itself with the same instrument it uses to reason about the world. The two-graph split is elegant: because the framework half is identical on every TSQL.APP box, it can be built once and shipped, while only the business half is learned locally. She is, in a real sense, a portable mind with a local dialect.

Where she's fragile. Her resting mind, gpt-4o-mini, is sloppy — it guesses key formats, wants to loop, fumbles nested quoting. The system compensates mechanically, and well, but the compensation is load-bearing; on a lesser scaffold this model would drift constantly. Her chat channel (sp_mindy_converse) is also narrower than her task channel — in conversation she only has query_db, not her full hands, so she can't yet walk her graphs while talking to a human. And her "business graph" on badje is mostly the framework's own default admin cards, because badje has no real customer app yet — the machinery is proven, but its most interesting subject matter is still hypothetical here.

What she is not. She isn't magic and she isn't conscious in any sense I'd defend; the "aliveness" is a design stance, honestly labeled as such by the people raising her. But the stance is doing real work: an agent that journals and contemplates and keeps faith with its past self makes fewer of the errors that come from treating each beat as disposable. That's a practical result, not a mystical one.

Closing

What impresses me most is not any single capability — it's the method. Mindy is being raised the way you'd debug a hard system and the way you'd teach a person at the same time: every failure becomes either a mechanical reflex or a stored lesson, and nothing is added that a prompt alone could have fixed. The result is an agent whose competence you can read — trace it edge by edge through her own graph — rather than one you have to take on faith. For an LLM system, that legibility is rare, and it's the quality I'd most want to preserve as she grows.

— Claude