# Agentic Data Access

AI agents need to reason over organizational data to answer questions, make
decisions, and take action. The challenge is that this data is scattered across
relational databases, graph databases, data lakes, and SaaS tools—each with its
own query language, connection protocol, and access model. Teaching agents to
navigate this fragmentation is brittle and error-prone.

MemGQL solves this by exposing all connected data sources as a single, unified
graph. Agents use standard GQL to explore relationships, traverse connections,
and retrieve data—without knowing where each dataset lives or how to access it.

## The Problem

Modern AI agents face a few critical barriers when accessing organizational data:

1. **Fragmented APIs**: Each system exposes a different interface—SQL for
Postgres, Cypher for Memgraph, REST for SaaS tools. Agents must learn multiple
query languages and connection patterns.

2. **Context Loss**: When data is split across systems, agents lose the ability
to follow relationships. A customer ID in PostgreSQL may reference the same
entity as a node in Memgraph, but the agent has no way to know this without
explicit integration code.

3. **Discovery Friction**: Agents cannot explore data autonomously. They need
hardcoded schemas, pre-defined mappings, and human-written prompts to know what
questions to ask and where to look.

## The Solution

MemGQL provides a federated graph layer that abstracts all backend systems
behind a single GQL endpoint. Agents connect to one URL and query everything.

### Autonomous discovery

Agents don't need hardcoded schemas or hand-written `USE` clauses. A single
[`SHOW SCHEMA`](https://memgraph.com/docs/memgraph-zero/memgql/multiple-graphs#schema-discovery) returns
the unified index of every label, relationship type, and property across all
connected backends: the agent's map of what's queryable and where the
entities connect.

From there, [schema-based routing](https://memgraph.com/docs/memgraph-zero/memgql/multiple-graphs#routing)
lets the agent write a plain GQL query and let the engine pick the backend from
the labels and properties it referenced:

```gql
-- The agent doesn't need to know `name` lives in PostgreSQL or that
-- FRIEND_OF lives in Memgraph; both route automatically.
MATCH (p:Person {id: 1})-[:FRIEND_OF]->(f:Person) RETURN f.name;
```

Routing is strict: if a query is ambiguous or matches nothing, MemGQL returns
an actionable error that names the candidate sources and points back at
`SHOW SCHEMA`, so an agent can self-correct instead of failing silently.