Tukun Agent Is Live

Today, Tukun Agent is officially live.

Tukun Agent is not traditional ChatBI, and it is not a demo product that simply connects a large model to a database. We care more about putting semantic, ontology, and evidence back on the same analysis path so the product can work as a durable data agent.

The problem it is meant to solve is also concrete.

Many AI analytics products look good in the first demo, then run into the same recurring problems once they meet real work:

• metric definitions are inconsistent, so the same word does not mean the same thing to the system and to the team
• answers sound plausible, but the evidence path is unclear
• conclusions are readable, but the process is hard to inspect and harder to reuse
• useful analysis gets trapped inside a chat thread instead of turning into cards, dashboards, and shared assets

Tukun Agent is designed around those problems.

What Tukun Agent is

Tukun Agent is a governed analytics product, and more specifically the kind of data agent we think real business work actually needs.

Its core question is not “can it answer?” but “can it answer with clear business meaning, explicit evidence boundaries, and reusable outputs?” That is what separates it from generic chat products, and it is also why we do not think it is the same thing as the common ChatBI pattern.

In the current product, Tukun Agent is organized into five major surfaces:

• Workbench: the single execution workspace for conversations, queries, analysis, progress, artifacts, and critique
• Semantics: the semantic asset workspace for models, metrics, dimensions, entities, relationships, and review / publish flow
• Dashboards: the downstream surface for preserving result cards as readable and shareable assets
• Skills: the runtime extension surface for installed and available capabilities
• Console: the place for shared configuration and health, not day-to-day analysis work

There is one product rule we are very explicit about: Workbench is the only execution entrypoint.

We do not want queries to run in one place, analysis to run in another, and saved assets to carry a third logic path. That quickly turns into multiple systems that look similar while disagreeing on the truth. Tukun Agent keeps runtime execution on one path, then builds cards, dashboards, and other downstream assets on top of that path.

Why start with semantics

Without shared meaning, an agent can generate something that looks like an answer while still failing to produce something that is actually valid in business terms.

That is why semantic structure is not a side configuration in Tukun Agent. It is a first-class product asset. And ontology is not just a word for research discussions. It is the practical way business objects, relationships, and meanings stay organized inside the product.

In the current version:

• semantic definitions live in PostgreSQL metadata storage as the product source of truth
• published manifest files are execution artifacts, not the definition itself
• every Workbench run is scoped to one explicit data source
• semantic definitions and publish state are isolated by data source

This means the agent must first align what a metric, dimension, or entity relationship actually means in the business world. It has to resolve the semantic and ontology layer before jumping straight to SQL and hoping for the best.

That is not flashy. It is still the part that determines analysis quality. What matters most is not whether the model can write a neat summary. What matters is whether the data agent is standing on the right business meaning in the first place.

Why evidence boundaries matter

The second core principle behind Tukun Agent is evidence-first analysis.

For many products, the easiest optimization is to make the answer sound smoother. For us, the more important requirement is to acknowledge limits when the evidence is not strong enough.

In the current product, every request should land clearly in one of four outcomes:

1. answer directly
2. return a governed query result
3. return an evidence-based analysis
4. say what is still missing

That sounds simple, but it drives concrete behavior:

• if the user asked for a time grain, the evidence has to include that time grain
• if the user asked for a business-dimension breakdown, the evidence has to include that breakdown
• if the result is truncated, missing shape, or incomplete, the system cannot pretend the analysis is finished
• if the evidence is only high-level, it cannot be packaged as a strong conclusion

In other words, Tukun Agent is not built to always say something. It is built to say the right thing when the evidence is there, and to stop clearly when it is not.

Not just answering questions, but preserving results

Analysis loses value quickly if it stays trapped inside a single conversation.

That is why Tukun Agent treats result preservation as part of the main path, not as an afterthought. In the current product, outputs created in Workbench can be turned into cards and then saved into Dashboards as downstream reusable assets. They stay linked to their source turns, keep their data source scope and evidence context, and remain readable without requiring a rerun.

That matters because teams should not have to choose between flexible analysis and stable reuse.

You should be able to do real query and analysis work in Workbench first, then preserve the parts that deserve to live longer for reporting, review, follow-up discussion, and future decisions.

What is included in the launch

As of today, Tukun Agent is live in production with the following capabilities:

• account-scoped product access and isolation
• email sign-in, Google and GitHub OAuth, and passkey sign-in
• governed query and analysis flows for a selected single data source
• one Workbench experience for queries, analysis, evidence, artifacts, and diagnostics
• semantic definition discovery, editing, review, and publish flow
• downstream result preservation into cards and dashboards
• runtime skill catalog and visible capability management

Taken together, those pieces already support a full data agent workflow: start from a question, align the meaning, execute the query and analysis, and preserve the result as a reusable asset.

What this launch means

For us, Tukun Agent going live is not the moment when “enough features” have been piled up. It is the moment when the product boundary is finally clear.

It is no longer just an internal prototype or an experiment around one narrow problem. Tukun Agent now has a defined execution workspace, a real semantic asset layer, explicit evidence boundaries, and a downstream place where useful results can continue to live.

That is what makes it a product we can keep evolving, instead of a loose collection of impressive demos.

What comes next

We will keep pushing in the same direction:

• strengthen consistency between the semantic layer and the analysis layer
• improve runtime inspectability instead of hiding the process
• make more outputs reusable instead of disposable
• extend support for multi-space and team workflows without breaking the simplicity of the current path

If what you care about is not whether a model can answer one more question, but whether a data agent can become a reliable analysis interface in real business work, and whether there is a better path than traditional ChatBI for keeping semantic, ontology, and evidence together, then Tukun Agent is our answer.

Tukun Agent is live.