A typed, governed semantic layer is what AI needs. That layer is the product.
SemanticFed is AI-native by architecture rather than by feature: the thing an agent most needs and almost never gets — a documented, versioned, access-controlled model of your business, plus an inspectable record of how every number was computed — is exactly what this platform is. Below is precisely what ships today, what is partly built, and what is still on the roadmap.
Point a language model at raw tables and it has to guess: which column is revenue, in what currency, in which timezone, and which rows this person is allowed to see. It guesses fluently, which is the problem — a confident wrong number is indistinguishable from a confident right one. Every serious attempt to fix this converges on the same answer: the model needs a governed semantic layer between it and the data. SemanticFed is that layer, which makes AI-nativeness a property of its architecture rather than a feature bolted to its side.
Concretely, three things already exist that an agent can stand on. First, a typed semantic model: entities bound to physical sources, dimensions with real data types, metrics with declared aggregations, and typed relationships that describe how sources join — published and versioned, so what a metric means is a governed object and not a copy-pasted SQL fragment. Second, a cost-aware federated query engine that resolves a query against that model, refuses names the model does not contain, decides per source exactly which predicates, projections, and aggregations can be pushed down given that connector's real capabilities, and persists the resulting plan alongside the run. That persisted plan is the accountability artifact AI-generated analytics has always been missing: a sceptic can open a run and see which sources were touched, which filters reached them, how results were joined, and how the estimate compared to reality. Third, a published MCP server — 40 tools over the entire federation domain, plus guided recipes and the schema itself as readable context — so an external agent can operate the platform through the same gateway, with the same identity and the same role checks, as a human clicking in the UI.
What is not built, we say plainly, because the honest version is more useful than the flattering one. There is no natural-language interface and no AI-authored query yet; there is no LLM code in the federation service at all. The in-app assistant is not wired — the app's AI page is currently a placeholder. The autonomous loops that would triage a degrading source, propose a cache policy, or flag a newly-appeared PII column are designed and ticketed, not running. Two gaps are governance rather than absence, and matter more than the missing features: the agent tool surface does not yet require confirmation before irreversible operations, and stored row and column policies are not yet evaluated at query execution — so today's guarantee that AI is not a policy bypass holds at the operation level, not the row level. All of it is sequenced behind the shared platform AI runtime rather than a bespoke model integration in this product, and none of it is presented here as done.
Every capability on this page is labelled with what is actually built in SemanticFed today — shipped, in progress, or on the roadmap.
AI-native by architecture, not bolted on
Four architectural choices that make AI a first-class part of SemanticFed rather than a chat window on the side.
The model is the grounding
Agents bind to entities, dimensions, metrics, and typed relationships that are published, versioned, and documented — so a query references fields that provably exist rather than plausible-sounding column names. Grounding is a schema property here, not a prompting technique.
One authorization edge, agents included
Authorization happens once, at the workspace gateway, driven by an explicit action, resource, and scope on every operation. Services never validate tokens. An agent is therefore an ordinary caller with an identity, not a new client type with its own rules.
Every answer resolves to a plan
Each run persists the plan that produced it: join order, what was pushed down to which source, estimated against actual cost. AI-authored queries inherit auditability by construction instead of needing it retrofitted after someone disputes a number.
An API already shaped for agents
Every domain object is reachable through a prefixed, permission-annotated federated schema — which is why the MCP server needed no parallel permission system, and why the CLI, SDKs, and agents all drive the same operations a human does.
From intent to a governed action
Walk the path a request takes. Select any stage to see what happens there and what backs it.
Stage 1 of 6 · Connect
Register sources, keep their health first-class
Connectors and data sources are catalogued, with a validated connectivity lifecycle and recorded health probes.
A connector describes a source technology and its capabilities; a data source is a concrete endpoint with a credential reference and a push-down flag. Sources move through a validated lifecycle — draft, connected, degraded, disconnected, disabled — and every health probe records a verdict, a latency, and a message. This is the substrate the planned autonomous triage loop reads. Today the signal is recorded faithfully and acted on by hand.
How it works: Shipped: SourcesService probe recording + status reconciliation; semRecordConnection, semTransitionDataSource with a validated transition guard.
What the AI in SemanticFed actually does
Filter by delivery status, then open any capability for the detail and what backs it. No capability is listed as shipped without something in the product behind it.
Where the AI shows up
The places AI meets the work in SemanticFed — and how far each one has actually got.
MCP & external agents
ShippedThe one AI surface that exists in code today: a published Model Context Protocol server that hands the entire governed semantic layer to an agent in your editor or pipeline, through the same gateway and identity a human uses.
- 40 tools spanning connectors, data sources, health probes, models, entities, dimensions, metrics, relationships, saved queries, runs, and access policies
- Two guided prompts encoding the model-build and query-federation recipes end to end
- Federation schema plus connector, source, and model catalogs exposed as readable agent context
- Stdio transport by default for editors, optional HTTP transport for services
- Open gap: irreversible operations are not yet confirmation-gated — treat agent access like a write-capable service account
See it as a real scenario
Every AI capability above shows up in a concrete SemanticFed story. Open one to read the full walk-through.
Let an AI agent run your federation over MCP
The shipped agent surface: 40 tools, guided recipes, and the schema as context — through the same gateway a human uses.
Read the storyMake every AI answer openable, not just plausible
Each run persists join order, push-down decisions, and estimate versus actual — the accountability substrate AI analytics needs.
Read the storyMake sure AI is not a way around your access rules
Agents authorized at the same edge, with the same roles and tenant scoping as people — plus the two gaps we have not closed.
Read the storyStart modelling from a draft the AI proposed
Designed to turn a registered source into reviewable draft entities, dimensions, metrics, and relationships — publishing stays human.
Read the storyHave an agent notice a degrading source before your analysts do
Probe history reconciled into lifecycle decisions on a cadence, with the owner notified — the one loop allowed to act.
Read the storyGet caching proposals from an agent that reads your run history
Hot, slow, repeatedly-run queries surfaced with a suggested cache policy and the evidence behind it — you apply it.
Read the storyCatch a new PII column the day it appears
Likely-sensitive fields flagged with a proposed deny policy that stays inactive until a human approves it.
Read the storyAI you can actually let near your data
An AI-native product has to be governable. Here is where SemanticFed stands on each control — including the parts still being built.
One enforcement point, agents included
Permissions are declared on every operation as an explicit action, resource, and scope, and enforced at the workspace gateway from the composed schema. Services never validate tokens themselves, so there is no second code path an agent could take.
Workspace isolation on every write
Mutations filter by the calling workspace and assert exactly one matched row before succeeding, so an identifier guessed or leaked from another tenant resolves to a not-found rather than a cross-tenant write. This applies identically to agent calls.
Answer provenance you can open
Every run persists which sources were touched, which filters reached them, the join order, and how the cost estimate compared to reality — so a disputed number can be verified rather than argued about. Generated queries will inherit this unchanged.
Nothing becomes AI-only
Every critical action — modelling, publishing, querying, policy changes — is doable by hand today and is required to stay that way as AI lands. Automation is designed as an accelerator, never as the sole path to a capability.
Confirmation before irreversible agent actions
Stated as a gap, not a feature: the agent surface does not yet require explicit confirmation before deleting a modelled entity or archiving a published model. The mechanism exists in the shared tool layer and arming it for this product is tracked work.
Row and column policy at execution time
Also stated as a gap: policies are authored and toggled but not yet evaluated when a query runs. Until they are, our no-policy-bypass guarantee covers who may invoke an operation, not which rows or columns come back — for humans and agents alike.
Models
There is no model provider wired into SemanticFed today — the federation service contains no LLM, embedding, or vector code at all, and we would rather state that than imply a capability. When the AI decision layer lands it is specified to consume the shared platform AI runtime, which is provider-switchable with Gemini as the intended default, rather than a bespoke integration inside this product. That choice is deliberate: a per-product gateway would mean per-product credential handling, per-product cost accounting, and no common agent-run ledger. Bring-your-own-key is not offered today and is not promised. The one AI-adjacent surface that is live, the MCP server, calls no model itself — your own agent supplies the model and SemanticFed supplies the governed tools, schema, and permission checks it operates through.
- None wired in SemanticFed today — no provider SDK exists in the federation service
- Gemini — intended default of the shared platform AI runtime once it ships (not yet built)
- Provider-switchable by design via the shared runtime, so no model choice is baked into this product
- Your own agent's model, when driving SemanticFed over MCP — SemanticFed makes no model call in that path
The honest answers
One surface: the MCP server. It is published and callable, exposing 40 tools across the whole federation domain, two guided multi-step prompts, and the federation schema plus workspace catalogs as agent-readable resources. Under it sits a genuinely shipped decision substrate — the typed semantic model, the cost-aware planner with capability-gated push-down, real parameterized execution against Postgres sources, and a persisted plan summary per run. Everything else is honest roadmap: there is no natural-language interface, no AI-authored query, no in-app assistant, and no autonomous loop. The federation service contains no LLM code whatsoever.
Put SemanticFed’s AI to work
SemanticFed is AI-native by architecture rather than by feature: the thing an agent most needs and almost never gets — a documented, versioned, access-controlled model of your business, plus an inspectable record of how every number was computed — is exactly what this platform is. Below is precisely what ships today, what is partly built, and what is still on the roadmap.