I built Datris with a single agent that reviewed its own code. The reviews always said “looks good.”
So I split it into five roles under a lead that can’t write code, and only I can tag a release. Here’s the org chart, plus what’s still bad:
https://t.co/SaTD0PsLrR
I keep getting asked what a data control plane for AI agents is.
It's the layer between your agents and your stores that holds the rules, since the agent won't remember them and is just as confident at 3am on a Sunday.
Wrote it up: https://t.co/y4Rt6IzTuE
Here's the issue with AI agents and data management.
When every agent builds its own integrations, you get separate credentials, inconsistent quality checks, and results that can be difficult to trace.
The solution, a data control plane gives agents a shared, governed path to your data—with clear permissions, consistent validation, and evidence of what actually ran.
Your warehouse stays in place. Your agents gain a consistent way to work with it.
I put together this three-minute video to explain why this matters as agents move from demos into production.
https://t.co/nV4HmmggS3
#AIAgents #DataEngineering #DataControlPlane
Our platform runs code a model wrote.
That's the product, so the sandbox can't be a switch you flip.
It's the default now: no credentials in the box, no road out.
New post on secure-by-default for agent infrastructure: https://t.co/89aP6f8AEO
Your company probably already approved frontier AI, years ago, when it signed its cloud agreement.
Claude via AWS. GPT via Azure. Same trust boundary, same IAM, same bill. No new vendor review.
The approved path and the good path are the same path now.
https://t.co/lz12vQ3nts
Somewhere in your shop a pipeline will re-download the entire source tonight, like it did last night, so it can throw most of it away.
Full reload never fails loudly — it just gets more expensive every day.
New post on why the fix is where the sync state lives: https://t.co/7WKuucx4iV
Kimi K3 Failed My Agent Test. Badly.
Softball: 10-city forecast into MongoDB, nightly.
It finished. It also rebuilt the pipeline 3x, deleted it once, and blamed a different part of my platform for every failure.
Benchmarks say pass. The session says no.
https://t.co/zp8TJMInCQ
Your AI agent writes production code. Where does that code live?
If the answer is a database column called script_body, nobody can diff it, blame it, or prove what ran. We stopped accepting that for human code around 1995.
Put it in git. Pin what runs.
https://t.co/QDxT7oZbNx
"Data gravity" isn't physics. Warehouse vendors build it.
An ingestion tool that only loads into their platform isn't a pipeline — it's an intake valve owned by the destination.
Keep your ingestion layer neutral.
Load the lake. Don't live in it.
https://t.co/5VsCtYhUQ2
One MCP server per database is becoming the default for agent query access. Postgres, Snowflake, Mongo, each with its own server.
Feels responsible. Nobody handed the agent a password.
But entitlements get defined once per store, and nothing above them holds a single view of what the agent is allowed to know. Cross-store questions make the agent the join engine, and the data leaves governance the moment it lands in the context.
Agents don't need a new data platform. They need a governed way into yours.
https://t.co/Nx7CMOkzhH
An agent can clone your vendor's headline feature over a weekend, for the price of some tokens.
So what were you actually paying for? Trust, operation, ownership. The code was never the moat.
https://t.co/QCqpGgZr4D
Most agents are wired to three data tools: SQL, documents, RAG.
Ask one question that spans all three and the agent answers from whichever it hit first. A third of the picture, full confidence.
One server fixes it:
https://t.co/FaNmB4Rk5w
An agent needs data it doesn't have, so it writes the code to go get it.
Nobody picked it off a shelf. Nobody read it. It ran against a live source the hour it was born.
Run that code in-process and it can reach everything: your DB password, your secrets, the whole platform.
Where it runs is the whole game.
https://t.co/j1G5as1Hi7
1/
Databricks just rebuilt its summit around the layer between your connectors and your agents.
MCP governance. Access control on what agents touch. Context routing. Managed memory.
That's the bet we made when we started Datris. The argument about whether this layer matters is over.
2/
Their gateway reaches out. Their gravity pulls in.
Context from their catalog. Memory in their database. Agent traces governed next to the data you already moved.
Govern it all in one place. The fine print: govern it all in their place.
3/
Datris governs what you already have. Your warehouses. Your connectors. Your agents.
No migration. No single vendor owning both the data and the agents reading it.
The category is settled. The open question is who holds the keys.
Open source. Neutral by design. https://t.co/c2NQ5JqqVY
A credential your agent can read is a credential you've lost.
It pastes the key into a config file, the job goes green, and now it's sitting in plaintext nobody rotates.
Agents work the lock. Vaults hold the key.
https://t.co/CDR9BayY1C
Ask a coding agent to store data and it writes straight to a database.
That's the demo path. It also quietly becomes your production path, and now you've got an agent welded to one store that double-writes on every rerun.
Why that instinct bites: https://t.co/vGCHZ8x1Wn
A retry policy is a bet that nothing changed.
Most of the time it wins. But when a column moves or an API changes shape, running the same task again just fails faster.
A retry can re-run. It can't re-think. That's the agent's job.
https://t.co/7UWbMWjALE