Work that shipped.

The CRM had no honest way to show a deal as "blocked". Leaders couldn't tell whether a quiet deal was stalled at the client or simply neglected, so they couldn't trust the pipeline, and associates got misjudged for delays outside their control.

Six asks triaged:

• Build now: Q5 Deal on halt; Q4 Notify if stale a week (a signal, not an alert).
• Merge: Q2 Track pipeline deals (subsumed by the urgency list); Q1 Track team performance (partial, proxy only, no revenue data).
• Build later (V3): Q3 Log documents to deal.
• Kill for V1: Q6 Reassign deal on leave.

Rationale: Q2, Q4 and Q5 trace to one root problem, that the CRM can't show "blocked". Q3 and Q6 are real but don't touch it, so they're deferred and will attach to the same deal record. Q1 is partly answered by a lightweight team rollup.

The Deal Truth Layer: one health status per deal (On Track, Stale, On Hold), replacing guesswork. Built as four tasks:

• T1: deal status state machine: status, hold_reason, hold_resume_date, last_meaningful_update_at.
• T2: staleness derived from status and elapsed time.
• T3: mobile deal list sorted stale-first, then on-track, then on-hold, with filter chips.
• T4: set-on-hold flow on the deal detail screen.

Key rules: the timestamp updates only on real activity, never on read, and is stored in UTC. Held deals auto-revert to active when the resume date passes.

Scoped to a V1 prototype built in 4 hr 40 min (time on task). Engineering was broken into four tasks with explicit dependencies (T1 → T2 → T3; T4 depends on T1 and T3), each with acceptance criteria. Out of scope for V1: document upload, reassignment, real backend/database/auth, push notifications, outcome-based metrics (revenue, win rate, cycle time). Implementation assumptions (CRM event availability, a 7-day default threshold) enabled the prototype; strategy decisions needing stakeholder input remain open.

A prototype, not a shipped product. It lets a field associate declare a deal "On Hold" with a reason and resume date, and gives a leader a list that surfaces stale deals first and separates stalled-at-client from neglected. Risks named up front: (1) without existing event timestamps, staleness can't be derived without new instrumentation; (2) associates could use on-hold to dodge scrutiny, mitigated by an auto-expiring resume date.

Outcome metrics (revenue, win rate, cycle time) were deliberately left out of V1. In-product signals: time since last meaningful update (168-hour stale threshold; 7-day default) and on-hold status with resume date.

Hexalog's platform already surfaces exceptions in real time, but resolving one still takes a person 2–3 hours across 4–5 disconnected systems. Today's flow is notice → search systems → diagnose → contact stakeholders → decide → execute → follow up, with no structured record of why a decision was made. Cost scales with shipment volume, which works against Hexalog's own "scale without expanding your ops team" promise. Exceptions are already a named object in the product; resolution is the gap.

Priority = Frequency + Repeatability + Value − Risk-if-wrong (each scored 1–5), a RICE-style approach adapted so downside risk is explicitly penalized. Scores:

• Customs DOC_HOLD: 12, build first.
• Failed delivery attempt: 10, next.
• Warehouse QC hold: 9, next.
• Carrier delay / port congestion: 9, later (low controllability).
• HS classification ambiguity: 5, excluded from autonomy (assistive only).

Decision: build the highest-scoring class first, not the highest-value one. HS classification is the highest value but a judgment call with legal exposure, so the human stays and the system auto-compiles the dossier. Knowing what not to automate is a prioritization decision.

The person stays in exactly one place, the decision, and the system assembles everything on either side: detect → investigate → explain → calculate impact → propose plan; human approves; execute → verify. Six narrow agents, each with one job and an explicit "must never" (for example the Document agent can never submit to a government portal unsupervised, and the Impact agent can never modify an SLA or client commitment). Autonomy is set by policy, per step, by the action's risk class and never by model confidence, in three tiers: Auto (low-risk, reversible, audit-logged), Recommend (agent-prepared, human-executed), Human (regulatory or above-threshold financial, always gated). Policy is configuration, not code. Reject-with-reason halts execution and writes to an audit log that becomes eval data for tuning autonomy thresholds.

Prototype scoped to one exception class (customs DOC_HOLD): the full detect → investigate → propose → approve → execute → verify loop, a real reject path, and a simulation/eval harness over 6 scenarios. Before touching a real shipment, it is tested against 50–100 past exceptions with known outcomes. Autonomy expands only when exit criteria are met on real data: Observe (≥50 live exceptions shadowed; eval set v1) → Recommend (root-cause accuracy ≥90%; ops agree with plan ≥85%) → Assist (≥95% task success, 0 critical failures, sustained 4 weeks) → Resolve (≥90% end-to-end; false-confidence ≤2%; override ≤10%) → Optimize (next class). Out of scope: other exception classes, any autonomous HS action, unsupervised filings, production integration (no access). Key assumption to confirm with engineering in week 1: the platform exposes event streams and allows write-back.

A concept prototype, not live. The change: from one person doing all seven steps alone to the system doing everything except the decision, with a structured record of why each decision was made. In the 6 simulated scenarios: 3 solved correctly on their own, 2 correctly escalated to a person, 1 deliberately built failure (91% confident, wrong cause) caught by the verification step and added back to the test set. Modelled business case per 100 exceptions/month: 230 ops-hours saved, ₹4.2L cost avoided, 9 fewer SLA breaches. These are modelled from named assumptions (₹1,800/hr blended ops cost, 2.9h median handling time), not claims.

Goal: reduce ops hours to resolve a customs exception without increasing wrong or unsafe resolutions. Targets: root-cause accuracy ≥90%, task success ≥95%, 0 critical failures, false-confidence ≤2%, human override ≤10%.

Transport exists; coordination doesn't. Every leg of a commute (first mile, metro, transfer, last mile) has a different price and failure mode, so the commuter is the integration layer and one slip costs the whole trip. Nobody owns the outcome. By 2035 the question won't be "how do I get a vehicle?" but "how do I reliably get to work across a fragmented system?" Why it matters: ~600M urban Indians by 2036; 78% of passenger transport by road vs 1% metro (2025); $840B of urban infrastructure needed over 15 years from 2022.

Five options scored out of 100 on my own judgment (user clarity, problem fit, concreteness, trade-offs, why Ola, 100M credibility, metric quality):

• A Orchestration only: 75.
• B Autonomous 8–12 seat pod: 75.
• C 2–3 seat pod: 65.
• D Gig-worker subscription: 56.
• E MoveGrid (A + B, human-driven first): chosen. Shuttle for reach, orchestration for trust.

RICE also ranked orchestration first and autonomy lowest on confidence. Pilot scope by MoSCoW:

• Must: saved commute, plan, booking, live ETA, transfer protection, pass, SOS.
• Should: employer pass, metro-card tap, regional languages.
• Could: gig-worker earning mode, carbon tracker.
• Won't yet: autonomy, personal vehicles, social features.

Trade-offs accepted: human-driven first (gives up the driverless cost advantage, removes the biggest technology risk); a subscription over per-ride margin (retention and predictable demand); a hybrid fleet (control for capital efficiency); dense corridors only (breadth for utilisation).

One product, two layers: a shared electric shuttle you can ride, and a layer that guarantees your whole journey.

• MoveGrid Shuttle: 8–12 seat EV on dynamic fixed corridors, pick-up within ~400 m, wait ≤5 min, human-driven at launch.
• Orchestration engine: plans the whole trip, holds shuttles for connections, watches metro and bus feeds, replans when something breaks. Rules first, ML later.
• Commute Pass: ~₹1,799 a month for 4 shuttle legs a day over ~22 days, with an employer-paid option.
• MoveGrid app: the one place the commuter interacts.

The system acts first and tells the commuter after, which makes it a guarantee, not an alert. Why Ola: vehicle manufacturing, cells and batteries, MoveOS software, service and charging network, and brand trust.

A hypothesis-to-pilot plan with gates and kill criteria. Roadmap: Discover (commuter interviews, corridor selection, data deals) → Pilot (1 corridor, 3–10K commuters; shadow mode, employee beta, then public; gate: break-even utilisation and 90% on-time) → Expand (5–10 cities; gate: 1M+ commuters, positive contribution margin) → Network → Layer (100M on the grid). Experiments before scaling: pass vs pay-per-trip, transfer protection vs none, three price points, shadow mode. Commuters arrive in bulk via employers, metro and bus operators, residential clusters and city authorities. Stop or pivot after 6 months if trips per shuttle stay under 150 a day, D90 retention is under 40%, the reliable-commute rate doesn't beat private options, or operators won't share data. Top risks: low utilisation, unreliable transit data and permits, driver displacement, capital intensity, safety (especially for women).

A strategy, not a shipped product. What it enables: a commuter hands one trip to one plan and one pass, with a promised arrival. Modelled scale (assumptions to validate): ~100M of ~250M urban daily commuters on the grid (40%); ~10M on Ola shuttles (~20M trips a day), which means ~80K shuttles at ~250 trips each; if the grid captures 20% instead of 40%, it still reaches 50M. Unit economics (assumptions): ₹2,850 cost per shuttle per day, ₹20 average fare per leg, break-even ≈145 trips per shuttle per day, the one number the pilot must prove.

North Star is Reliable Commuters: weekly commuters (3+ commute days) who arrive within the promised window on at least 90% of those days. It combines habit (reach) with quality (the guarantee), and downloads and rides don't show whether the problem is solved. Layers: Reliability, Engagement, Economics, Guardrails.