The Blackfell Group
Agents that work inside
the boundary, not beside it.
The usual way to put AI on your data is to send the data to the AI. We do it the other way round: the agents run in the account that already holds the data, against a model endpoint you own, and they propose work rather than quietly doing it. What comes back is a written change you can read, argue with, and reject.
An engineer's attention, applied on a schedule.
Data platforms fail quietly. A job stops running, a table stops refreshing, a column changes shape upstream, and nobody notices until a number is wrong in a meeting. The agent's job is to notice, and to arrive with a specific proposal instead of an alert.
It reads the platform, not your records
The agent works from what the platform already keeps about itself - job history and failures, table freshness, schema changes, the query audit log, the catalog. That is the material it reasons over.
It is pointed at the operational surface of the system, not turned loose on the contents of your tables.
A ladder you set, one rung at a time
How far the agent may go is a deliberate setting: silent, email a summary, write a proposal with its reasoning, or open a pull request against your repository. Nothing merges itself.
Every deployment starts at the bottom of that ladder. Moving up is an administrator's decision, made once you have read a few weeks of its work and know what it is like.
Reasoning and execution are separate
The part that thinks and the part that can change anything are different processes with different credentials. The agent runs under its own isolated, least-privilege role - it cannot quietly acquire reach it was not granted.
What it sends outward is scrubbed of record-level content, so an operational email stays operational.
Documentation that keeps up with the data.
Every organization intends to maintain a data dictionary. Almost none do, because it is written by hand, once, and is wrong within a quarter. So we made it a product of loading the data rather than a task that competes with it.
Tables arrive described
When a new table lands it is catalogued and enriched automatically: what it appears to hold, what its columns mean, how it relates to what is already there. Suggestions are reviewed by a human before they become the published definition.
The result is a dictionary that exists on day one instead of the quarter after someone is assigned to write it.
Identifiers found before they are queried
Columns that look like personal identifiers are flagged as tables are catalogued, and masked unless a role is explicitly entitled to them. Masking is enforced in the query engine, so it holds however the data is reached - notebook, BI tool, or raw SQL.
Classification is a review queue, not an automatic verdict: the agent proposes, a person confirms, and only then do the access rules regenerate.
Lineage captured as jobs run
Transformation jobs emit their inputs and outputs while they execute, so the dependency graph is a record of what happened rather than a diagram someone drew last year.
It answers the question that actually gets asked: if this column changes, what breaks downstream, and who is going to call?
Inference inside your cloud boundary.
Your account, your endpoint
Model calls go through a gateway deployed in your own account, against your cloud provider's hosted models. Prompts and the data inside them stay within the boundary your security team already reviewed.
There is no Blackfell service in the request path. Nothing to trust us about, because nothing passes through us.
The agent is audited like anyone else
Every query is recorded - who ran it, against which columns, and when. Queries the agent issues appear in the same log, under its own identity.
An agent whose work you cannot reconstruct afterwards is not one you should let near regulated data.
Isolated networks are a first-class target
The same architecture is built to deploy where there is no internet to call out to: dependencies delivered ahead of time, no runtime reliance on anything outside the enclave.
That was designed in from the start rather than retrofitted once the commercial version shipped.
The claims we have deliberately not made.
The market for AI on data is loud, and most of the noise resolves to "trust the demo". Here is where we have drawn the line, so you can tell quickly whether we are a fit.
Not autonomy as a selling point
Acting without review is the easy part; it is also the part that goes wrong at three in the morning. Our agents are built to produce reviewable work, and the review is a feature, not a stage we are trying to remove.
Not a chatbot bolted to a warehouse
The value is not a text box over your tables. It is the unglamorous work underneath - cataloguing, classification, lineage, noticing breakage - done continuously instead of never.
Not your data as training material
The gateway calls a hosted model in your own account and the exchange ends there. Your data does not become anyone's training set, ours included.
Tell us what you are trying to build.
If it sounds like something we build, we will say so. If it does not, we will say that too.