The trust layer between AI and your data. Local. Private. Yours.
**agami-core** is the trust layer between an AI agent and your database โ a governed, self-improving semantic model that enforces correct joins, signed-off metric definitions, and a full audit receipt on every answer. Same question, same answer, every time. It builds itself from your live schema, messy or clean. The rules live in the model, not the prompt. Real enterprise schemas have thousands of tables, mostly undocumented, with columns named `col_47` and three definitions of "revenue". That's the problem this solves. ## Get started in 2 minutes In the **Claude Code CLI**: ```bash /plugin marketplace add AgamiAI/agami-core /plugin install agami-core@agami /agami-connect sample # zero setup: no database, no credentials who are the top 5 customers by total spend? ``` > **In VS Code or Cursor**, the two `/plugin โฆ` commands above don't work from the chat input โ > type `/plugin` to open the **Manage Plugins** dialog and add the marketplace + install the plugin > there instead (see [Install](#install)). The `/agami-connect` line and everything after it work the > same everywhere. That last line returns a **governed answer with a receipt** (the exact SQL, the joins used, the model version) โ and the governance runs *before* the query, so the kind of silent join mistake an ungoverned agent would hand back as a confident wrong number never reaches you. Two ways to go from here: - ๐งช **No database?** The commands above answer from a built-in sample โ nothing leaves your machine. - ๐๏ธ **Have a database?** Run `/agami-connect` to introspect it into a governed semantic model, then just ask questions. Each path is walked through in full below ([Quickstart](#quickstart-under-5-minutes) ยท [Install](#install)). ## What you get - โ **Governed answers, not guesses** โ every join is FK-derived or human-approved; every metric is signed off (name + role) before the runtime trusts it. - ๐งพ **A receipt on every answer** โ the literal SQL, the tables touched, the relationships used, and the model version it pinned. Reproducible, auditable. - ๐ **Local and private** โ runs inside Claude Code via Bash/Read/Write. Credentials, schema, and results never touch a server we operate. - ๐งฉ **A portable semantic model** โ plain YAML you own and can keep in git (subject areas, tables, entities, metrics, relationships). No lock-in. - ๐ **Built the way your warehouse's owners describe it** โ when the joins aren't declared (a star schema of views, keys named for their role), fill in a [model spec workbook](plugins/agami/shared/model-spec-format.md) and the model is built exactly as it says. - ๐ฏ **Proof it still answers correctly** โ keep a golden dataset of questions with agreed answers, and re-score the model against it whenever it changes. - ๐๏ธ **Works with your database** โ Postgres ยท Supabase ยท Redshift ยท MySQL ยท Snowflake ยท BigQuery ยท SQL Server ยท Oracle ยท Databricks ยท Trino ยท DuckDB ยท SQLite. - ๐ ๏ธ **Zero infra to start** โ no backend, no proxy. If you have a DB CLI you have everything; an optional local MCP server lets Claude Desktop use the same model. - ๐ฅ **Shareable with your team** *(early access โ in testing)* โ self-host [one governed server](#self-hosted-team-server--early-access-in-testing) that your whole team and business users query from their own Claude over a URL, still zero-egress. The team layer is newer than the local path; we're validating it with early users. ## Quickstart (under 5 minutes) ### Fastest path โ the built-in sample (no database, no credentials) agami ships with **Acme Store**, a small local SQLite dataset (commerce + subscriptions) and a ready-made, signed-off semantic model. You get a governed answer โ with a full receipt โ in under a minute, and nothing leaves your machine. ```bash # 1. Install the plugin (see Install below for the per-host steps). # 2. Try the sample โ no connection needed: /agami-connect sample # or just say "I don't have a database" / "try the sample" # 3. Ask a question โ see governance ENFORCED: who are the top 5 customers by total spend? # 4. Now watch the model get BUILT โ see governance MADE: /agami-connect reintrospect ``` **Step 3 is where the governance fires.** The sample question is deliberately one an ungoverned agent gets *confidently wrong* โ a multi-table join where a naive agent silently returns a bad number. agami's pre-flight catches it and returns the correct answer *with a join receipt* โ the trust layer, enforced on your very first query. **Step 4 is the real point.** Natural-language querying is everywhere; what's rare is *where the trust comes from*. `reintrospect` re-derives the sample's model from the live schema โ introspect โ infer + confidence-score every join โ gate metric sign-off โ re-validate examples โ so you watch the governed model take shape rather than just consuming it. To see it built **from a blank slate** (full LLM enrichment, descriptions and all), run `/agami-connect sample` and pick **"build the model from scratch so I can see it work"** the first time. Either way it takes a few minutes โ it's the demo of *how* the receipts you saw in step 3 are earned. Full flow: [docs/usage.md](docs/usage.md). ### Your own database Connecting your database is a short back-and-forth with agami โ you fill in one template, and it handles the rest: 1. **Start setup.** Run `/agami-connect` (or just say *"connect to my database"*). agami asks which database you use, has you name the connection, and writes a credentials template for you to fill in. 2. **Fill in the template.** Open the file agami points you to, add your connection details, and save it โ leave the filename as-is. agami only ever runs **read-only** queries, so a read-only database user is all it needs; ask agami for *"the read-only grant"* and it gives you the exact SQL to create one. 3. **Say *"introspect my database"*** (or just *"continue"*). agami takes it from there: it locks the file down for you (no manual `chmod`), reads your schema, builds the semantic model, and seeds a few validated example queries. You don't move or rename anything. 4. **Ask a question** โ *"how many orders did we ship last month?"* That's the whole setup. Along the way agami scores its confidence in every join and entity, auto-approves the clear ones (real foreign keys, well-named columns), and asks you to sign off the judgment calls. Full walkthrough: [docs/usage.md](docs/usage.md). Connection details for each database: [docs/credentials.md](docs/credentials.md). **Joins not declared in the database?** Many warehouses are views with no foreign keys, where `ship_to_customer_key` joins the customer table only by convention. Introspection can't see those joins, so describe them instead: fill in the [model spec workbook](plugins/agami/shared/model-spec-template.xlsx) โ subject areas, which area owns each table, the joins (including condition joins such as `current_flag = 'Y'`), metrics, sensitive columns and rules โ and attach it when `/agami-connect` asks for context. After introspection reads the listed tables, a dry run checks the whole workbook against them, and the spec replaces the introspected model only if it all validates โ built exactly as it describes. Format: [model-spec-format.md](plugins/agami/shared/model-spec-format.md) *(early: the format may still change)*. ## Databases supported agami runs your SQL **locally**, with whatever's already on your machine โ a native database CLI, the DuckDB universal binary, or a Python driver โ picking the best option available. No agami-operated server ever sees your data. | Database | How agami runs the SQL | | ----------------------------- | ------------------------------------------------------- | | **PostgreSQL** ยท **Supabase** | `psql` CLI ยท DuckDB ยท `psycopg2` | | **Redshift** | `psql` ยท `psycopg2` (speaks the Postgres wire protocol) | | **MySQL** / **MariaDB** | `mysql` CLI ยท DuckDB ยท `pymysql` | | **Snowflake** | `snowsql` CLI ยท `snowflake-connector-python` | | **BigQuery** | `bq` CLI ยท `google-cloud-bigquery` | | **SQL Server** / Azure SQL | `pymssql` | | **Oracle** | `python-oracledb` (thin mode โ no client libs) | | **Databricks** | `databricks-sql-connector` | | **Trino** / Presto | `trino` | | **DuckDB** | `duckdb` binary or module | | **SQLite** | `sqlite3` (Python stdlib โ nothing to install) | agami picks the first method available for your database: a **native CLI** if one's on your `PATH` (nothing to `pip install`), then the **DuckDB** binary where it applies (Postgres ยท MySQL ยท SQLite), then the **Python driver**. Per-database connection fields and the read-only-grant SQL for every dialect are in [docs/credentials.md](docs/credentials.md). A read-only Postgres role still sees the primary and foreign keys (read from `pg_constraint`), and Redshift's late-binding views introspect with their columns. ## Install > **Platform note.** Validated on **macOS and Linux**. On **Windows** the skills > need **[Git for Windows](https://git-scm.com/downloads/win)** (Claude Code uses > Git Bash for its Bash tool). As of 0.9.11 the Python side works on Windows โ > UTF-8 throughout, correct query results, the Microsoft Store Python and Claude > Desktop builds โ but some skill instructions still assume macOS/Linux commands, > and there's no Windows CI run yet ([#362](https://github.com/AgamiAI/agami-core/issues/362)). > The optional local MCP server is pure-stdlib Python and is cross-platform. The same plugin works across Claude Code CLI, VS Code, and Cursor. **Claude Code CLI** โ in the Claude Code prompt: ``` /plugin marketplace add AgamiAI/agami-core /plugin install agami-core@agami ``` Verify with `/plugin list` โ you should see `agami-core@agami` installed. **VS Code / Cursor** โ the slash-command install form above is **CLI-only**; in the extension you install through the UI. Install the **Claude Code** extension, type `/plugin` in the chat to open the **Manage Plugins** dialog, paste `AgamiAI/agami-core` into the marketplace input and click **Add**, then switch to the **Plugins** tab and click **Install** on `agami-core`. Per-host walkthroughs: [docs/install/](docs/install/). ## The trust layer Most AI data agents quietly pick a join, quietly pick a definition of "revenue", and quietly return a number. agami makes every one of those decisions auditable: - **Confidence + review state on every entry.** Each join, metric, and entity carries a flat trust block (`confidence`, `review_state`, and a sign-off identity once approved) โ no vendor blobs, no scores to tune. DB-declared FKs and structural column names auto-approve; everything inferred stays `unreviewed` and surfaces in the Review tab. - **Metrics must be signed off (Rule 1).** A metric needs an approver email, a role, and a non-empty `calculation` before the runtime treats it as truth โ one bad metric skews every report that uses it. A query that uses an unsigned metric still answers, with a warning on the receipt. Joins & entities are lazy (Rule 2): usable while unreviewed, flagged on the receipt until confirmed. - **Every answer ships a receipt** โ the literal SQL, tables + row counts, relationships used (with confidence/state), metric definitions with author + date, data freshness, and the model snapshot hash. A warning banner appears if any unreviewed entry was used, and a total behind a join the model can't vouch for is reported as *undetermined* rather than clean. Nothing is silently trusted. - **Read-only, enforced where the SQL runs โ not in the prompt.** Every statement passes one executor that always refuses writes and side-effecting functions on every dialect (`SLEEP`, `pg_read_file`, Snowflake `SYSTEM$โฆ`, `OPENROWSET`, `UTL_HTTP`, `load_extension`, โฆ). A second pass confines it to the tables and columns the model declares (schema-qualified, so `staging.orders` isn't `sales.orders`) and refuses a projected `SELECT *`. That pass always runs locally; on a server it runs when `AGAMI_GOVERNANCE_ENFORCED` is on, which is **off by default**, and every answer says when it didn't run. Details: [SECURITY.md](SECURITY.md). - **Snapshot-pinned.** The model is YAML under `~/agami-artifacts/