cypress.DOCS
Log inRegister
Cypress Docs
PlatformPractices

Practice: Working with Cedar

Why propose-and-confirm exists, and how to get the most out of it without slowing yourself down.

TL;DRAI summary

This chapter explains how Cedar, your AI assistant, always proposes changes like price adjustments or offer decisions for you to review and confirm. You maintain full control, ensuring Cedar only makes changes you approve.

Dive deeper:

For: Everyone

The decision

Every time Cedar wants to change something — a price, a status, an offer decision — you decide whether to let it, in the moment, with the exact change in front of you. The practice question isn't "should I trust Cedar" so much as "how do I review a proposal fast enough that Cedar is actually faster than doing it myself."

The principle

Cedar never writes without you. Reading is free — summarizing a fleet, finding stale listings, explaining an offer costs nothing and needs no review. Any change becomes a proposal card: the exact change, shown, executed only when you confirm. Declining costs nothing; an ignored proposal simply expires rather than nagging you. That asymmetry is deliberate — the fast path is reading, the deliberate path is writing, and the interface makes you feel the difference every time.

The same rule holds everywhere Cedar lives — the browser, Telegram, voice — so a confirmation typed "YES" in chat is the identical gate as the card in the app, and your role gates the action regardless of channel: Cedar proposing a launch to someone who can't launch goes nowhere. Every confirmed action is recorded with the confirming person named — a browser confirm reads as "Cedar · Maria" in the record, the same shape whichever channel it came from.

Worked example

As in the Transit's story, Orbis values Acme's 2022 Ford Transit 250 at $31,400; Maria (Acme's Fleet Manager) set the floor at $29,000, and Alex (the Cypress Manager) listed it at $32,500. When Dan at Birchwood Logistics offers $28,200 — below Maria's floor — Alex asks Cedar to "draft a fair counter for this offer." Cedar proposes $30,000 with a note about recent service records — a proposal card shows the exact number before anything is sent, Alex confirms, and the Updates feed tells Maria a counter went out, badged Cypress · on behalf, because that is what it is.

Dan counters back at $29,200, which clears Maria's $29,000 floor, and Alex accepts — the same number the Transit's story itself closes on. Cedar's part ends at the counter: proposing and sending it is what the ask "draft a fair counter" asked for, shown and confirmed before it went anywhere.

Signals to watch

  • How much of a proposal card you actually read. If you're confirming without checking the number, the card isn't slowing you down enough to be doing its job.
  • Ignored proposals. They expire rather than nagging — a pattern of proposals expiring instead of being declined usually means the original ask was vague enough that you didn't trust the result either way.
  • A proposal that surprises you — touching a vehicle or a number you didn't mean — is worth pausing on; it usually means the ask was ambiguous, not that Cedar guessed wrong.

Common mistakes

  • Treating "propose" as "already done." Nothing happens until you confirm — walking away from an open card is the same as declining, just slower to notice.
  • Asking broadly and expecting a precise write. "Clean up my stale listings" is a reading question; Cedar will ask what "clean up" should mean before it proposes anything.
  • Confirming on autopilot. The one thing the whole design assumes you'll actually do is read the card — money and legal actions always card specifically so that habit doesn't wear off.