MivaanOS

Steel distribution runs on people holding state in their heads. A Customer Account Manager starts the day not knowing what the factory released overnight, which customers are eligible for it, what price was approved, or which of their accounts have gone quiet. The information exists — in the ERP, in the factory report, in the pricing approval chain, in the visit logs — but assembling it takes an hour of tab-switching before any selling happens. Management sees the same picture a day late, in a spreadsheet someone rebuilt by hand.

• Overnight factory hold reports arrive as files nobody has time to reconcile against customer eligibility before the morning.
• Day-price approvals, bulk-order deviations and visit requests queue in email; approvals are the bottleneck, not the decisions.
• Customer segmentation — loyal, dormant, blocked — is stale the moment it is compiled, so outreach goes to the wrong list.
• SOR checks, NSR calculation and stock availability each live in a different screen; nobody does all three before quoting.

MivaanOS is a voice-first control layer over the full distribution lifecycle, not a chatbot bolted to a CRM. A spoken intent is parsed into a plan, dispatched across a fleet of roughly 80 specialised agents, and executed against the systems of record — with the agents driving the existing application surfaces directly through DOM-level control where no API exists. Agents hold persistent memory across sessions, so context accrues per user and per account rather than resetting at every login. Role determines both what is retrieved and what may be acted on: the CEO's brief aggregates, the HOD's brief queues approvals, the CAM's brief is a worklist. Incumbent systems remain the system of record throughout.

Rule-based automation fails here for a specific reason: the questions are open-ended and the state space is not enumerable. “What's the status today?” has no fixed query behind it — the answer depends on role, on what changed overnight, on which of a hundred conditions are currently interesting. That requires a model that can plan, decompose and select tools at runtime, and a memory that persists what mattered yesterday. The DOM-control layer exists for the same reason: enterprise steel systems expose no clean API for half these actions, so the agents operate the software the way a person does, under supervision, rather than waiting for an integration programme that would take a year.

INTERFACE

Voice-first, role-aware; text fallback

ORCHESTRATION

~80 specialised agents under a single planner

MEMORY

Persistent, per-user and per-account, across sessions

CONTROL

DOM-level control of incumbent applications

COMPLIANCE

GST and TDS verification gated into onboarding

SYSTEM OF RECORD

Incumbent ERP retained; no rip-and-replace

1. 01Single spoken question returns a role-scoped operational brief — aggregate for CEO, approval queue for HOD, worklist for CAM.
2. 02Overnight factory hold reports parsed and matched automatically to eligible customers before the working day starts.
3. 03Day-price approvals, bulk-order deviations and visit requests surfaced as a decision queue rather than an inbox.
4. 04AI-generated customer segmentation drives differentiated outreach without a manual list-build.
5. 05SOR check, average NSR calculation and stock availability resolved in one turn, pre-quote.
6. 06Agents operate legacy screens directly via DOM control where no integration surface exists.

~80

Agents in production orchestrationverified

Same day

Management visibility, previously next-daydesign intent

• DEMAND PLANNINGHub for Demand Forecasting→
• RESTAURANT OPERATING SYSTEMPrime POS→
• PHYSICAL AI OPERATIONSMotion™→