Why we're building damn.dev

We started by building a workspace. Channels, conversations, a team, except some of the team are AI agents and they do actual work: they run commands, open pull requests, read from the warehouse, post to the calendar, talk to each other.

The agents were the easy part. Models got good, tools got good, and within weeks we had agents doing things that were genuinely useful.

Then one of them opened a pull request against a production repository, and I could not answer a question a colleague asked me in passing.

Three ordinary questions#

The question was "which one did that?" And underneath it, two more that turned out to be harder:

What did it do? Not what it said it did. Agents narrate. A model will tell you it ran a command with total confidence in a turn where it emitted no tool call at all. The only trustworthy answer comes from the layer that actually executed something.

Who approved it? For most of what an agent does, the honest answer is nobody, because nobody was asked. That is fine for reading a file and not fine for a force push, and the difference between those two is a decision somebody has to have made.

Can you prove it? Not "is it in a log." Logs are editable by whoever owns them, which for most tools is the vendor and for the rest is you. If the artifact is going to an auditor, "trust our database" is not an answer.

If any of those three comes back silent, the agent is running on trust. Which is fine for one agent you wrote yourself and stop being fine at about the fourth one, and stops being fine much earlier than that if the systems are somebody's medical records.

The part that made it a company#

You could solve this for the agents you build. We had, more or less, inside our own workspace.

What we could not solve was everything else, and everything else turned out to be most of it.

The engineers were already running Claude Code, Codex, Cursor and Copilot, chosen per squad, none of them ours. The SaaS tools were shipping their own agents into seats already paid for, enabled by default, without asking anyone. A contractor arrived with a personal account and a workflow nobody had approved because nobody had been asked to.

Each one came with its own trust model, its own log, and its own idea of what "approved" means. And the person accountable for all of it had visibility into none of it.

That is not a phase that consolidation fixes. The number of AI surfaces inside a company tracks how fragmented the organization is, not how mature it is, and the direction of travel is more of them every quarter. Nobody is going to standardize.

So the interesting problem stopped being "how do we govern our agents" and became how do you apply one trust model to an ecosystem the company does not control.

What we chose to build#

Every agent, whoever wrote it, wherever it runs, has one thing in common. To do anything that matters to your company, it needs a credential you issued, and it has to arrive at a system you run.

Those are the keys and the doors, and they were always yours.

Scope the key and you control what an agent can touch. Gate the door and you control what it can do. Record both and you can prove what happened. Nothing has to move, nothing has to be rebuilt, and a tool you have never heard of is governed the first time it presents a credential at a door you own.

One rulebook. One record. Every agent.

The version of this that asks you to rebuild your agents on our platform would be easier to build and easier to demo. It would also govern only the agents that moved, which are exactly the ones that were never the problem.

Why it runs on your infrastructure#

Not as a privacy promise. As a structural fact about what this job is.

You cannot gate a company's own systems from somebody else's cloud, and the record of what your AI did to your production database should not be an artifact you rent. So damn.dev installs on your server, your data stays inside your perimeter, and the audit chain is yours in a way that survives us.

The useful side effect for anyone evaluating it: nothing leaves the machine, so nobody has to approve a data flow before you are allowed to try it.

What we will not claim#

The category has a vocabulary problem that costs buyers real money. Detected, observed, gated and contained get used as if they were the same word, and they are four very different strengths. We publish exactly which one applies to each surface we ship, including the surfaces where the honest answer is weaker than we would like.

That is not modesty. A technical buyer finds out anyway, and the moment they find out is usually the incident. We would rather be the vendor who told you first.

Stated forward, it is one sentence: one rulebook, one record, every agent, and how hard we can stop something depends on how much of the path runs through you.

Where we are#

It runs. It is in production, we use it to run our own company, and we build it with a design partner in regulated medical imaging who has the version of this problem where the answer has to hold up to an auditor.

If your engineers are already running four coding agents and your SaaS vendors are shipping more, the first useful step is not a platform decision. It is a number: how many AI surfaces are actually running against your systems right now.

That one is usually available inside a day, and it is almost always higher than anybody guesses. Come and find out.