AgentQ Examples

Chasing down an anomaly alert

Context. A notification says anomalies turned up in the transactions table overnight. You want to know what broke and whether it matters before you open the scan results yourself.

What you ask.

You: We got an alert about anomalies in the transactions table. What's going on?

AgentQ: I found 3 anomalies from the last scan. The most significant is a Not Null check failure on the merchant_id field. 247 records have null values where this field is expected to be populated. This started appearing after the batch that loaded at 2:00 AM. The affected records all have source_system = 'legacy_import'. Would you like me to show you the specific check that's failing or help investigate the source of these null values?

What AgentQ did. It looked up the container, read the anomalies from the most recent scan, ranked them, then read the failing check and the records behind it to find what the bad rows have in common.

Why it works. The question named the table and nothing else, and that was enough. AgentQ found the pattern in the records, which is the part that turns a count of failures into a lead worth chasing.

Deciding whether a table can be trusted

Context. You are about to publish a revenue report from daily_orders and want a second opinion on the data before the numbers reach anyone else.

What you ask.

You: Can I trust the daily_orders table for this month's revenue report?

AgentQ: Verdict: Moderate. The table is usable for the report if you treat the last three days as incomplete.

Score: 74, in the moderate band. Timeliness (58) and Volumetrics (69) pull the total down, while Completeness, Conformity, and Consistency are all above 90. Timeliness carries the highest weight in this container's score settings, so it accounts for most of the shortfall.

Drivers: The source system last wrote to the table three days ago, although the description says it is loaded daily. Two anomalies are active: a Volumetric check on the daily row count failed on the last scan, and an Expected Values check on order_status is failing.

Caveats: The upstream orders_staging table has an open anomaly on order_total, which feeds this table's revenue field. Qualytics scanned daily_orders yesterday, so the anomaly picture is current.

Unassessed: The table has more fields than the assessment could list, so the field inventory is partial. No freshness reading exists for the upstream table.

Want me to open the failed Volumetric check, or look into why the load stopped?

Answer basis: Model-synthesized answer

Method: Synthesized by the model from AgentQ guidance tools and any supporting tool results.

Limitations: Guidance tools supply evidence and a rubric for the model, not an authoritative answer.

What AgentQ did. It pulled the quality score and its dimension breakdown, read the container's score settings to see which dimension carries the most weight, listed the active anomalies, and followed the lineage one step upstream.

Why it works. The verdict comes first and the evidence follows, so the answer is usable in a sentence and auditable in a paragraph. The Unassessed section is the part worth reading twice: it names what AgentQ could not check, which is what keeps a confident-sounding answer honest.

Getting quality checks onto a new datastore

Context. A PostgreSQL database has just been connected and nobody knows it well enough to write checks by hand.

What you ask.

You: We just connected a new PostgreSQL database called "ecommerce_prod". Can you help me understand what's in there and set up some basic quality checks?

AgentQ: I found 12 tables in the ecommerce_prod datastore. The main ones appear to be customers, orders, order_items, products, and inventory. Would you like me to describe the schema for any of these in detail?

You: Yes, tell me about the orders table and suggest some quality checks.

AgentQ: The orders table has 15 fields including order_id, customer_id, order_date, ship_date, status, and total_amount. Based on the schema, I'd recommend these quality checks:

• order_id should be unique
• customer_id should not be null
• total_amount should be positive
• ship_date should be after order_date when both are present
• status should be one of your valid status values

Want me to create these checks?

You: Yes, and also look at order_items. I think the same line shouldn't appear twice per order.

AgentQ: For order_items, the natural identifier is a pair like (order_id, line_item_id) rather than either column on its own. order_id repeats across line items in the same order, and line_item_id resets per order. I'll add a Unique check on both fields together so the combination is enforced as a composite key. Want me to apply it now?

What AgentQ did. It listed the containers, read the schema of the one you named, proposed checks from the field types and names, and then read the data well enough to correct your assumption about what makes a row unique.

Why it works. AgentQ asks before it writes. Each round narrows the scope, and the composite-key correction is the kind of thing that only shows up once something has actually looked at the values.

Joining customers and transactions across two datastores

Context. Customer records live in Snowflake and transactions live in an operational PostgreSQL database, and you need lifetime value across both.

What you ask.

You: I need to analyze customer lifetime value but our customer data is in Salesforce (synced to Snowflake) and our transaction data is in our PostgreSQL operational database. Can you help?

AgentQ: I can create a computed join that combines data from both sources. I'll join the customer table from your Snowflake datastore with the transactions table from PostgreSQL on customer_id. What fields do you need in the result? At minimum I'd suggest customer details, total transaction count, total spend, and first and last transaction dates.

You: That sounds right. Also filter out any test customers.

AgentQ: I've created a computed join called "customer_lifetime_value" that combines the data and excludes records where the customer email contains "test" or the customer_type is "internal". The join is now available as a container in Qualytics. Would you like me to set up quality checks on this new dataset or run a profile to understand the data distribution?

What AgentQ did. It found the matching field across the two datastores, proposed the output columns, then created the computed join with the filter you asked for and offered the obvious next step.

Why it works. The work ends in a real container, not a suggestion you have to build yourself. Because AgentQ created it, the change is recorded in the audit against your name.

Finding the gaps in your monitoring coverage

Context. You inherited a workspace and want to know which datastores nobody is actually watching.

What you ask.

You: Which datastores don't have an active recurring schedule?

AgentQ: 4 of your 17 datastores have no active recurring schedule: legacy_billing, marketing_exports, vendor_feed_eu, and sandbox_analytics. Two of them carry active quality checks, so those checks are only asserted when someone runs a scan by hand: legacy_billing has 23 checks and was last scanned 41 days ago, and vendor_feed_eu has 8 checks and has never been scanned. Want me to look at what those checks cover?

What AgentQ did. It counted the datastores, matched them against the recurring schedules, then enriched the gap list with the check counts and last-scan dates that say which gaps matter.

Why it works. Counting questions like this go through the structured query interface rather than free text, so the numbers come from the same place the web app reads them. See Semantic Reporting.

Asking where the quality problems are concentrated

Context. A weekly review needs one slide on where the team should spend its time.

What you ask.

You: Across the warehouse datastore, which containers have the most active anomalies right now?

AgentQ: Three containers hold most of them. orders_fact has 31 active anomalies, customer_dim has 18, and shipments_fact has 12. The remaining 24 containers hold 9 between them. In orders_fact, 22 of the 31 come from a single Expected Values check on order_status, so one upstream fix would clear most of that column.

What AgentQ did. It grouped the active anomalies by container, ordered them, then looked inside the largest group to see whether the count came from many problems or one.

Why it works. The follow-through is what makes the answer useful. A ranked list tells you where the anomalies are, and the breakdown inside the top container tells you whether the number is 31 problems or one problem counted 22 times.