Empirik announced more than $21 million in funding and an infrastructure agent on September 1. Its promise is to explain the consequences of a change before deployment. That is a claim to evaluate, not a demonstrated guarantee against outages.
What the company has announced
The launch post by CEO Kartik Chandrayana names Sequoia and S32 as lead investors, alongside Canapi Ventures and Alumni Ventures. S32 was missing from our previous account. The company says the product is already used in production, including at Guardant Health; that customer statement does not supply an independent accuracy benchmark.
The product description starts with a proposed change, maps its impact onto a live environment, and returns affected services, owners and evidence. Execution depends on the approvals and permissions the customer grants. Buying an analysis product should not be confused with authorizing it to change production.
Test the missing edge in the dependency graph
Consider an illustrative migration: an engineer changes a database endpoint, the API is updated correctly, but a nightly billing job still uses the old address. A useful review must discover that job and explain its dependency. Merely listing resources that appear in the pull request misses the failure.
The diagram uses that invented example to show the evaluation target, not a screenshot of Empirik or a result obtained with the product. Ask the vendor which observed configuration, runtime connection or event supports each edge. Also ask when that evidence was last refreshed. A graph can be detailed and still stale.
A pilot with measurable acceptance criteria
Start with a limited environment and advisory permissions. Choose a recorded set of both incident-causing and harmless changes, with known outcomes. Reconstruct only the evidence available before each deployment; letting a system see the later incident report would make the exercise misleading.
Record three separate results: harmful changes missed, harmless changes flagged, and evidence that a reviewer could actually verify. Track review time as well. A correct warning that arrives after approval is not useful as a deployment gate.
Finally, introduce deliberately undocumented dependencies in a test environment. This probes discovery, rather than the ability to restate infrastructure-as-code. Decide in advance which failure rate and permission boundaries your team will accept. Keep these acceptance criteria independent of the vendor’s terminology.
What remains unproven here
We have not run this pilot or measured the product’s false-positive rate. A funding round and named deployments support the existence of a business and its claims; they do not establish that an agent can anticipate every outage. The practical next step is a bounded evaluation with observable failures and a human decision on deployment.
Sources
- Empirik launch announcement, September 1, 2026
- Empirik: current product workflow and permission model
Checked the vendor announcement, corrected the investor list and replaced outage-prediction guarantees with an evaluation method.