Automatic Repair Still Needs Buyer Rules

2026-05-11 · 7 min read

Some fixes are harmless. Some actions should wait for review. A real workflow needs that boundary.

Where repair becomes risk

Repair is useful until it starts guessing. Fixing a wrapper is fine; guessing a customer ID, payment amount, or message recipient is not.

Automatic repair helps only while it stays inside rules the buyer would approve.

Better Call lets teams decide which repairs can pass, which need review, and which must stop. The product keeps control of business risk.

The product should make policy visible before the repair layer touches a customer-facing or production action.

The buyer should be able to name which repairs are allowed before a workflow goes live.

flowchart LR
  A[User pain] --> B[Bounded workflow]
  B --> C[Reviewable action]
  C --> D[Operational evidence]
  D --> E[Repeatable outcome]

A buyer should ask whether repair rules can change by environment, tool risk, customer data sensitivity, and action type.

The user-facing promise is not “repair everything.” It is “repair what is mechanical and stop where judgment matters.”

Model Cost And Privacy

Flev workflows can route routine, structured steps to local or private small models while keeping stronger models available for complex reasoning.

Classification, extraction, validation, routing, and repair do not always need the most expensive model in the stack.

Teams should be able to see which model handled which step, why fallback exists, and who can approve changes.

Better Call evidence shows tool-call accuracy improving from 73.4% to 83.8% on 3,625 granite4.1:3b BFCL v4 cases.

User Guides

Start with the DevOps intake: one failing CI, deploy, Kubernetes, or incident path, one owner, one useful result.

Start the intake