Ask your PostgreSQL database in plain words, no SQL

The agent connects to the database directly with parameters — host, port, database name, user, password and SSL mode — and starts with a look at the schema: the list of tables, their columns and types. From there it writes the SQL itself: it calculates revenue, average order value and conversion, matches rows against data from other connected services and shows which tables and columns every number came from. The same query can be put on a schedule and delivered regularly.

The PostgreSQL specific the agent accounts for: a role with pg_read_all_data does not bypass row-level security. A table under RLS with no SELECT policy returns zero rows — and that is not «no data» but «no access», which the agent states directly. It reads an empty result from an ordinary query the same way: it first checks whether any rows exist at all and only then calls the number a zero. The schema is re-read before an analysis, so a renamed column or a new table is picked up without reconnecting.

The agent never writes to the database: the connector passes through only SELECT, WITH, SHOW and EXPLAIN, one statement per call and with a row limit, and rejects INSERT, UPDATE and any DDL before they reach the database. That is how the connector itself is built, not a setting that can be lifted from chat, so the connection stays analytical by nature: the agent reads, calculates and explains what the result is made of, but changes nothing in the database.

Access comes not from a sign-in through a service but from the login and password of a separate role, so you set its boundaries: the agent sees exactly what that role sees, and nothing said in chat can widen them. Every query is bounded by the connector in time and in rows, and one that grows too heavy is cut off by timeout instead of hanging on a production database. If a table is missing or permissions do not allow reading it, the agent says so directly instead of showing an empty table.