SLayer puts a semantic layer under AI agents

SLayer is a semantic layer that sits between databases and AI agents, internal tools, dashboards, and scripts. The project says it can auto-create models from schema, compile queries into SQL, and let agents update models at runtime through MCP, REST, CLI, and Python interfaces.

SLayer puts a semantic layer under AI agents

SLayer is a semantic layer for AI agents and internal tools that queries databases, manages data models, and stores natural-language memories about data and queries. The project was posted on Hacker News as “Show HN: SLayer, a semantic layer maintained by your agent.”

According to the project description, SLayer sits between a database and the systems that need to use it, including AI agents, dashboards, scripts, and other internal tools. It is designed to expose structured concepts such as measures, dimensions, and filters rather than forcing every request into hand-written SQL.

⚡ New to this?

This is news about a tool that helps AI systems talk to databases without writing raw SQL every time. A semantic layer is a middle layer that gives data a consistent meaning, like “revenue,” “monthly growth,” or “customer count,” so agents and apps can ask structured questions.

That matters because database queries are easy to get wrong when an AI model has to invent SQL on the fly. SLayer tries to reduce that by turning the database schema into reusable models and translating higher-level requests into SQL automatically.

🦞 OpenClaw angle

If you build self-hosted agents that query business data, put a semantic layer between the agent and the database instead of letting the agent generate raw SQL directly. Start by auto-ingesting your schema, then keep your model definitions in YAML so they can be reviewed and versioned like code.

If you use MCP, test the stdio transport for local agent runs and the HTTP transport for a shared service. Also note the missing pieces in the post: no caching, no pre-aggregation, and no access controls yet, so keep it in a controlled environment until those gaps are covered.

The project says one of its main features is “warm start” model creation. SLayer can inspect a database schema, detect foreign-key relationships, and generate models automatically, including joined dimensions and count-distinct measures. It also supports editing models at runtime, with changes taking effect immediately.

SLayer also lets users specify aggregations at query time instead of baking them into the model. In the examples provided, queries can ask for metrics such as month-over-month percentage change, cumulative sums, lagged values, or comparisons against previous periods. The project says its DSL supports nested formulas and can compile them into the correct SQL for the target database, including joins, aggregations, time-based calculations, and dialect differences.

The project supports multiple ways to access the same functionality. According to the documentation snippets in the post, SLayer exposes MCP, REST API, CLI, and Python interfaces. It can run in-process as a Python module or as a serverless tool via the CLI, and it supports both HTTP and stdio-based MCP transports.

For agent workflows, SLayer can create a datasource, ingest models from a schema, inspect models, and run queries conversationally over MCP. The post also shows CLI examples for starting a server, querying data from the terminal, and connecting to a database with a connection URL. The examples include a demo setup based on the Jaffle Shop DuckDB database and instructions for using Claude Code with an in-process MCP server.

The project says it supports most popular databases and offers two storage backends. YAMLStorage stores models and datasources as YAML files on disk for version control, while SQLiteStorage keeps everything in a single SQLite file. The docs also say custom storage backends can be added for use cases such as tenant isolation.

SLayer’s query language is built around model names, measures, dimensions, time dimensions, and filters. The post gives an example JSON query for counting orders by status, and another for monthly revenue by store with month-over-month percentage change. The project says models are defined as YAML by default, with optional descriptions and named formulas such as average order value.

The author also listed features that are not yet implemented. According to the post, SLayer currently does not include caching or pre-aggregation, and the roadmap also lists access controls, governance, unpivoting, asof joins, and chart generation as incomplete items. The project is released under MIT license.

Source: HN Show HN ↗

More from OpenClaw News