Data agent on Slack or WhatsApp

Create consumption tables per purpose (daily sales by branch, funnel by month, revenue by customer), with the grain stated in one sentence in the description. When the rule is complex, the table already carries the result in a column (for example, a boolean that says whether the row counts toward the metric) and the document tells the agent to use that column instead of rewriting the formula. Scratch tables (prefixes debug_, test_, tmp_, suffixes _log, _dryrun, names with dates) are never a source of numbers.

Start the column description with a tag: @pk (grain key), @fk (foreign key), @measure additive (sums across any dimension), @measure non_additive (average ticket, percentage, rate), @grain. Then state the origin, the rule and the pitfall. Every monetary measure says whether it is gross or net. Document the table, not only the transformation: whoever looks for the data finds the table.

A root document lists every document with one line saying when to read it. The agent reads every document that matches the request; chained metrics are read together (NRR also reads MRR and churn). If no document covers the request, the agent says so instead of improvising. In semantic search, ask for the concept and the metric: a proper name surrounded by weak words makes the search return zero documents. The name is for filtering in SQL.

Fixed order: fetch context with the original question, read the documents, check the last load, generate and run the query, check the order of magnitude against a reference number in the document. The agent never answers a number without running the query and never refuses for lack of data before reading the table structure. Null is absence, not zero. Metrics flagged 'to be validated' are not inferred.

The answer names the metric (net or gross), the period with start and end dates and the date and time of the last load. The current day is partial: compare only closed days. An open month does not count as actuals; use the table's closed-month flag when there is one.

ERP date fields stored as midnight UTC are already the business day. The agent computes today and yesterday in local time and compares directly, without converting the field. The rule is written in the column description and in the protocol.

The agent breaks the change down (volume versus ticket, which branch explains the difference in reais), but does not explain why it fell or recommend action without data to back it. A comparison base of zero or very small becomes 'low base', with the change in reais. Rates change in percentage points. Percentages and averages are not summed across rows: recompute the ratio from the totals.

Each audience has its own MCP token with table scope: leadership reads the whole network, a manager reads the view of their own branch. A catalog folder is organization, not security. Data that identifies a person (operator, contact, student) stays out of broad views. An access error is the scope working: the agent says where the answer lives, without asking for new permissions.

Rules are stable; counts (active customers, number of tables, totals) are a snapshot of a date and age within days. If the document disagrees with the query, the query wins. Every document carries an owner, a status (validated or not) and the last review date. When the agent uses an unvalidated rule, it says so.

Keep a set of real questions with the expected answer and run it on every document change. Store the channel history pairing each question with the final answer. Intermediate messages ('analyzing your question') do not count as an answer or toward response time.