I designed Julie so a person can describe what happened in a meeting, review the exact CRM changes it prepares, approve them, and see what the system of record actually contains afterward.
Notes still have to become CRM records, follow-up tasks, owners, dates, and linked entities. A summary helps someone remember the meeting, but it does not complete—or verify—the operational work.
Company names may match multiple records, the CRM may change after preview, and a timed-out write may already have succeeded. Giving a model direct mutation authority turns ambiguity into hidden risk.
I designed Julie so the model can inspect context and prepare typed actions, while a durable application workflow owns clarification, editing, approval, execution, readback, reconciliation, and audit.
The default story stays at the level of the person and the work they are trying to finish.
Natural language remains the fastest way to capture what happened.
Julie checks relevant accounts, contacts, deals, and existing CRM state.
The person can clarify, edit, remove, or correct every suggested action.
Approval binds to a specific payload and CRM state, not a vague instruction.
Deterministic application services perform the allowed mutation.
The CRM is read again and the real outcome is recorded for recovery or audit.
If the shared customer record changes before execution, the product blocks the change and returns the proposal to that human reviewer. After execution, the deterministic workflow reads the CRM again before it claims success.
A conversational interface could collect a request, but it made state, ambiguity, and the exact mutation difficult to inspect before execution.
People needed to see matched entities, suggested notes and tasks, unresolved questions, and the precise effect of approval in one durable place.
The browser flow moved toward a server-backed preview with typed clarifications, editable and removable cards, explicit review states, and refresh-safe recovery.
The product could represent uncertainty before the write and preserve enough state to explain or reconcile the outcome afterward.
Acceptance evidence covers successful ordered execution and duplicate-approval reuse.
A successful note remains recorded when a following task fails definitively.
A timed-out task is checked against the CRM without blindly repeating the prior note or task.
The technical route traces the trust boundary, exact-payload approval, idempotent execution, external-state readback, and reconciliation paths behind the default product story.
Model output becomes structured workflow input; deterministic services retain mutation authority.
A person approves a specific payload against a known CRM state—not an open-ended instruction.
External writes can be successful, partial, unknown, or failed; the product models each state explicitly.
Readback compares requested state with authoritative external state before the workflow claims success.
Have a useful AI idea trapped in an unclear brief or brittle prototype?
Send me the rough version →