Private beta: open now · General availability: planned for October 2026 · Design partners keep launch pricing
Connect your stack, ask across it, watch it, fix what breaks, build on it.
Your team’s databases, files, APIs, repositories and cloud accounts — and every answer the AI agents give comes back with the sources it read.
4m 13sfrom the first bad signal to the merged fix — the run replayed below.
The private beta runs until GA — planned for October 2026. Design partners from the list step in first.
what breaks if I drop orders.discount_code?
Scope22 connectionsDropping it breaks two surfaces: order writes in the API start failing, and the storefront’s order summary breaks with them — 13 references in all, 4 of them writes. The column also takes its partial index down with it.
Three questions, one incident, one pull request — the app’s own Ask screen, on the demo workspace’s own data. Not a video: the cards are the app’s real answer cards, links and all.
You asked: is checkout healthy?
Degraded. p95 is 10x its baseline and 2.3% of requests are failing.
Degraded since the v2.41.0 deploy — payment authorization is timing out.
You asked: what changed?
checkout-api v2.41.0 shipped at the exact minute the latency started, and it lowered the payments client timeout from 8s to 3s while deleting the retry wrapper.
TimeoutError: upstream payments timed out after 3000ms
1,284 eventsYou asked: fix it
Two files. Brings back exponential backoff with full jitter, sets the per-attempt timeout to 8,000ms and caps total time at 12,000ms. All 34 tests pass, and a panel of reviewers then tried to break it.
Every number on this page comes from the Northwind Commerce demo workspace, so the page and the product can never drift apart.
INC-241 on the demo workspace, in the order it happened. Every duration below but the first is the step’s own.
Where it started: one service, the state Datis put it in, and how much of that hour it actually sampled.
checkout-api, since the v2.41.0 deploy.
ERR-9F2A · TimeoutError: upstream payments timed out after 3000ms
Datis does not open an incident on one bad probe. It waits until more than one monitor is failing and the service’s error rate has breached at the same time — then it opens the incident, names what breached and pages whoever is on call.
3 consecutive probe failures on POST /checkout/confirm. Datis opens INC-241 and pages the on-call.
The agent gathers before it proposes anything: the error group, the recent releases of the failing service, the code the failure runs through, and whatever runbook your team already wrote about it. Nothing is inferred from the alert alone.
The agent reads the error group, the last three releases of checkout-api, the payments client and the checkout runbook.
It writes down what it intends to change, and what it decided against, before touching a file. The rejected options stay in the record — a plan that only lists what it did is not something you can argue with.
Restore the retry wrapper, raise the per-attempt timeout to 8,000ms, add a 12,000ms total budget. 2 alternatives rejected in writing.
The change comes out as a diff you read like any other — same repository, same review, same protections. It opens its own branch and its own pull request, like anyone else: Datis has no private way into your code, and the patch stays as small as the hypothesis allows.
2 files, +69 −16. Retries only on timeouts and 5xx, never on a decline, so nobody is charged twice.
Green tests are the floor, not the argument. The patched build goes to a panel of reviewers at once, each briefed to break it from one angle. Each one that comes back reports what it tried, what it found and what it could not check at all — and a brief that never ran is shown as unreviewed, never counted as a pass.
34 of 34 tests pass. Then 6 reviewers, each briefed to break the patch from a different angle, run at the same time — 5 come back.
A first attempt that spends the whole ceiling leaves the second one less time than the p99 it has to survive — and the suite passes anyway.
The retried method takes any path, and the policy that merged this reserves capture and refunds for two signatures.
Datis does not send traffic to a payment provider from a fix run, and a recorded contract does not say how one behaves under load. Production judges that, and this outcome is still open.
5 of 6 briefs came back. 2m 21s of review, finished in 47s — they start together, so the step is the slowest one, not the sum.
Nothing raised here blocked the merge — a reviewer that had broken the patch would have. It rides this run’s outcome instead: if that turns, the class stops merging itself.
Everything the run knows goes into the description: the hypothesis, the evidence it rests on, and every reviewer’s verdict — including the ones that raised something. The pull request is the argument, not a notification that one exists.
Opens against main with the hypothesis, the evidence and every reviewer’s verdict in the description.
A change merges itself only where its class has earned it: enough judged runs behind it, no regressions among them, and the checks green. Everything else stops and waits for a person, and the ledger records which of the two happened.
Build, test and lint come back green, so the policy merges it. Nobody is asked and nobody signs — this class of change earned that on 3 judged runs with no regression.
Every duration above but the first is that step’s own elapsed time. Nobody was asked and nobody signed: the policy governing these paths merges retry-and-timeout changes once the tests are green, because that class has held 3 times. Every other class still stops for a person.
Models can now carry a multi-step fix end to end. What is missing is not capability — it is governance: who allowed the change, what evidence backed it, and which class of change has earned the right to merge without a signature.
The fix that merges needs the schema, the code, the runbook and the cloud account in the same window — which is why it cannot be a feature of one observability silo. The triage step above read all four before it named the change that did it.
Autonomy is a dial you earn, not a switch you flip. Every run adds to a track record, and the track record — not a mood — is what moves the dial.
Datis writes the Terraform, prices the change and runs your policy checks before a single resource exists. Nothing is applied without an approval.
Prompt: add a Redis cache and an SQS queue for checkout, production, us-east-1. the cache is for quote pricing and the queue is for order-placed side effects. give the queue a dead-letter queue.
Targetprod · us-east-1resource "aws_elasticache_subnet_group" "checkout_cache" { name = "${var.environment}-checkout-cache" subnet_ids = var.private_subnet_ids} resource "aws_security_group" "checkout_cache" { name = "${var.environment}-checkout-cache" description = "Redis access for the checkout service" vpc_id = var.vpc_id ingress { from_port = 6379 to_port = 6379 protocol = "tcp" security_groups = [var.ecs_task_security_group_id] } tags = var.tags} resource "aws_elasticache_replication_group" "checkout_cache" { replication_group_id = "${var.environment}-checkout-cache" description = "Quote pricing cache for checkout-api" engine = "redis" engine_version = "7.2" node_type = var.node_type num_cache_clusters = 2 parameter_group_name = "default.redis7" port = 6379 automatic_failover_enabled = true multi_az_enabled = true at_rest_encryption_enabled = true subnet_group_name = aws_elasticache_subnet_group.checkout_cache.name security_group_ids = [aws_security_group.checkout_cache.id] maintenance_window = "sun:05:00-sun:06:00" snapshot_retention_limit = 3 tags = var.tags}4 policy checks passed, 1 warning: prod requires 2 approvers.prod
Databases, files, APIs, repositories, cloud accounts and payments — every one connects the same way. What Datis may then do with a connection is a policy you set, not a property of the provider.
One connection, one question, one answer with the evidence attached — that is the whole pitch, and it is what we would like to show you.
Founder’s note
I run production stacks for a living, and Datis is the tool that work kept asking for. Every request on the list lands in my inbox, and the reply is mine too.
Solo founder, said plainly: the person who wrote the policy floor is the person who answers your email.
Sebastián Galli · Founder & CEO, Datis
Sebastian Galli SAS · Montevideo, Uruguay · contact@datis.app