Product
One product, two ways to use it. Both pass the same controls.
AgenticObjects is a team of analysts that runs on top of your data warehouse: you question it in plain language, and it keeps scanning your data when you don’t.
Fifteen seconds
The whole loop, before the detail
A question answered with an address under every figure, then a scheduled run publishing a brief and its findings — the two paths this page then takes apart one at a time.
Where the difference is
Every serious analytics agent now builds the query from a semantic layer. That is where we start, not where we stop.
| Standard in the category, and in AgenticObjects | What AgenticObjects adds on top |
|---|---|
| One governed definition per metric, from a versioned semantic model | The sentence is checked, not only the query. Every figure the model writes is resolved against the sealed query result before delivery. A number without an address never reaches the screen. |
| Deterministic query construction; the model never writes SQL | Refusals are on the record. Held candidates, withheld values and rejected drafts sit in a ledger with their reason. Ask any vendor to show you theirs. |
| Row-level security, role-based access, your choice of approved model | One model per run, and it cannot be swapped part-way. The model is chosen before the run starts and written onto the run. Nothing switches to a different one because the provider is slow or because a first answer looked weak. Six months later the record still says which model wrote it, so if a model is ever withdrawn you can find every record it touched. |
| Natural-language questions with an evidence trail | It works when nobody asks. Scheduled discovery produces findings, recommendations and briefs as persistent records, not messages. |
Most analytics AI in this category is tied to the vendor’s cloud. AgenticObjects installs next to your warehouse: on-premise runtime, read-only gateways, credentials that never leave your server. For banking, healthcare and public-sector organisations where data cannot leave, this is not a feature. It is the condition for being in the room at all.
The “no number without evidence” rule applies to a finding produced at 05:00 exactly as it applies to an answer typed at 15:00.
The morning brief
Monday, 08:00. This is what is on the screen.
Assumptions strip
Cannot be switched off; read before the numbers. “You did not state a period; last full month was assumed.”
Narrative
Written by the model; every number in it tied to an address.
Findings
Severity, direction, and an interpretive badge that separates opinion from measurement.
Link to the run
At the foot of every brief, leading back to the run, its frozen settings and its cost.
The point is not that the agent summarised the week. It is that nobody had asked about the stock-to-sales gap, and the agent found it on its own.
The dashboard
One glance every morning. Five regions, and each one says what it is.
| Region | What it holds | The rule behind it |
|---|---|---|
| Daily | The latest briefs | First opening is stamped once; “unread” means never opened |
| To-dos | The agents’ recommendations | Every row opens the finding it rests on, in one click |
| Findings without a recommendation | “Important, but not yet turned into action” | Shown, not hidden |
| Data status | Periods where the agent looked and found no records | Never inflated into a finding; no severity badge, because an empty period has no business impact |
| Notifications | One per run | The same topic a third time gets an ongoing stamp, not a third alert |
Continuous analysis is not continuous interruption. The system manages your attention the way it manages its budget.
Three record types, in detail
Each type has a birth rule. If the rule is not met, the record does not exist.
FINDING — “What happened?”
How a metric behaved in a given breakdown over a given period. Every finding carries a severity: low, medium, high or critical. Which metric, which period, which filters — the engine writes these, not the model. If the query ran and returned no data, that is not a finding but a data state: its own class, no badge, and no recommendation can be built on it.
RECOMMENDATION — “What should we do?”
A business action grounded in at least one finding. An ungrounded recommendation cannot be produced; one resting only on “no data” is rejected as well. It inherits the most restrictive usage policy of the findings beneath it, so it can never be more widely shareable than its own evidence.
BRIEF — “What mattered this week?”
The readable cover note that gathers a run’s findings into one text. At least one covers link is mandatory. You choose per agent what gets produced: findings only, an executive summary, or both.
Three link types connect them — based_on, covers, related_to — so knowledge becomes a small navigable graph rather than a flat list. The chain can be walked in both directions.
The eight gates
Every record on your dashboard has passed eight checks. None of them involves AI.
The agent’s raw output never reaches the dashboard directly. It is parsed into candidates, then passed through eight rule-based checks in a fixed order.
| Gate | What it checks |
|---|---|
| 0 · Structure and links | A candidate missing a title, a type or its grounding is dropped. Self-links and cycles are forbidden. |
| 1 · Authority freeze | Sealed with the permission and row-level scope it was produced under. |
| 2 · Evidence | Every number is tested against the query results the agent cited. An unproven number cannot enter the body. |
| 3 · Trust stamp | The record’s trust tier is the tier of its weakest evidence. The engine writes it. |
| 4 · Claim check | Unevidenced causality and superlatives are structural defects: one rewrite, then held. Interpretive language is badged, not blocked. |
| 5 · Novelty | Has this agent said this before? Stamped new / ongoing / repeat against its own history. |
| 6 · Deduplication | A second record with the same identity is not deleted; it stays as a duplicate and is counted. |
| 7 · Cardinality and contract | Per agent per run: at most 6 findings, 3 recommendations, 1 brief. A type you did not select is never published. |
Every dropped, held, duplicate or overflowed candidate sits in the Guard Ledger with its reason. If every candidate is dropped, the system says “all candidates dropped”, not “no new findings”.
What your team does with a record
Reads it. Votes on it. Drills into it. Follows it.
Reads it
On the dashboard, the timeline, the archive. Who opened it and when is recorded. Seen / discussed / dismissed is personal and never changes anyone else’s feed.
Votes on it
Useful or not, with an optional reason. Votes flow back into the agent’s next run as a signal — never as raw text, so one person’s comment cannot poison the system.
Drills into it
One click carries a finding into a conversation with its numbers attached: “break this down by city” — without starting a new run.
Follows it
Everyone following an agent is notified on a new publication. Notification text never contains a value; the value lives in the record.
Setting an agent up
You are hiring an analyst, not writing code.
Explain the job. Set the limits. Agree the working hours. That is what a manager does on a new analyst’s first day, and it is exactly what the agent studio asks for.
- You explain the job A job description in plain language. Audience, priorities, what to look at first, what never to claim. Honesty is not a software feature; it is a line you write into the job description: “Never claim causation.”
- You set the spending limit A company card with a ceiling: steps, seconds, cost. An agent can only narrow its limits, never widen them.
- You show them the field Where each dataset ends, which metric is empty, what it should never look at. The agent speaks knowing its own limits.
- You set the working hours Every Monday at 08:00, Istanbul time. Every brief is born from that one line.
Two differences from a human analyst: the instruction is word-for-word identical every run — no moods — and every settings change lands in the audit log with who and when.
The anatomy of a record
What every agentic object carries, and who is allowed to write it
Four groups of properties. Two of them the agent contributes to; two of them only the engine may write. That split is the whole governance model in one table.
Identity — who it is
Its own identifier and its own address in your installation. A type, and the version of the schema it was written against. A revision counter: change the content and the evidence check runs again. A record that supersedes an earlier one keeps the pointer back to it.
Origin — where it came from, frozen
The run that produced it, the agent, the exact model binding in force at the time, and a hash of the configuration that was live. Also the identity it was produced under and that identity’s row-level scope — frozen at creation, and re-checked live on every read.
Evidence — what it rests on
The query results it declared, and the proven figures frozen onto the record so the evidence survives even if the run log is cleaned. Plus the freshness of the data and the exact periods read. Any figure that could not be proven sits in a held-values list with a named reason — it never reaches the body.
Judgement — what the engine concluded
Trust tier, taken from the weakest piece of evidence beneath it. Whether it has been validated. Whether this agent has said this before. Whether the wording strays into causal or superlative language — which is labelled, never blocked. And whether it counts as an experiment, which it does by default until something proves otherwise.
Type — the fifth property
A number travels with its identity, its address, the authority it was made under and its lifecycle. The fifth thing it needs is type: what kind of claim is this, and what does it oblige?
There are three, and adding a fourth is deliberately hard. The test is not whether it would look different on screen or arrive from somewhere new — a different card or a different origin is a context, never a type. The test is whether it has a genuinely different lifecycle and a genuinely different obligation.
Links, and the direction they run
A recommendation rests on a finding. A brief covers findings. A finding may relate to another finding. The engine enforces which way each link may point and refuses to create a cycle, so a chain of reasoning cannot quietly close on itself.
The states a candidate can end in
Nothing silently disappears, and cardinality overflow is never dressed up as a gate failure.
| State | What it means |
|---|---|
published | Passed all eight gates. It is on the dashboard and in the feed of everyone entitled to see it. |
validated | Provable and correct, but not selected for publication on this run. |
held | A gate stopped it, and the reason is recorded with it. |
duplicate | The same record found again. Not deleted — kept and counted. |
not_selected | Correct, but over the run’s cap for its type. Its own state, deliberately distinct from a failure. |
Archival is a timestamp, not a state — a record can be archived from any of the states above. There is no delete endpoint anywhere in the product for these records. An answer given in August is still inspectable two years later.
Seen, discussed, dismissed — personal state lives separately from the record. One person dismissing something never drops it from anyone else’s feed. First opening is stamped once and never rewritten, which is why “unread” means never opened.
See it on your own data in four weeks.
Acceptance criteria written down first.