How SLX works — and how you'll actually use it

Every task has a natural shape. SLX picks one and tells you, so the contract is always clear.

• Now (amber) — ask anything, get an answer. The conversational baseline. Use it for lookups, drafts, analyses, "what's our pipeline look like right now."
• Watchdog (green) — runs when something happens. A signal fires in a connected system (a Salesforce stage moves, an invoice goes overdue) and SLX takes the action you defined.
• Clockwork (purple) — runs on a schedule. Every Monday at 9am, the first of the month, end-of-day Friday. Same kinds of actions as a Watchdog; the trigger is time, not event.
• LiveGrid (teal) — a spreadsheet wired to live data sources. Pull from Salesforce, QuickBooks, Stripe, an uploaded CSV — keep them current, edit locally, push changes back, or send the sheet out as a PDF.

The same chat switches between primitives as the conversation evolves. Ask, then automate; pull data, then act on it.

Plan is the authoring surface behind the four primitives — the place where rules and sources are built and live. Three concepts to understand:

• App — an external system you connect once (Salesforce, QuickBooks, Stripe, Slack, DigiSigner) via OAuth.
• Source — a specific saved view of an app's data ("Closed-Won opportunities > $25k", "open invoices past due"). Define once, reuse across many rules and LiveGrids.
• Rule — "when X happens in this source, do Y." A rule becomes a Watchdog (event-driven) or Clockwork (time-driven) at runtime.

You don't have to think in app/source/rule to use SLX — most users start with a template ("Closed-Won → DigiSigner signature", "invoice overdue → Slack #finance") and the structure becomes intuitive within a session. But once you grasp it, the same source can power five rules and a LiveGrid without duplication.

SLX is model-agnostic. We run an internal evaluation pipeline that scores models on accuracy, latency, and cost for each kind of task, and route requests to whichever model is best-matched. The chat shows the routing decision (you'll see "Best-matched · ROUTED ✓") but not the model name — specific versions change too quickly to expose in the UI.

You can bring your own keys from Anthropic, OpenAI, Google, or any compatible provider. Your keys, your billing relationship, your data flowing through your contracts. SLX handles the plumbing and the prompting; you keep the model relationship.

SLX runs a pre-inference access check on every action. Before the model is even called to generate an action, the request hits a permission classifier that compares it against the scopes granted in this chat. The model can't act outside its scope because the model never sees data it wasn't allowed to see.

Three outcomes:

• Trusted scope — inside the boundary you defined, actions run automatically. Example: "send signature requests to the primary contact on Acme deals."
• Approval required — anything outside scope or above a sensitivity threshold pauses. You see what SLX wants to do, what data it'd touch, and you approve or reject. The approval is logged as a conversation-scoped permission slip — temporary, auto-expiring.
• Hard no — destructive actions (deleting records, sending to external recipients, large financial transactions) always require explicit approval. No exceptions.

Every action SLX takes shows up in the Log. Nothing happens silently, and there's no "Claude did something unexplained" failure mode.

Both let SLX use context outside the chat, but with very different relationships to the conversation.

• Materials are what you point SLX's attention at — files, links, data extracts you explicitly attached to the chat. SLX reads them deliberately for that conversation. Think of materials as the documents on the desk.
• Embeddings are SLX's long memory — your past chats, past actions, decisions you've made. SLX searches embeddings before responding so it can stay consistent across sessions ("last time you asked for pipeline by stage, you wanted Q-over-Q comparison"). You don't curate this directly; it accumulates.

Materials are session-scoped; embeddings are workspace-scoped. You can clear either at any time from settings.

If a response is close but not right, you can tune it without restarting the conversation. Sliders for depth, formality, length, evidence-density, and presets like "executive-brief" or "deep-dive." Pick what's off, drag the sliders, hit regenerate.

Under the hood, tuning rebuilds the full system prompt and runs a fresh generation on the same model. It's not a post-edit or a style filter — the model sees a new set of instructions and writes the answer from scratch. So when you tune for "shorter," you get an answer that was conceived as short, not a long one trimmed down.

Each live data source on a LiveGrid sheet can run in one of two modes — set per source, not per sheet, because trust calibrates differently for different systems:

• Auto — when the source changes, cells update on the sheet immediately. A short teal flash marks each updated cell. The full change log is reviewable in the source dropdown — you see what changed, when, and from what to what. Auto isn't "silent changes vanishing into the sheet" — it's "changes apply, and here's the receipt."
• Manual — changes don't touch the sheet. They queue as a pending count on the source chip, with an amber marker on each affected cell showing the incoming value. You open the source, accept or dismiss each change individually (or bulk), and only then does the sheet update.

QuickBooks (factual, system-of-record) typically runs Auto. Salesforce (judgment-laden, reps editing) typically runs Manual. You choose per source and can flip at any time.

An aside is a private side-channel inside a group chat. You're in a thread with three teammates discussing the Acme renewal; you and Jamie want to quickly sync on something without spamming the main thread. You open an aside with just Jamie. SLX can't see the aside; it's outside the model's context.

When you're done, you can bring context back into the main thread on your terms. Select which aside messages to surface, choose how (quote / summary / your own framing), and decide whether SLX can act on the brought-back context or just see it for awareness. The main thread gets a clearly-marked aside-card with attribution: "From the aside · brought back by You."

The point: private deliberation that doesn't leak into the main conversation by accident, with explicit control over what eventually crosses over.

We never train on your data. Period. No exceptions, no "anonymized" telemetry exfiltration, no model-improvement loops fed by your prompts. That's not the business we're in.

Your data lives in your SLX workspace with end-to-end encryption in transit and at rest. When SLX calls a language model, it sends only the context required for the task and respects your data-governance settings (zero-retention available on Enterprise, where supported by the model provider).

Connected apps stay your source of truth — SLX reads and writes through their APIs with your OAuth tokens. We never copy the underlying database, never sync your CRM into our infrastructure, never proxy your data through opaque pipelines.

And we keep an immutable audit log (SOC 2-aligned) of every request, approval, action, and read. Exportable on demand. Retained 90 days on standard plans, 3 years on enterprise.

Every answer shows the sources it pulled from. Click a citation, see the underlying record. Disagree with how the answer reads? Use Tune to rebuild it with different instructions — same model, fresh generation, no muddled in-line edits.

For automations, the Log shows every run: what fired, what SLX did, how long it took, what permissions it used, what cross-user data it touched. If a Watchdog fires wrongly, pause it from the log with one click, inspect the run detail, fix the rule, resume.

Bad answers and bad fires are still possible — that's the nature of language models and the messy data they're working with. But you'll see what went wrong, why, and have one-click ways to correct it without losing your conversation context.

Flat per-seat subscription. Two published tiers — Standard at $40/user/month and Premium at $120/user/month — and a custom Enterprise plan for orgs needing SSO, VPC deployment, or formal compliance attestations.

Per-seat, not per-action. Whether your team runs 10 Watchdogs or 10,000 in a month, the price doesn't change. We don't want SLX to feel like a meter you're afraid to push, and we don't want to be in the business of charging more for power users.

If you bring your own LLM keys, you pay the model provider directly. If you don't, inference is included in the subscription. Either way, no surprises on the invoice.

None. Subscription revenue is the entire business. SLX has no ads, runs no data sales, takes no affiliate kickbacks from connected apps. We don't recommend Salesforce over HubSpot because someone pays us to. We don't surface "sponsored" workflows.

This is a deliberate choice. The moment a product's revenue stops aligning with its users' interests, the product starts subtly working against them. SLX gets paid when teams keep using it. That's the loop we want — and it's the only one.

Cenizas Labs is the company building SLX. Small team, focused product, no investor pressure to broaden into adjacent markets just because the deck looks better that way.

We came out of the realization that most B2B software is configuration software masquerading as productivity software — you spend more time setting up the tool than getting value out of it. SLX is our answer to that.

We've filed provisional patents on three of SLX's distinguishing mechanisms: pre-inference access interception (the access check that runs before the model is called), conversation-scoped permission slips (the transient grants that expire with the chat), and full prompt reconstruction on regeneration (the rebuild-from-scratch behavior of Tune). These cover the how, not the what — anyone can build a chat-driven automation tool; what they can't easily replicate is the safety and quality architecture underneath.

What's protected as trade secret: our evaluation harness, the system prompt, and the routing classifier logic. We don't publish those. Everything customer-facing — the modes, the visual system, the templates, the integration list — is open and replicable; that's the cost of being usable.

14-day free trial on Standard and Premium, no credit card required upfront. The trial is the full product, not a feature-locked version. Connect a few apps, build a Watchdog, see if it survives contact with your real work.

If you leave: your data is yours. Every chat, source, rule, log entry, file SLX generated for you, and brought-back aside card is exportable in standard formats (JSON, CSV, Markdown). We don't make leaving harder than joining. That's not how trust works.

Fair question. The honest answer is: the roadmap is shaped by what makes existing users renew and bring in their teammates. That's a different incentive than "what makes the demo more impressive."

Renewal-driven product development tends toward reliability, predictability, and quiet usefulness — which is what SLX is optimizing for. If the four primitives feel restrained rather than feature-packed, that's why. The product gets better by getting more correct, not by getting bigger.

Teams that live in tools but want to spend less time in them. Sales ops, RevOps, customer success, finance ops, mid-market account executives. Roles where the work is mostly orchestration — pulling data from one place, deciding something, taking an action in another place — and where the orchestration eats the day.

The common shape: a small team (5–40 people) where everyone uses Salesforce or HubSpot, talks in Slack, lives in Google Sheets or Excel, and burns hours every week on workflows that are routine but not codified anywhere. Ops-minded people pick up SLX fastest because app → source → rule matches the if-this-then-that model they already think in.

We won't pretend there's no learning curve — there is one, especially around Plan (rules + sources) and LiveGrid (the live spreadsheet primitive). But it's hours, not days, for the target user. The honest hurdle is the first five minutes of clarity: figuring out what app/source/rule means, what auto vs manual sync does, what a Watchdog actually is.

Three things we built specifically to flatten that:

• Templates — every primitive's first-run screen has a template strip ("Closed-Won → signature", "Invoice overdue → Slack", "Pipeline reconciliation"). Click one, see the rule pre-built, edit it. You learn the model by reading a real example, not by reading docs.
• First-run empty states — Plan's empty state isn't "you have no rules" — it's three labeled cards showing App → Source → Rule with examples. LiveGrid's empty state isn't "no sheet yet" — it's three pillars (live data, push/pull, chat-driven) with the actual visual idioms you'll see later. The page itself teaches.
• 60-90 second video walkthroughs on first open of each primitive. Skippable. Re-runnable from the help menu.

You can use SLX productively in Now mode (the conversational baseline) from minute one. Watchdog, Clockwork, and LiveGrid are there when you need them — they don't gate the basic value.

Pipeline reconciliation, every Friday. A Clockwork watches for opportunities where Salesforce pipeline value and QuickBooks invoiced value disagree by more than $10k. It posts to the deal owner's chat with the gap, the likely cause (phased deal, discount line, late invoice), and a suggested action.

Set up once, in plain English: "every Friday at 4pm, flag deals where SF and QB differ by more than 10k and tell the owner who to chase." SLX builds the Clockwork, asks for permission to read both systems, runs from then on. Total setup time: ~3 minutes.

This used to be a 90-minute weekly task that someone forgot to do half the time. Now it runs whether anyone remembers it or not.

Renewal early-warning. A Watchdog listens for HubSpot deals with a renewal date inside 30 days where product usage has dropped more than 20% quarter-over-quarter. When both conditions hit, it pings the CSM's chat with a renewal-risk brief and a draft outreach message tuned to the specific account.

The CSM reads the brief in their morning chat, edits the draft if needed, sends it. The customer's renewal risk becomes visible before the renewal conversation, not at it.

The same source ("HubSpot deals with renewal <30d") also powers a LiveGrid the CSM lead reviews weekly — the watchlist sheet. One source, two surfaces, no duplication.

Monthly close, automated. A LiveGrid pulls invoiced revenue from QuickBooks, payments from Stripe, and bank reconciliation data from Plaid. The columns auto-refresh (QB and Stripe on Auto mode, since they're systems-of-record); the discrepancy column is a formula. The CFO opens the sheet on the 1st of each month, reviews the flagged rows (which SLX has annotated with likely causes), and signs off.

The same LiveGrid powers a Clockwork that emails the executive team a PDF of the reconciled summary on the 3rd, no manual export step. The Files section of the Log keeps every generated PDF for audit.

Cross-user access has two distinct shapes, and SLX treats them differently:

• Standing access — a Watchdog or Clockwork owned by Priya reads Ram's Salesforce on every run. This is recurring, often unattended, and shows up as RECURRING in everyone's audit log. Requires explicit approval from Ram when the automation is built, and Ram can revoke it from his Access & Permissions page at any time. Revoking pauses the automation.
• One-off chat grants — Sriram is in a chat with Jamie and grants Jamie temporary access to a specific Salesforce account for that conversation. Auto-expires when the chat is idle or after the configured window. Doesn't carry to other chats.

Every grant is in the immutable audit log. The Admin & Security page surfaces all org-wide standing grants in one view; each member sees their own grants on the Access & Permissions page.

Same product, two governance surfaces accessible from the profile menu.

• Members see "Access & permissions" — apps they've connected, Watchdogs and Clockworks reading their data, chat grants they've issued, with per-row revoke. A "Revoke everything" danger button at the bottom for nuclear-option moments.
• Admins see "Admin & security" — same personal sections, plus org-wide controls above: domain auto-approve policy (anyone signing up with @yourcompany.com gets admitted instantly), pending join requests, every cross-user grant in the org, and the audit log export.

Admins are members too — promoting someone doesn't change the layout, it adds sections above the existing ones. No re-learning.

The pattern we see most often:

• Week 1 — one person on the team signs up, connects Salesforce and Slack, runs Now-mode queries to feel out the product.
• Week 2 — they build their first Watchdog or pick a template for a workflow they own (pipeline review, lead qualification). Runs for a week without issues.
• Week 3 — they share the chat with one or two teammates, who add their own automations on top of the same connected sources.
• Week 4–5 — the team upgrades to Premium for shared chats, approval flows, and the admin console. The manager starts setting up team-level automations and a first LiveGrid.
• Month 2+ — adjacent functions (CS, finance, ops) see the impact, the admin enables domain auto-approve, and the org grows from inside.

Bottom-up. No giant rollout, no implementation phase. The product earns its place one workflow at a time.

For a typical 10-person team on Premium, after 90 days we expect:

• 15–25 Watchdogs running across the team — most of them small, specific, reliable.
• 3–5 Clockworks for recurring reports, digests, and audits.
• 1–2 LiveGrids that have become the team's source of truth for views people used to rebuild weekly in Sheets.
• 5–10 hours per person per week reclaimed from work that used to be manual orchestration.
• Zero anxiety about whether automations are running or have quietly broken — the Log surfaces health at a glance.

If we're 90 days in and none of that has shown up, something is wrong with the rollout — and your success engineer will tell you so. Honest feedback over upsell is the policy.