Ambiguous customer decomposition (Palantir-style case)
Expected question
"A customer gives you a vague, high-stakes goal with messy data. You have 45–60 minutes. How do you decompose it before proposing architecture?"
Variant forms
- "A major city wants to reduce 911 response times. They have call, traffic, and GPS data. Go."
- "A regional bank wants unified fraud detection across three acquired systems. Scope 90 days."
- "A pharma company wants an AI assistant over internal compounds data with IP/legal constraints."
- "A logistics firm wants an agent that reroutes shipments using SAP, weather, and warehouse managers."
- "An insurer wants LLM claim summarization across 30M claims under state regulation."
- "A hospital network gets 38,000 support tickets/month with patient data. Automate triage — where do you start?"
- "A bank wants an internal assistant over ten years of policy docs; compliance won't allow errors."
- "A logistics company wants to 'use AI to reduce delays.' Turn that into a concrete first project."
- "Ops says they 'can't trust the dashboard.' Diagnose and propose a plan."
- "Don't design Instagram — design this customer's first useful system."
- "What questions do you ask in the first ten minutes?"
- "How do you know when you've scoped enough to build?"
- "How would you measure and demonstrate ROI for the first wedge?"
- "How do you start when the customer has poor data quality?"
Where this actually gets asked
Palantir FDSE-style cases, Databricks / OpenAI FDE customer cases, and Anthropic Applied AI “ambiguous problem” rounds. The bar is structured decomposition under time pressure, not Kafka fluency. Jumping to components in minute one fails.
The question, as it might actually be asked
"Here's a vague customer problem. Talk out loud. Don't jump to Kafka."
The framework
30-second thesis
I'd refuse architecture until we name the decision and the 90-day metric. Then I inventory what will kill a naive design — SSO, residency, irreversible writes, change windows — and pick the smallest production wedge that can move that metric with HITL on the scary path. Platform comes after the walking skeleton has a name.
2-minute method
I'd talk through the room like this — not a component tour:
Clarify → outcome → constraints → data → actors → wedge → risks → next week.
| Minute | Move | What I'd actually say / ask |
|---|---|---|
| 0–8 | Goal & success | “Who's the user, and what decision gets better? What number moves in 90 days — and what's the baseline window?” |
| 8–15 | Constraints | “SSO? Residency? Change freezes? What action is irreversible on day one?” |
| 15–25 | Reality inventory | “What's system of record? Who owns the data? Labels any good? Offline ok for v1?” |
| 25–35 | Decomposition | Entities, workflows, decision points — human vs agent, aloud |
| 35–45 | Wedge | Smallest production path under those constraints; name non-goals |
| 45–55 | Risks & ops | Failure modes, HITL, evals, rollback, who owns it after I leave |
| Last | Ask | “What am I missing? What kills this in week two?” |
Hard rules
- Never propose architecture in minute one.
- Separate decision support from autonomous action.
- Prefer a walking skeleton over a perfect platform.
- Name what you will not build in v1.
- Every irreversible tool call needs a governance story.
Requirements (what the case must produce)
Functional
- Named user + decision + 90-day success metric with a baseline window.
- Explicit non-goals for v1.
- One wedge path: read vs write boundary stated.
Non-functional
- Constraints that kill naive designs (SSO, residency, change windows, PHI/IP).
- Operability: evals, HITL, rollback, handoff owner.
- ROI story a sponsor can defend — not vanity model metrics.
Core entities / actors
- Sponsor: owns the 90-day metric and weekly review.
- Operator / end user: lives in the workflow daily.
- Systems of record: authoritative writes (ERP, claims, EHR, ticket system).
- Data plane: warehouses, docs, event streams — often incomplete.
- Governance plane: identity, HITL, audit, legal/compliance veto.
- FDE: temporary critical-path owner who must exit.
Process flow
Rendering architecture diagram…
High-level design (case output, not platform)
Deliver in the room:
- One-sentence problem restatement.
- Ranked workflows (top 3) with forced pick.
- Wedge sketch: identity → assist/retrieve → optional tool with HITL → audit.
- Measurement plan + shadow rollout preference.
- What becomes reusable product vs stays customer-specific.
Deep dive 1: worked EDI / exception pattern (H with P muscle)
Prompt shape: “Ops wants AI to fix EDI / exception workflows.”
I'd open the same way I would in a Lucid Supply Chain room (P muscle, public prompt is H/R):
- Clarify: “Which exception types eat the most hours? Are we measuring tickets, cycle time, or vendor fees — and over what baseline window?”
- Constraints: “Who can approve an irreversible EDI mutation? What's source of truth?”
- Wedge: RAG over procedure + classify exceptions + human confirm on writes. Not thirty agents day one.
- Integrate: event path into the bus they already have; identity from existing SSO.
- Measure: volume, HITL accept/reject, time-to-resolution. Savings only with a dated baseline. Shadow before autonomy.
- Handoff: runbooks; ops/platform owns prompts and evals after I leave.
Same skeleton for bank fraud, pharma QA, logistics reroute — swap entities, keep the order.
Deep dive 2: hospital / PHI and regulated accuracy
Classify + draft only in v1; humans send; minimize PHI in logs. Eval escalation precision/recall before auto-reply. When compliance says “no errors,” I don't promise 100% model accuracy — I promise fail-closed + human ownership on high-harm paths.
Deep dive 3: ROI that survives a skeptical CFO
Baseline hours or $ risk for 4–8 weeks (H until you have P). Primary metric plus guardrails — reopen, CSAT, safety. Weekly sponsor review. Never claim savings without a dated window.
Quantitative trade-offs
| Decision | Trade-off and reversal evidence | Evidence class |
|---|---|---|
| Assist-first vs autonomous writes | Assist earns trust faster; reverse when write path is reversible, eval-gated, and sponsor demands cycle-time | H/P |
| Shadow vs big-bang | Shadow delays “wow”; reverse only if shadow is impossible and blast radius is tiny | H |
| One wedge vs platform rewrite | Wedge proves value; reverse when shared control plane is already funded and wedge blocked by missing platform | H |
Migration / next-week plan
- Confirm metric + sponsor calendar hold.
- Access request for one data slice + staging SSO.
- Golden-set seed (20–50 hard cases) before model shopping.
- Shadow beside humans for one workflow.
- HITL on any write; review reject reasons weekly.
Org ownership
- Business sponsor owns outcome metric.
- Ops / domain owns workflow truth and HITL reviewers.
- Platform / security owns identity, egress, audit.
- FDE owns critical path until handoff criteria met.
Situation
In Lucid-style Supply Chain / Commerce rooms (P), stakeholders often open with a vague goal — “use AI on exceptions / ops” — with messy systems of record, real change windows, and irreversible actions (EDI mutations, payment-adjacent paths). The interview case is the same muscle under a public prompt (911, bank fraud, hospital triage).
Task
In 45–60 minutes, turn ambiguity into a timeboxed wedge with explicit non-goals, a governance boundary, and a next-week plan — without pretending the data is clean or jumping to a full platform.
Action
- Open with user, decision, and 90-day metric — refuse architecture until those are named.
- Inventory constraints (SSO, residency, irreversible actions, change control) aloud.
- Force-rank workflows; pick one wedge (usually read/assist + HITL on writes).
- Sketch integration into existing identity and event/data plane — not a parallel demo stack.
- Define eval + shadow + handoff ownership before claiming ROI.
- Close by asking what would kill the plan in week two.
Result
A case answer that sounds like Staff+/Principal FDE under time pressure: structured ambiguity → walking skeleton → governance → handoff. Lucid P is muscle memory for stakeholder rooms; open O stack (Enterprise RAG, AegisAI HITL) is how I'd harden the wedge — not a claim those repos run at Lucid.
The follow-up question you should expect
"Why not start with a multi-agent platform?"
Because agents multiply failure modes before you have a metric, an ACL story, or HITL reviewers.
I'd earn autonomy after assist + evals prove the slice. Gateway, retrieval, orchestration patterns
can reuse once the wedge is real — same brand, not a new platform per customer.
What I'd ask them
- What decision improves, and who owns the 90-day number?
- What's irreversible on day one — and who can approve it today?
- What's the worst data quality you're willing to admit in this room?
- If this fails in week two, what usually kills projects here?
Candidate-owned evidence prompts
- Which Lucid workflow will you use as the analogy if they ask for a real example?
- What baseline window supports any hours/$ claim?
- What irreversible action will you put behind HITL in the first sentence of the wedge?
- What will you explicitly put on the non-goals list?
Author reference (do not memorize)
Treat the EDI/hospital worked examples as templates. Convert to “I” only with evidence-ledger provenance. Public case prompts are H/R practice; Lucid embed is P.
Staff+/Principal signal rubric
- Mid-level: Jumps to components (“vector DB + LLM”) without users or metrics.
- Senior: Asks clarifying questions; proposes a plausible v1.
- Staff+: Forced ranking of workflows; irreversible vs reversible; data reality; 90-day plan.
- Principal: Org ownership, product feedback loop, and how this customer pattern generalizes.