Gwenlake Atlas is live

Most AI projects do not fail at the model. They fail in the gap between the data and the model. That is the part where a connector breaks, where nobody can say where a number came from, and where the vocabulary of the business does not survive the trip into a column name.

Gwenlake Atlas is the platform we built to close that gap on our own projects. It connects to your business systems, prepares your data with your ontology and full lineage, runs your models and agents, and writes the results back into the tools your teams already use, inside an environment you control. It is now available as a product. Here is what it does, end to end.

Five steps that have to hold together

A break in any one of them shows up as a wrong answer at the end, so Atlas covers all five rather than the two in the middle.

Connect and read. Around twenty connector types: CRM, document stores, mailboxes, databases, object storage, git, and any REST API. Credentials are held in a dedicated secret store rather than in a notebook, and a connection is set up once and reused by every sync that needs it.

Transform. OCR, chunking, embedding, vectorisation and joins across sources, with provenance carried on every row down to the source file and page. If an answer cites something, you can open what it cited.

Ontology. Concepts and relations derived from your data, so models and agents read your vocabulary rather than column names. This is the step most pipelines skip, and the one that decides whether a retrieval system answers questions in the language the business actually asks them in.

Models and agents. The prepared material goes to the models we build for you, or to Gwenflow agentic pipelines. Schedule them, and watch every run.

Connect and write. Outputs pushed back into Salesforce, Dynamics 365, Power BI, Tableau or your own applications, through the same connections Atlas read from, or through your APIs. A result that stays in the platform is a result nobody uses.

Every kind of data, prepared the same way

Atlas recognises what it is given and processes it accordingly. Tables are typed and joined. Time series are aligned. Documents are read, with OCR where needed, and chunked. Audio and video are transcribed. Everything lands in the same datasets, with the same lineage, so a question can be answered across a contract, a spreadsheet and a recorded meeting without three separate pipelines.

Every row knows where it came from

Atlas records the provenance of every row: the file, the page, and each transformation it went through on the way to the clean dataset. Pick a row and you can walk it back to its source. Lineage says where the data came from, the ontology says what it means, and a system that has both can be checked, corrected and trusted. Without lineage, a wrong figure is an argument; with it, it is a fix.

From column names to business concepts

An ontology is the part a model needs in order to know that an emissions figure belongs to a factory, which belongs to a company, and was verified by an auditor. Atlas derives one from your data and lets you refine it: the concepts that exist, how they relate, and what each of them means. Definitions, units and synonyms are written once, so CO₂e, Scope 1 or net zero mean the same thing to every agent and every team.

This changes what an agent can do. Asked which suppliers missed their 2025 emissions target, an agent without an ontology scans a couple of hundred tables, guesses which column holds emissions, assumes a unit, finds no target and invents one. The answer sounds fine and cannot be checked. With the ontology, the same agent follows the relations it has been given, from the supplier to its sites, from the sites to their metric in tonnes of CO₂e, from the metric to its 2025 target, and the answer traces back to the rows it came from.

Four things follow from that:

• Fewer hallucinations. The agent can only name concepts and relations that exist, and every figure it cites traces back to a row and its source.
• Concepts it understands. Your vocabulary is defined once and shared.
• Actions it is allowed. Each object declares what can be done with it and by whom: read, propose, or execute after approval. The agent cannot act outside those rules.
• Checks before answers. An auditor agent validates each plan against the ontology's constraints, and sends it back when it does not hold.

One workspace, twelve modules

Everything above lives in one place rather than in a chain of tools. The Atlas home screen opens on its modules: search across everything that has been ingested, datasets, a SQL console, syncs, connections, ontologies, apps, agents, code, models, schedules and telemetry. A data engineer, a data scientist and a business user work in the same workspace, on the same data, with the same lineage behind it.

Run it where your data lives

The same platform, three ways to run it. Pick the one your security team is comfortable with; moving between them later is a deployment change, not a migration.

What it costs, as it happens

Atlas records what each run did and what it cost, run by run rather than as a monthly total: sessions per user and project, one trace per run with its spans, latency, prompt and completion tokens, the estimated cost per model, the error rate, and the energy each LLM call draws with its CO₂e per session, measured as it happens instead of estimated at the end of the year. Usage breaks down by user, by project and by application, and every agent run is traced through OpenTelemetry to any OTLP backend, with the lineage of the data it touched sitting alongside the trace.

None of that is a dashboard we added at the end. It is the part that makes the platform defensible in a review, which is why it was in the design from the start.

Read more about Atlas, or talk to us about what it would take to run it on your data.