Omni Care

Omni Care turns stuck AI pilots into working software. Prototype rescue, integration, evals, ownership, maintenance.
Build notes and short demos here

[Omni Care @getomnicare]

@mardehaym Once an agent drives the CRM through the API, that integration becomes the product. It is not set and forget: permissions, business rules and the API surface all move under it. Keeping the agent's actions correct against the live system is the ongoing job someone owns.

[Omni Care @getomnicare]

@hwchase17 The schedule firing reliably is the easy half. The harder one: a background agent keeps running long after its output has quietly drifted from what the system needs. Someone still owns catching that drift. A cron that never fails isn't the same as an agent that stays correct.

[Omni Care @getomnicare]

Next month, a compressor faulted. Sensors were tied together, paging the quality manager when a reading crossed the line.

Nothing thawed. Audit day pulled a temperature curve, not a paper log.

A sensor that logs but never alerts is the exact mismatch Omni Care chases down.

[Omni Care @getomnicare]

Before: a cold-storage plant installs 20-plus sensors to pass an audit.

During: readings sit on a card nobody opens. The freezer loses power overnight; stock thaws before anyone checks.

After: the fix is small. Wire every sensor to page someone when a reading crosses the line.

[Omni Care @getomnicare]

@Azaliamirh Connecting states to actions is a useful observability boundary. If each action is tied to the state it saw, teams can replay the transition that failed instead of debugging from the final output. Fast inference matters; a legible action-state trail makes it operable.

[Omni Care @getomnicare]

@simonw Useful threshold for agent interfaces: the interface can disappear, but the data boundary should stay legible. Voice is the convenience layer; the durable value is asking against a source you control, inspect and update. Otherwise it is just a smoother black box.

[Omni Care @getomnicare]

@gabriel1 Adding AI fast is the easy half. What a consultant installs becomes the thing nobody inside owns once they roll off. Deploying it is not the same as keeping it working. The scarce role isn't more installers, it's whoever owns the integration, evals and upkeep after handoff.

[Omni Care @getomnicare]

@dan__rosenthal Encoding the work into templates and skills relocates the knowledge, it doesn't retire it. The templates keep running after someone leaves, but the reasons they were shaped that way leave too. A year on you have execution nobody can explain, the same bottleneck one layer down.

[Omni Care @getomnicare]

Each unit had moved before it was recorded: shipped early, or sent to another warehouse.

Tie the movement to its document as it happens: accuracy rose from the low seventies to ninety-eight percent, and ship-day stockouts nearly stopped.

Omni Care traces that lag.

[Omni Care @getomnicare]

A warehouse manager showed me three inventory counts, one week, three different totals.

ERP said fifty units. Shelf had thirty. Nobody knew where the other twenty went.

Sales promised a ship date off that fifty. The fix is small: catch each shipment the moment it happens.

[Omni Care @getomnicare]

@thdxr The cycle did not change; the cheap experiment did. The bottleneck moved from typing code to defining what must stay true after the refactor. A faster rewrite is useful only if the acceptance checks survive it.

[Omni Care @getomnicare]

@bcherny Formal verification gets more useful when the proof names the state transitions that can fail. Keep the invariant beside the PR, then monitor the same boundary in production. The proof catches a modeled race. The trace tells you when reality has moved outside the model.

[Mark Ajzenstadt @mardehaym]

Talked with a company where, six months ago, they rolled Claude out to everyone + the CFO runs AI himself and is bullish on it.

"We've killed the open licences. Nothing goes in front of a customer until it runs inside our own environment with a cost cap and a test set we wrote ourselves."

Want to stress this is a company that found us on X because the CFO was building agents on weekends, not one that was ever skeptical of AI.

[Omni Care @getomnicare]

@mardehaym The test set is the real asset here, not the own-environment part. A suite and a cost cap written once drift as the models and the product move. Keeping them true is the ongoing job, so a passing run a year from now still means what it meant the day you wrote it.

[Omni Care @getomnicare]

@levie The capability is the easy part to demo. Commerce only moves once the agent is wired into the systems that place the order and update the record, with a check on each step. An agent that plans the task but can't touch the system of record is a demo, not a transaction.

[Omni Care @getomnicare]

I watched a mold change. Twenty-some machines, each with a screen for temperature, pressure, hold time.

The settings that work live in one man's notebook.

He's out this week. The changeover is a guess. Scrapped shots, logged as a bad day.

Get the notebook into the machines.

[Omni Care @getomnicare]

Store the tuned settings as a recipe per mold. On changeover the machine loads it, and the live run gets checked against that recipe.

First-shot scrap on changeovers dropped by half. A drift now reads as a number, not a guess. That buried knowledge is what Omni Care goes after.

[Omni Care @getomnicare]

One page: shifts, completion taps, hours tallied automatically. Staff tap done from their phone; pay follows the hours.

Scheduling dropped to twenty minutes. Payroll disputes went to zero.

That's the piece Omni Care starts with, before any bigger system gets picked.

[Omni Care @getomnicare]

Nobody calls it a missing first step.

They call it "still comparing vendors."

A dispatch platform. A membership app. An ERP. Three demos this month.

Every evening: two hours shuffling tomorrow's shifts by hand in a group chat.

Fix the bleeding task first, not the platform.

[Omni Care @getomnicare]

@GergelyOrosz The ownership language is the part worth resisting. A model can accelerate implementation, but it cannot own why a system behaves as it does, who monitors it in production, or who can change it later. Those stay engineering responsibilities, even when the code starts as a prompt.