Our internal AI workflows

Enterprise AI is usually sold as a new colleague: the autonomous employee that reads your codebase, files the tickets, ships the fix and updates the documentation while the founders sleep. It is a tidy story, and almost nobody runs their company on it. The agents that have earned a place in a working engineering team are far less cinematic. They take over a specific, repetitive chore, they do it quickly, and they hand the result back to a person who decides what happens next.

Last week Anthropic held an event at our Paris office, and our engineering team put three of these on the table. None of them runs the company. Each one removes a particular kind of toil that used to eat an engineer's afternoon, and in every case a human still signs off before anything reaches a customer. That second part is not a caveat we bolt on for comfort. It is the design. An agent that scales the work while a person keeps the judgment is a throughput multiplier you can actually trust. An agent that decides on its own is a liability waiting for its first bad day.

Here is what that looks like in practice.

The SRE agent: compressing the slow part of an incident

Site reliability work has a familiar shape. Monitoring flags an anomaly, and then the clock starts on the part that hurts: figuring out what broke. The fix is often quick once you know where to look. The looking is what costs you, usually at an inconvenient hour, usually under pressure, usually across a week's worth of changes any of which could be the culprit.

Our SRE agent goes after exactly that bottleneck. When monitoring flags an anomaly, the agent pulls the latest code changes, checks them against the symptom, and proposes a likely cause within minutes. It does not deploy anything. It does not roll anything back. It narrows the search and tells the on-call engineer where to start, and the engineer decides and fixes.

The value is not that the agent is clever. It is that diagnosis, the genuinely tedious detective work, no longer depends on one person.

The help-center agent: documentation that keeps pace

We ship every week. Documentation rots accordingly. Help articles are right on the day they are written, but the product moves and the articles do not, so a customer reads last quarter's screenshot of a screen that no longer exists.

Our help-center agent reads each new release, detects the features that are new or changed, and drafts or revises the matching article. When a screen has moved, it takes fresh screenshots of the relevant parts of the app so the visuals match what the customer is actually looking at. Then the product team reviews the changes before anything is published.

That review step is the whole point. The agent does the labour of keeping a sprawling help center current, which no human enjoys and few do consistently. A person still owns the words a customer reads. The result is documentation that tracks the product week by week instead of trailing it by a release or three, without a quarterly scramble to catch up.

The worktree switcher: space for several agents at once

The third example is not an agent at all, and that is exactly why it matters.

A worktree switcher lets a developer keep several versions of a project open on the same machine at the same time, rather than being pinned to one. On its own that sounds like a minor convenience. It becomes important the moment you start using AI coding agents in earnest. You do not want to run one and wait; you want to run several in parallel, each in its own isolated workspace so they cannot overwrite each other's work, and switch between them without friction.

This is the unglamorous plumbing that makes parallel AI coding practical instead of chaotic. The constraint is no longer how many agents you can point at a problem, but how many a developer can supervise at once. The supervising, again, stays human.

A small theme runs through all three. The agent absorbs the part of the job that scales badly with human attention. The human keeps the part that should not be automated at all.

The same goes for the agents we deploy for our customers in the data room

This is the principle we built our product on, and shipped to customers first.

Entropia was the first data room to launch an MCP server, in 2025, letting customers connect their own AI platform directly to their data room. Most of them use it with Claude. (More on the launch of our MCP server.)

For the uninitiated, MCP, the Model Context Protocol, is an open standard that lets an AI assistant connect to an external system and act inside it through a defined set of permitted operations. The power of this MCP connection then depends on many factors, such as the sophistication of the AI platform connecting to it, but also the tools the data room makes available to it.

We draw the same line for customers: the AI can read, search, answer and scale across thousands of documents, and a person still validates the outcome and owns the trail of what was done. Our autonomous IRL tracker is a good example, checking every line of a request list against the data room and returning the file marked complete, partial or missing, ready for review. The discipline is identical on both sides of the wall.

Which leaves the question that every team adopting these tools eventually reaches. It was never really whether the agents can do more; they can, and they will. The interesting question is where you choose to keep the judgment. We have made our answer fairly explicit, internally and in the product. The agents handle the toil. The decisions stay with us.

See what the same discipline does on your deal. Contact us.