DEV Community: Claix

Read-Only Postgres Role for AI Agents: 7 Gaps to Close

Claix — Sat, 31 Oct 2026 15:58:53 +0000

A read-only Postgres role for AI agents is the right first step. It is also not enough on its own.
Most guides stop at GRANT SELECT. We ran the usual setup on PostgreSQL 16, tried to get around it the way a manipulated agent or a careless query would, and found seven places where "read-only" doesn't mean what people assume. Each one comes with the SQL to reproduce it and the fix.
Quick answer
A read-only Postgres role for an AI agent should be a dedicated login role with no superuser or BYPASSRLS, SELECT granted only on the columns the agent needs, and timeouts set. But default_transaction_read_only and statement_timeout are defaults that a session can change, a SECURITY DEFINER function can still write, and anything you grant can still be read by a manipulated agent. The real barrier is what the role is allowed to do, so grant as little as possible and never give the agent a raw SQL session.
In this post

How we tested
The baseline setup
Gap 1: the read-only setting is a default, not a lock
Gap 2: your timeout can be switched off
Gap 3: a SECURITY DEFINER function can write for you
Gap 4: table names stay visible
Gap 5: SELECT * fails, and the error blames the table
Gap 6: row-level security with no policy returns nothing
Gap 7: everything you grant can be read
The hardened setup in one block
FAQ How we tested Everything below ran on PostgreSQL 16.15 in a clean database, with each statement sent from a normal login role. The results are copied from the terminal. Nothing needs an extension, and you can paste each block into psql and compare. The sample schema has three tables: customers, orders and secrets. The agent should reach only some columns of the first two, and nothing in the third. The baseline setup This is the setup most guides describe, plus the settings people add to make it "read-only". CREATE TABLE public.customers (id serial PRIMARY KEY, name text, email text); CREATE TABLE public.orders ( id serial PRIMARY KEY, customer_id int REFERENCES customers(id), status text, total numeric, internal_notes text ); CREATE TABLE public.secrets (id serial PRIMARY KEY, token text);

CREATE ROLE claix_agent WITH LOGIN PASSWORD 'use-a-secret-manager'
NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOREPLICATION NOBYPASSRLS;

GRANT CONNECT ON DATABASE mydb TO claix_agent;
GRANT USAGE ON SCHEMA public TO claix_agent;
GRANT SELECT (id, name) ON public.customers TO claix_agent;
GRANT SELECT (id, customer_id, status, total) ON public.orders TO claix_agent;

ALTER ROLE claix_agent SET default_transaction_read_only = on;
ALTER ROLE claix_agent SET statement_timeout = '2s';

Two things to avoid at this stage. Don't use GRANT SELECT ON ALL TABLES, which also covers tables you didn't mean to expose. And don't use the built-in pg_read_all_data role for an agent: it grants read access to every table in the database, which is far more than an agent needs.
Gap 1: the read-only setting is a default, not a lock
The assumption: default_transaction_read_only = on means the role can't write.
What happens: it means new transactions start read-only. The session can change that. To see it, we made a second role that does have INSERT and the same read-only default:
INSERT INTO orders(customer_id, status, total) VALUES (1, 'x', 1);
ERROR: cannot execute INSERT in a read-only transaction

SET default_transaction_read_only = off;
INSERT INTO orders(customer_id, status, total) VALUES (1, 'x', 1);
-- succeeded
The same happened with BEGIN READ ONLY; followed by SET TRANSACTION READ WRITE; as the first statement: the write went through.
What stopped the write in the real agent role was something else. After SET default_transaction_read_only = off;, an INSERT from claix_agent failed with:
ERROR: permission denied for table orders
The fix: treat the setting as a safety net and the privileges as the barrier. Grant SELECT only. If you can, connect the agent to a read replica, because a standby server rejects writes whatever the session sets (we didn't test this one).
Gap 2: your timeout can be switched off
The assumption: ALTER ROLE ... SET statement_timeout = '2s' caps every query.
What happens: it sets the starting value. The session can raise it or remove it:
SHOW statement_timeout;
2s

SELECT pg_sleep(3);
ERROR: canceling statement due to statement timeout

SET statement_timeout = 0;
SELECT pg_sleep(3);
-- ran to completion
The fix: the timeout protects you only if the agent can't send a SET. So never give the agent a raw SQL session. Your code should run a single validated SELECT, set the limits itself for each transaction (SET LOCAL statement_timeout = '5s') and add its own timeout around the call. A pooler or proxy that cancels long queries is a second layer, and you should check its documentation for the exact setting.
Gap 3: a SECURITY DEFINER function can write for you
The assumption: a role with only SELECT can't change data.
What happens: functions declared SECURITY DEFINER run with the privileges of their owner, and by default Postgres lets everyone execute functions. We created one that inserts into secrets, a table claix_agent can't touch:
CREATE FUNCTION public.archive_orders() RETURNS void
LANGUAGE sql SECURITY DEFINER AS $$
INSERT INTO public.secrets(token) VALUES ('written-by-function')
$$;
With the read-only default on, the call failed. After the session switched it off (gap 1), it worked, and secrets went from one row to two.
The fix: find these functions and remove public execute access from the ones that write:
SELECT p.oid::regprocedure
FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public' AND p.prosecdef;

REVOKE EXECUTE ON FUNCTION public.archive_orders() FROM PUBLIC;
After the revoke, the same call returned permission denied for function archive_orders. Give EXECUTE back to the roles that need it. You can also run ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; so that future functions aren't public by default, but that affects every function created afterwards by the same role, so check your application first.
Gap 4: table names stay visible
The assumption: if the role can't read a table, it can't see it.
What happens: it can't read the contents, but the catalog still lists the name:
SELECT tablename FROM pg_tables WHERE schemaname = 'public';
customers
orders
secrets

SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
customers
orders

SELECT * FROM secrets;
ERROR: permission denied for table secrets
information_schema shows only what the role has privileges on. pg_catalog shows everything.
The fix: don't put anything sensitive in a table or column name. And when you build the description of your schema for an agent, read it with the agent's own role through information_schema, so the agent is told about the tables it can use and nothing else.
Gap 5: SELECT * fails, and the error blames the table
The assumption: with a column-level grant, SELECT * returns the allowed columns.
What happens: it fails, and the message names the table, not the column:
SELECT * FROM orders;
ERROR: permission denied for table orders

SELECT id, status, total FROM orders ORDER BY id LIMIT 2;
1|shipped|10
2|pending|20

SELECT internal_notes FROM orders;
ERROR: permission denied for table orders
That is useful: an agent can't get a column you didn't grant by accident. It is also confusing when you debug, because the table looks denied even though only one column is.
The fix: make your agent list its columns, and reject SELECT * in your validator so the failure is a clear message from your code and not a database error. A view with only the safe columns is a simple alternative:
CREATE VIEW public.order_status WITH (security_invoker = true) AS
SELECT id, status FROM public.orders;

GRANT SELECT ON public.order_status TO claix_agent;
The security_invoker option (PostgreSQL 15 and later) makes the view use the privileges and row-level security of the caller, not the view's owner.
Gap 6: row-level security with no policy returns nothing
The assumption: enabling row-level security on a table limits what the agent sees.
What happens: if the role is not the owner and no policy applies to it, it sees zero rows. That fails safe, and it looks like an empty table:
ALTER TABLE public.customers ENABLE ROW LEVEL SECURITY;

SELECT count(*) FROM customers; -- as claix_agent
0

CREATE POLICY agent_read ON public.customers FOR SELECT TO claix_agent USING (true);

SELECT count(*) FROM customers;
2
The fix: if you use row-level security, write a policy for the agent role with the narrowest condition that works, and check that the role is not the table owner and does not have BYPASSRLS. If an agent suddenly "finds nothing", look at the policies first.
Gap 7: everything you grant can be read
The assumption: once the role is read-only, the data is safe.
What happens: a read-only role protects what it can't reach. It doesn't protect what you gave it. Instructions hidden in a user message, a document or a database field can change what an agent asks for, and the role will answer any query for data it was granted. Supabase's own documentation names prompt injection as the main risk of connecting an agent to your data, and says its MCP server is designed for development and testing.
A role also can't tell a useful query from a pointless or expensive one, or a correct query from one that is valid and wrong, and it doesn't separate one person's rows from another's.
The fix: grant less, and add layers outside the database:
• Validate every query with a real SQL parser before it runs: one SELECT, approved tables, an allowlist of functions.
• Add a row limit, a timeout and a cost check.
• Treat query results as untrusted data.
• Log every request: the question, the query and the result.
• Keep per-user rules in row-level security or in your application.
The hardened setup in one block
This is the baseline plus the fixes that belong in the database. We ran the whole block on a clean cluster and checked that granted columns work and others don't.
-- 1. A dedicated role, not your app user and not postgres
CREATE ROLE claix_agent WITH LOGIN PASSWORD 'use-a-secret-manager'
NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOREPLICATION NOBYPASSRLS
CONNECTION LIMIT 10;
GRANT CONNECT ON DATABASE mydb TO claix_agent;
GRANT USAGE ON SCHEMA public TO claix_agent;

-- 2. Columns, not whole tables
GRANT SELECT (id, name) ON public.customers TO claix_agent;
GRANT SELECT (id, customer_id, status, total) ON public.orders TO claix_agent;

-- 3. Guardrails (defaults the session can change)
ALTER ROLE claix_agent SET default_transaction_read_only = on;
ALTER ROLE claix_agent SET statement_timeout = '5s';
ALTER ROLE claix_agent SET idle_in_transaction_session_timeout = '10s';

-- 4. Find functions that run with their owner's privileges
SELECT p.oid::regprocedure AS security_definer_function
FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public' AND p.prosecdef;

-- 5. Remove public execute access from any that write
REVOKE EXECUTE ON FUNCTION public.archive_orders() FROM PUBLIC;
-- GRANT EXECUTE ON FUNCTION public.archive_orders() TO app_user;
Then add what a database role can't: validation, limits, logging, and a controlled way for the agent to ask.
Where Claix fits
Claix is a managed service between your agent and your database. You connect Postgres or Supabase with a read-only role like the one above, choose the tables and columns each agent can use, and write a short guide with your rules. Your agent sends questions to its own endpoint and gets typed answers back, so it never holds a database connection or sends raw SQL. Every request is traced.
It doesn't replace the role. Claix connects with a role like this one, and what that role can read is still the ceiling. You can try it in the Sandbox and read the docs at claix.dev.
FAQ
Is a read-only user enough to secure a database for an AI agent? No. It is the first layer. A session can change settings such as default_transaction_read_only and statement_timeout, a SECURITY DEFINER function can still write, and a manipulated agent can read anything you granted. Add query validation, limits and logging.
How do I create a read-only user in Postgres? Create a login role without superuser or BYPASSRLS, grant CONNECT on the database and USAGE on the schema, and grant SELECT only on the tables or columns it needs. The block in this post does that.
Can a read-only Postgres user still modify data? It can if it can call a SECURITY DEFINER function that writes, or if the session lifts the read-only default and the role has write privileges. With only SELECT privileges and no public execute access to writing functions, it can't.
How do I limit an AI agent to certain columns in Postgres? Use column-level grants, such as GRANT SELECT (id, status) ON orders TO claix_agent, or expose a view with only the safe columns.
Should an AI agent connect to a read replica? It is a good extra layer, because a standby server rejects writes whatever the session sets, and it keeps heavy queries away from your main database. It doesn't replace limiting what the role can read.
Does this work on Supabase? Yes. Supabase is Postgres, so the same SQL works in its SQL editor. Supabase's MCP server has a read-only option that runs queries as a read-only Postgres user, and its documentation says the server is designed for development and testing.
How do I stop an AI agent's long-running queries? Set a statement_timeout for the role, set it again in your code for every transaction, and make sure the agent can't send SET statements. A pooler or proxy that cancels long queries adds another layer.
Sources and further reading
• PostgreSQL documentation, GRANT: https://www.postgresql.org/docs/current/sql-grant.html
• PostgreSQL documentation, CREATE FUNCTION and SECURITY DEFINER: https://www.postgresql.org/docs/current/sql-createfunction.html
• PostgreSQL documentation, client connection defaults: https://www.postgresql.org/docs/current/runtime-config-client.html
• PostgreSQL documentation, row security policies: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• PostgreSQL documentation, predefined roles: https://www.postgresql.org/docs/current/predefined-roles.html
• Supabase documentation, MCP server: https://supabase.com/docs/guides/getting-started/mcp
SEO notes (not part of the post)
Why this angle. I searched the main phrase, how to connect an AI agent to a database safely, and the results are crowded: a dev.to post from September 2026 on giving an agent safe, read-only access, a hoop.dev guide, an Airbyte guide on connection patterns, Microsoft's SQL MCP Server documentation and several open-source projects. A generic how-to would compete with all of them. This post targets a narrower phrase with the same intent, read-only Postgres role for AI agents, and brings something those results don't: tested results, with the SQL to reproduce them. That is your best chance to rank and to be linked. I can't give you search volumes, so check the phrase in a keyword tool before you commit.
Keyword placement
Element
What it contains
Title
Read-Only Postgres Role for AI Agents (primary keyword first)
First sentence
The primary keyword, with a clear claim
Description (front matter)
Primary keyword and the numbers 7 and PostgreSQL 16
Quick answer
A direct answer in about 90 words, for featured snippets and answer engines
H2 headings
Each gap, plus FAQ questions in the words people use
Secondary keywords
AI agent database access, Postgres read-only user, default_transaction_read_only, statement_timeout, SECURITY DEFINER, row-level security, Supabase, MCP, prompt injection
Tags
postgres, ai, security, database (dev.to allows four

Your AI Agent Isn't the Problem: Its Database Access Is

Claix — Sun, 13 Sep 2026 12:42:07 +0000

Most AI agent workflows don't fail because the model is incapable.
They fail because the agent gets the wrong data, or gets the right data in the wrong shape.
A typical business workflow starts with a question like these:
• Has this customer accepted marketing consent?
• What is the status of this order?
• Which reservation does this guest have next?
The answer lives in a relational database such as Postgres or Supabase.
The agent is then expected to:
• Find the right tables
• Understand what the columns and codes mean
• Join tables correctly
• Write a query that is valid and read-only
• Read only what it is allowed to read
• Return a predictable result
• Trigger the next step in an automation
Sometimes it works.
Sometimes the output looks convincing but is wrong: a join that duplicates rows, a status spelled differently so that no rows match, a column nobody should have read, or an answer in a different shape that breaks the next node in the workflow.
This is the part of AI automation that is often underestimated: before an agent can reason about your business data, access to that data needs to be controlled, described and predictable.
The database problem behind many agent failures
When people talk about AI agents, they usually focus on the reasoning layer.
They discuss:
• Which model to use
• How many tools the agent should have
• Whether to use LangGraph, CrewAI, AutoGen, or another framework
• How to create planning loops
• How to give the agent memory
• How to reduce hallucinations
• How to make the agent autonomous
All of those decisions matter.
But in many real-world workflows, the biggest problem appears earlier.
The agent is connected to a database that was never designed to be queried by a language model.
Tables have names like t_ord_2. A status column holds the codes C, P and X. A relationship between two tables exists only in someone's head. Some columns contain internal notes that should never leave the company.
The agent has to solve the data problem and the business problem at the same time.
That creates unnecessary uncertainty.
Imagine an order-status workflow. The actual task may be simple:

Read the customer's question.
Find the order.
Read its status.
Check whether the customer accepted marketing consent.
Reply, or escalate to a person. The difficult part is often not the reply. The difficult part is making sure the agent uses the right table, the right status value, the right join and only the columns it is supposed to read. Why giving the agent a database connection is fragile A common first approach is to give a general-purpose model a database connection, or a database MCP server, and let it write SQL. For example: Check whether Javier Perez accepted marketing consent and tell me his next reservation. This can work for prototypes. However, production workflows usually need stronger guarantees. The output changes shape. One execution may return: { "consent": true, "next_reservation": "2026-11-07 21:00" } Another may return: Yes, Javier Perez has accepted marketing consent. His next reservation is on Saturday at 9 PM. Both responses look reasonable to a human. They are not equivalent to an automation. A downstream node expects a boolean. If it receives a sentence, an object with different key names, or a value that is missing, the workflow can fail silently. Wrong answers don't raise errors. A query that spells a status value differently runs fine, matches no rows and returns an empty result. Nothing fails, and someone acts on it. A prompt is not a permission. Instructions hidden in a user message, or in text stored in a database field, can change what an agent does. Supabase's own documentation names prompt injection as the main risk of connecting an agent to your data, and says its MCP server is designed for development and testing. A rule written in a prompt can be overridden. A permission in the database can't. Context grows. If the agent sees the whole schema, with hundreds of tables, it receives far more than it needs. That increases: • Token usage • Latency • Cost • The chance of confusing similar tables • The amount of data the model could reach There is no record. When an answer looks wrong, you can't see which table the agent used or what query it ran. The more of your database the model can see, the more important it becomes to control exactly what it can use and what it returns. A better separation of responsibilities A more reliable architecture separates data access from agent reasoning. Instead of asking one general-purpose agent to understand the schema, write the query, protect the data and decide what to do, the workflow can be divided into layers: Question ↓ Description of your data ↓ Scoped access: only chosen tables and columns ↓ Read-only query ↓ Typed answer ↓ Business rules and agent reasoning ↓ Action or human review Each layer has a different job.
Describing your data This layer says what each table is for and how tables relate to each other. For example, that orders.customer_id points to customers.id, and that cancelled orders stay in the orders table.
Scoping access This layer decides which tables and columns can be used for a given purpose. Whatever is not included doesn't exist for the agent.
Retrieving The query itself is a single read-only SELECT, restricted to the scope above. It is the least interesting part, and the part most people try to put first.
Typing the answer The result becomes a value the next step can use: a boolean, a number, a text, a date, a list or an object.
Validating The workflow checks what comes back before it acts: • Is the value present? • Is it the expected type? • Is it within a reasonable range? • Does it match what another source says? • Is the answer empty?
Reasoning Only after the data has been retrieved in a usable form should the agent evaluate business logic. For example: Does this order exceed the customer's approval limit by more than 5%? That is a much narrower and more reliable task than asking the same agent to find the tables, write the query and make the decision from scratch. Introducing Claix Claix is a managed service that your agent calls to get answers from your database. It is a controlled database retrieval layer for AI agents. The core idea is simple: Ask a question. Get a typed answer from the data you allowed. Claix works with Postgres and Supabase. You set it up in four steps:
Connect your database with a read-only role.
Review your Data Map. Claix drafts a description of your tables and the relationships between them, and you correct it.
Create routes. A route lists the tables and columns that can be used for one purpose, with a short guide of rules.
Create an agent. It has a name, which becomes its URL, a business prompt, the routes it can use and a response mode. The read-only role is the foundation. It is a few lines of SQL: CREATE ROLE claix_agent WITH LOGIN PASSWORD 'use-a-secret-manager' NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOREPLICATION NOBYPASSRLS;

GRANT CONNECT ON DATABASE mydb TO claix_agent;
GRANT USAGE ON SCHEMA public TO claix_agent;
GRANT SELECT (id, name, marketing_consent) ON public.customers TO claix_agent;
Columns that aren't granted can't be read, whatever the agent asks.
The business prompt is plain text. For example:
You are the reservations assistant for a restaurant group.
Use the Bookings route for questions about reservations.
Use the Customers route for questions about consent.
Status C means confirmed, P means pending and X means cancelled.
The agent's endpoint becomes /agent/ followed by its name. No code to host, no framework to learn.
A simple API workflow
Claix is designed for backend integrations, scripts, automation platforms and agent tools.
You send one or several questions, each with the type of answer you expect:
const response = await fetch("https://claix.dev/agent/hr-assistant", {
method: "POST",
headers: {
"x-api-key": process.env.CLAIX_API_KEY,
"Content-Type": "application/json"
},
body: JSON.stringify({
questions: [
{ question: "What is the phone number of the employee named Carlos?", format: "string" },
{ question: "Has the customer Javier Perez accepted marketing consent?", format: "boolean" },
{ question: "What is the job title of Marta?", format: "string" }
]
})
});

const [result] = await response.json();

console.log(result.ia_response);
The response keeps each question next to its answer, in the same order:
[
{
"user_ask": [
{ "question": "What is the phone number of the employee named Carlos?", "format": "string" },
{ "question": "Has the customer Javier Perez accepted marketing consent?", "format": "boolean" },
{ "question": "What is the job title of Marta?", "format": "string" }
],
"ia_response": [null, true, "Waiter"],
"log_id": "9ff38974-1392-4c1a-83e5-3b2f09bb43dc"
}
]
The important part is not just that the agent understood the question.
The important part is that the result is ready to be passed into another system.
For example:
Support ticket arrives
↓
Claix agent: order status and consent
↓
Branch on the typed values
↓
Reply, update the CRM or escalate
The same pattern works with n8n
A common n8n workflow might look like this:
Webhook or Trigger
↓
HTTP Request to the Claix agent
↓
IF node on a boolean or a number
↓
Slack / Email / CRM / Database
The HTTP Request node sends the questions to the agent's URL with your API key. Once the response comes back, the rest of the workflow works with typed values instead of trying to interpret a paragraph or a table of rows.
For a simple approval workflow, the next node might receive:
{
"order_status": "shipped",
"order_total": 1284,
"approval_limit": 1000
}
The agent doesn't need to rediscover the order total.
It can focus on the actual decision:
The order is above the approval limit. Request human approval.
That is a much better use of an agent.
A query result is not the same as an answer
A query returns rows. A business workflow usually needs something more specific:
Has this customer accepted marketing consent?
What is the status of this order?
When is this guest's next reservation?
The rows may contain several columns, several records and values that need interpreting. The workflow needs one value with a meaning.
That is why each Claix agent has a response mode:
Mode
What you get
Good for
Data
The result of the query as it comes out of your database
Code and other agents that process the result themselves
Answer
A reasoned answer in the type you asked for
Results that go straight to a person or to a workflow that needs a single value
In Answer mode, the rows returned by the query are sent to a model so it can write the answer. If your data is sensitive, take that into account when you choose the mode.
Handling missing information safely
One of the most important properties of a data workflow is how it handles missing data.
If the answer is not in the data the agent is allowed to use, the system should not invent a plausible value just to fill the gap.
In the response above, the first answer is null. The phone number is not in the data that agent can use, so Claix doesn't make one up.
A missing value is different from an inferred value.
That distinction matters in finance, legal workflows, compliance, procurement and customer operations.
A downstream workflow can then explicitly decide what to do:
if (result.ia_response[0] === null) {
return "manual_review";
}
This is more reliable than allowing a model to produce a number that looks right.
Routes and agents: deciding what each agent can see
Not every agent should see the same data.
A support bot, an internal assistant and a workflow check might all work on the same database, and each one needs a different slice of it.
That is the job of routes and agents:

Route
Agent
Decides
What data can be used, and how to read it
Who asks, and which routes it can use
Contains
Name, description, tables, columns and a guide
Name, description, business prompt, routes and response mode
A route might include only orders.status and orders.total. Another might include only a customer's name and consent. An agent can only use the routes attached to it.
This helps keep the main workflow focused and gives the data layer the responsibility for locating what is relevant.
Access is scoped per agent, not per end user: an agent can read everything its routes include, for every person who calls it. If each person must see only their own rows, enforce that in your database or in your application.
Traces: what happened, and why
Every response includes a log_id.
Use it to look up the request in Traces and see how it was answered: which route was used, the query that ran and what came back.
This matters when an answer looks wrong, because the useful question is not "why did the agent say that?" but one of these:
• Was the question understood?
• Was the right route chosen?
• Was the data missing?
• Was the description of a table unclear?
• Did the business rule calculate incorrectly?
You can also try your agents in the Sandbox with real questions before connecting them to your workflow.
Where this fits in an agent architecture
Claix is not intended to replace the entire agent stack.
It is better understood as a specialist tool, or a data agent.
A general-purpose orchestrator can decide:
This task needs the status of an order. Ask the data agent.
Claix returns a typed value.
The orchestrator then decides what to do next:
The order is shipped. Tell the customer.
This produces a clean division:
Orchestrator:
Planning, routing, decisions, tool selection

Claix:
Description of your data, scoped access, retrieval, typed answers

Business system:
CRM, ERP, database, spreadsheet, email, notifications
The main agent does not need to know your schema or write SQL.
It only needs to know when to use the capability and how to consume the result.
Every Claix agent is reachable over REST, MCP and A2A, so the same agent can serve a script, an MCP client or another agent.
A practical example: approving an invoice against the purchase order
Consider a procurement workflow.
The company receives a supplier invoice as a PDF. The purchase order lives in its database.
The workflow needs to determine whether the invoice should be approved.
A fragile implementation might give one agent the PDF and a database connection:
Read this invoice and tell me whether it matches the purchase order.
A more controlled implementation would look like this:
Step 1: Extract the invoice
The invoice arrives as a document, so a document extraction step turns it into fields. Claix Ingest does this, or you can use your own.
{
"invoice_number": "INV-2026-00456",
"supplier_name": "Acme Supplies Ltd",
"total_amount": 1284.5
}
Step 2: Ask the data agent for the purchase order
{
"questions": [
{ "question": "What is the approved total, in euros, of the purchase order for Acme Supplies Ltd?", "format": "integer" },
{ "question": "Is the supplier Acme Supplies Ltd currently active?", "format": "boolean" }
]
}
The answers come back typed:
{
"ia_response": [1200, true]
}
Step 3: Apply the business rule in code
difference = 1284.5 - 1200 = 84.5
difference_percentage = 84.5 / 1200 = 7.04%
This is arithmetic, so normal code does it.
Step 4: Decide
The invoice is 7.04% above the purchase order. Route to manual review.
The agent is still useful.
It simply is not forced to find the tables, write the query, protect the data and make the decision all at once.
Claix and the A2A direction
As agent systems become more modular, specialized capabilities need to be discoverable and callable by other agents.
A data agent can be useful in an Agent2Agent architecture because it offers a focused capability:
I can answer typed questions about this database, only from the tables I was given.
An orchestrator might delegate a task such as:
Is this customer's marketing consent recorded?
The data agent handles the database-specific work and returns a machine-readable result.
This is preferable to giving every agent direct access to the database and expecting each one to work out the schema.
Specialization can improve:
• Security boundaries
• Permission management
• Cost control
• Observability
• Reusability
• Testing
• Error handling
It also means a data-access capability can be reused across different orchestrators and applications.
Using Claix from Python
A basic request can be made with requests:
import requests

response = requests.post(
"https://claix.dev/agent/hr-assistant",
headers={"x-api-key": "YOUR_API_KEY"},
json={
"questions": [
{"question": "Has the customer Javier Perez accepted marketing consent?", "format": "boolean"},
{"question": "What is the job title of Marta?", "format": "string"},
]
},
)
response.raise_for_status()

result = response.json()[0]

consent, job_title = result["ia_response"]
print(consent, job_title)
print(result["log_id"])
The same pattern can be used from Node.js, n8n, Make, Zapier, an MCP client or a custom backend.
When to use Claix instead of building everything yourself
Building your own data access can be a good choice.
For a small number of fixed questions, a few well-written functions that your agent calls may be all you need.
A managed service becomes more interesting when:
• You have several agents on the same database, each needing different data.
• The questions vary and the rules change.
• You want typed answers rather than text or raw rows.
• You want a record of every request.
• You would rather not host and maintain query code.
• You want to describe your data in plain language and let non-engineers help.
• You want to choose your own model with your own key, or use a managed one.
It is not the right fit when:
• You need per-end-user row filtering inside the tool.
• You use a database other than Postgres or Supabase.
• You need dashboards, charts or governed metrics for analysts.
• You must self-host everything.
The choice depends on your requirements around privacy, latency, cost, control and operational ownership.
Designing reliable database automations
A few practical rules make a significant difference.
Start with a read-only role
Grant SELECT on the columns you want to share, and nothing else. It is the real barrier, and everything else builds on it.
Keep routes focused
Do not include every table if the workflow only needs three.
A smaller route is easier to understand, easier to test and easier to debug.
Separate retrieval from decisions
First get the facts.
Then apply business logic.
This makes it easier to understand whether a failure came from the data or from the rule itself.
Treat missing values explicitly
A missing value should remain missing.
Use null checks or a manual-review branch instead of silently guessing.
Keep the trace
Store the log_id next to important decisions.
This is particularly important for compliance, finance, contracts and healthcare workflows.
Add deterministic checks
Use normal code for things that normal code handles well:
• Date comparisons
• Arithmetic
• Thresholds
• Required fields
• Enum validation
• Duplicate detection
The agent can retrieve the data. It does not need to perform every deterministic operation.
Test with hostile questions
Use the Sandbox with real questions, and with questions that try to read what they shouldn't or to change the rules.
Add a human review path
Not every request should be processed automatically.
Empty answers, conflicting values and ambiguous questions should be routed for review.
A reliable workflow is not one that never asks a human for help.
It is one that knows when it should.
The bigger idea
The future of AI automation is probably not one giant agent that has every tool, sees every table and makes every decision.
A more practical pattern is composable specialization:
Input agent
↓
Data retrieval agent
↓
Validation layer
↓
Reasoning agent
↓
Business system
↓
Human approval when necessary
Each component has a clear responsibility.
The data layer describes your database, limits what can be read and returns typed answers.
The reasoning layer interprets those answers.
The workflow layer applies rules and triggers actions.
The human remains in control of high-impact decisions.
That architecture is easier to debug than a single autonomous loop because you can inspect each boundary.
When a workflow fails, you can ask:
• Was the question understood?
• Was the right route chosen?
• Was a field missing?
• Did validation reject the result?
• Did the business rule calculate incorrectly?
• Did the agent misunderstand an already-typed value?
That is much more useful than simply knowing that "the agent produced the wrong answer."
Final thoughts
AI models are becoming increasingly capable at reasoning over complex information.
But capability is not the same as reliability.
If your workflow depends on orders, customers, reservations, records or any other data that lives in a database, the quality of your data access will often matter more than the complexity of your agent framework.
Claix is built around a straightforward idea:
Data should stay in your database, and agents should reach only what you allow, through typed answers you can trace.
Once that happens, agents have less irrelevant information to process, workflows can rely on stable values, and developers can use AI for the parts that genuinely require reasoning.
Instead of asking an agent to do everything, give it a controlled way to read your data and a well-defined job.
That is where agent automation starts becoming useful in production.
You can try it without connecting your own database in the Sandbox, or read the docs at claix.dev.
Before you publish (not part of the post)
Item
What to check
Request body
The examples send a list called questions, with a question and a format for each. Your response echoes user_ask, so confirm the real field names
Endpoint
The examples call https://claix.dev/agent/{name} with the x-api-key header. Confirm it
Response
The examples use the exact format you shared: a list with user_ask, ia_response and log_id
Types
The examples use string, boolean and integer, which your reader prompt supports. The post says answers can be a boolean, a number, a text, a date, a list or an object. Your reader prompt has no decimal type yet, which is why the purchase order total is an integer
Response modes
The names Data and Answer are mine. Check what your interface calls them
Traces
The post says Traces show the route used, the query that ran and the result. Confirm it
MCP and A2A
The post says every agent is reachable over REST, MCP and A2A. Confirm that is true for each agent
Validation
The post doesn't claim queries are validated before they run. Add it only if it is implemented
Supabase link
The sentence about prompt injection and development use comes from Supabase's MCP documentation: https://supabase.com/docs/guides/getting-started/mcp
Claix Ingest
Step 1 of the invoice example mentions it as one option for extracting the invoice
Canonical URL
If you also publish the post on your own blog, add canonical_url to the front matter to avoid duplicate content