Перейти к содержимому

Agent Context

Это содержимое пока не доступно на вашем языке.

Agent Context is a semantic layer for your agents. It gives every agent in your organization precise, queryable access to your data — structured and unstructured — using standard SQL.

Most approaches to giving agents data rely on embeddings and vector search. That works for fuzzy retrieval — “find documents similar to X” — but it falls apart when agents need precision. “How many orders did customer #4821 place last month?” is not a similarity question. It has one correct answer.

SQL is designed for precision. Structured Query Language exists specifically to ask exact questions of structured data. It filters, joins, aggregates, and computes. When an agent writes a SQL query, it gets the right answer — not an approximation.

Think of SQL as an agent for querying your data. The language model reasons about what to ask; SQL handles how to get it.

Agent Context handles both kinds of data through a single SQL interface:

Structured data — databases, spreadsheets, CSV files — is already a natural fit for SQL. Connect your PostgreSQL database, upload a CSV, or point at an S3 bucket full of Parquet files. Agents query them directly.

Unstructured data — documents, images, conversation logs — gets transformed into embeddings stored in the same database. Agents query these using SQL functions (UDFs) that compare embeddings, combining semantic similarity with the full power of SQL filtering and joins.

This is the inverse of how most vector databases work. Vector databases add basic filters on top of embeddings. Agent Context adds embedding capabilities on top of SQL. The difference matters: SQL is the primary interface, so agents can combine precise structural queries with semantic search in a single statement.

  1. Connect, don’t migrate. We read your data where it already lives. No ETL pipelines, no schema changes, no data copies. Point us at your existing database and your agents can query it.

  2. Standard SQL. No proprietary query languages, no vendor lock-in. If you can write a SELECT statement, your agents can use your data.

  3. Read-only by design. Agent Context never writes back to your sources. All operations are read-only, so connecting is always safe.

A source is a connection to where your data already lives — a PostgreSQL database, a Snowflake warehouse, a CSV file in S3, or any of the supported connectors.

Supported sources:

CategorySources
DatabasesPostgreSQL, MySQL
Data WarehousesSnowflake, Databricks
Cloud StorageAmazon S3, Google Cloud Storage, Azure Blob Storage
FilesLocal file upload

More sources are coming — additional databases and streaming connectors.

A view is a materialized query on top of your sources. Views let you:

  • Shape the data for specific use cases (join tables, aggregate metrics, rename columns)
  • Remove sensitive fields before exposing data to agents
  • Refresh automatically so agents always see up-to-date information

Think of views as the curated layer between your raw data and your agents. You control exactly what agents can see.

Agent Context uses view-level access control — grant access to entire views rather than individual rows or columns.

  • Default deny. Every source and view is inaccessible to agents by default.
  • Explicit grants. You select exactly which users can access specific sources and views.
  • Read-only. Agents can query data but never modify the original source.

See Access Control for the full permission model.

Once you’ve connected your sources and configured access, agents query through the built-in context-lake skill:

1. Connect → Establish connection to Agent Context
2. Catalog → Discover available tables and schemas
3. Query → Run SQL queries to retrieve data

Structured query — precise, exact answers:

SELECT c.name, SUM(o.total) as lifetime_value
FROM "customers" c
JOIN "orders" o ON c.id = o.customer_id
WHERE o.created_at > '2025-01-01'
GROUP BY c.name
ORDER BY lifetime_value DESC
LIMIT 10

Unstructured query — semantic similarity via built-in SQL functions. Agent Context provides embed() to convert text into an embedding vector and cosine_similarity() to compare vectors (returns 0–1):

SELECT title, content, cosine_similarity(embedding, embed('quarterly revenue trends')) AS score
FROM "documents"
WHERE department = 'finance'
ORDER BY score DESC
LIMIT 5

Both paths use the same SQL interface. Agents combine them freely — filtering structured fields while searching unstructured content in a single query. This happens automatically as part of completing your tasks.

  1. Open Agent Context in the Rebyte dashboard
  2. Add a source — pick your database, upload a file, or connect cloud storage
  3. Create views (optional) — shape the data and remove sensitive fields
  4. Grant access — choose which users and agents can query each source or view
  5. Use it — your agents now have the ground truth they need