Lear is an AI engineer that stays on call for your team. When something breaks, it proposes a recovery plan and asks before it does anything risky. It runs inside your own infrastructure.
/pay 5xxVerified14:12:00 · 0%Example incident, the same one the loop below walks through. Not a customer deployment.
The alert is in PagerDuty, the change is in GitHub, and the access belongs to someone who is asleep. Most of the night goes to finding context and permission before anyone can touch the fix.
That night took 68 minutes and two people to ship one rollback.
PagerDuty
Pages the on-call engineer. Checkout is failing.
Grafana
They find 502s on /pay and a full connection pool.
GitHub Actions
An evening deploy changed the pool size. Probably that.
Kubernetes
Rolling back needs cluster access. They wake the platform lead.
Kubernetes
The rollback runs. They watch dashboards until it holds.
Bed
The write-up waits for the morning, if it happens at all.
Lear moves through six states, in the same order every time, inside your infrastructure. Here is the incident from the film: at 14:02 a deploy cut the payments connection pool from 20 to 2, and checkout started returning 502s.
/pay 5xx rate14:12:00Observe
Lear checks health endpoints, operational signals and recent changes. Watching needs no write access.
| 14:03:10 | GET /pay | 502 on 31% of requests |
| 14:03:10 | payments-db pool | 2 of 2 in use, 148 waiting |
| 14:02:41 | deploy checkout | a91f3c2, merged #482 |
Diagnose
Lear lines the alert up against code and infrastructure changes in the same window, and shows you the evidence.
config/payments.yamla91f3c2
- pool_size: 20 + pool_size: 2
Plan
It says what changes, where, under which permission, and how Lear will tell whether it worked.
Roll back checkout to the 14:01 build
deployment/checkout in prod. Nothing else changes./pay returns 200 for 5 minutesApprove
This is the trust boundary. A person approves the exact plan you just read, or nothing happens.
Approved by you at 14:06
Roll back checkout to the 14:01 build
Act
Lear runs the plan you approved and nothing else, using only the access you granted for it.
$ kubectl rollout undo deployment/checkout -n prod deployment.apps/checkout rolled back
Verify
Lear probes checkout until the recovery holds for five minutes, then appends each step to the audit trail.
GET /pay 200, 41 ms median, 5 minutes clean| 14:06:02 | Plan approved by you |
| 14:06:09 | Rollback applied |
| 14:11:09 | Recovery verified |
Example incident, shown for illustration. Not a customer deployment.
Inference was running at 1.7 tokens a second on a GPU the team pays for. Lear probed the machine and found that the driver worked but the app couldn't see the GPU.
Each fix went through a pull request and its own CI run, and a person approved every one. Lear wrote three of the four, which reached 55 to 65 tokens a second. An engineer wrote the fourth, and the same RTX A5000 now runs at 870.8.
Each connector lists what Lear can read and what it can change. Lear starts with reads only, and every change waits for you to approve the exact plan. Credentials stay in your environment.
Connectors / UptimeRobot / Live URL Monitor
every 30s by default13 connector implementations in the repository today. The CI and Kubernetes fix paths are live-verified.
Pick one service that pages you. Lear works on that one first.
Connect it read-only. Lear watches and explains, and changes nothing.
When you want Lear to act, approve its plans one at a time.
Every fix is verified and kept in an append-only audit trail.
A year for a 40-engineer US team, on the calculator's defaults
You keep
$10,990 to $11,677
The read-only trial is free. After that, Lear bills its share of the savings it measures in your environment, not of this estimate.