# Cleon

> Salesforce consultancy specializing in Marketing Cloud, Data 360, and AI Engineering. Three complete, practitioner-written documentation catalogs — direct, production-anchored, zero theater. Every page also exists in Spanish at the same path under /es/ (e.g. /es/docs/marketing-cloud/sql/select).

## Marketing Cloud
Query, scripting, configuration, and AI on Salesforce Marketing Cloud.

- [Marketing Cloud: principles from production](https://www.wearecleon.com/en/docs/marketing-cloud/marketing-cloud-principles): Thirteen principles we apply to every Marketing Cloud implementation, with concrete code and the kinds of mistakes that bite at scale. Operational, not aspirational.

### SQL
Query patterns, performance pitfalls, and the SQL we actually run against Marketing Cloud Data Extensions in production.

- [Basics — Marketing Cloud SQL fundamentals](https://www.wearecleon.com/en/docs/marketing-cloud/sql/basics): Where MC SQL lives, what Salesforce supports, and the mental model that keeps your queries from surprising you in production.
- [Debugging email sends with SQL](https://www.wearecleon.com/en/docs/marketing-cloud/sql/debugging-email-sends): When a Send went out but the numbers don't match expectations, the diagnostic flow is the same every time — audience funnel, suppression check, _Sent reconciliation, bounce/error breakdown. Five queries that find the bug fast.
- [Marketing Cloud SQL: Style Guide](https://www.wearecleon.com/en/docs/marketing-cloud/sql/style-guide): The opinionated rules Cleon applies to every MC SQL Activity we ship — naming, formatting, commenting, patterns to prefer, anti-patterns to refuse — distilled from the gotchas and reference pages into a single discipline document.
- [MC SQL gotchas: what actually fires in production](https://www.wearecleon.com/en/docs/marketing-cloud/sql/mc-sql-gotchas): Marketing Cloud SQL is a T-SQL subset, and the gaps are the part that matters. Ten gotchas we hit at scale, with the patterns we landed on after we learned the hard way.
- [Debugging value length with SQL](https://www.wearecleon.com/en/docs/marketing-cloud/sql/debugging-value-length): Silent string truncation is the bug that finds you weeks later — emails merging into the wrong subscriber, codes losing their suffix, names cut at character N. Three queries to find truncated values, audit destination DE column widths, and prevent the next one.
- [SELECT — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/select): The entry clause of every SQL Query Activity in Marketing Cloud — what it is, what Salesforce officially supports, and the production patterns that survive a hand-off.
- [Debugging All Contacts with SQL](https://www.wearecleon.com/en/docs/marketing-cloud/sql/debugging-all-contacts): Reconciling Marketing Cloud's All Contacts view against your Data Extensions — why a subscriber appears in one and not the other, status mismatches across channels, deletion-in-progress states, and the queries that surface each.
- [FROM — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/from): Where the rows come from. Data Extensions vs System Data Views, table aliases, and the production rule that protects you from views that vanish.
- [JOIN — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/join): How to combine Data Extensions in MC SQL — the four join types, the SubscriberKey type-coercion trap, anti-joins, and the staging rule that keeps performance honest.
- [WHERE — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/where): How to filter rows in MC SQL — comparison and logical operators, the IS NULL trap, NOT IN performance pitfalls, and the parentheses rule that prevents silent-precedence bugs.
- [LIKE — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/like): Pattern matching in MC SQL — wildcards, ESCAPE, case sensitivity, and the leading-wildcard performance rule that decides whether your suppression query finishes in seconds or minutes.
- [CASE — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/case): Conditional logic in MC SQL — Simple vs Searched CASE, the missing-ELSE NULL trap, type compatibility across branches, and the rule for when to stage into a lookup DE instead.
- [INSERT INTO — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/insert-into): The only write path in MC SQL — how the INSERT INTO ... SELECT wrapper works, what each target action (Overwrite / Append / Update) actually does, and the rules that prevent silent data loss.
- [String functions — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/string-functions): The string functions MC SQL supports — LEN, LEFT, RIGHT, SUBSTRING, LTRIM, RTRIM, LOWER, UPPER, REPLACE, CHARINDEX, CONCAT — plus the production rules for normalization, NULL handling, and the case-fold-kills-the-index trap.
- [Date functions — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/date-functions): The date and datetime functions MC SQL supports — GETDATE, DATEADD, DATEDIFF, DATEPART, EOMONTH — plus the timezone trap, the month-math instability, and the rule for stable date filters.
- [Numeric functions — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/numeric-functions): The numeric functions MC SQL supports — ABS, CEILING, FLOOR, ROUND, POWER, SQRT, SIGN, RAND — plus the integer-division trap, the precision/type rules for money columns, and why RAND can't be reused.
- [Conversion functions — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/conversion-functions): Type conversion in MC SQL — CAST, CONVERT, TRY_CAST, TRY_CONVERT — plus the rule for explicit casts on every join key, why TRY_* prevents whole-Activity failures, and the date-style codes worth memorizing.
- [Aggregate functions — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/aggregate-functions): The aggregate functions MC SQL supports — COUNT, SUM, AVG, MIN, MAX — plus the COUNT(*) vs COUNT(col) distinction, the SUM-returns-NULL-on-empty trap, and the MAX-per-group dedup pattern that replaces window functions in MC.
- [Null functions — Marketing Cloud SQL reference](https://www.wearecleon.com/en/docs/marketing-cloud/sql/null-functions): Handling NULL in MC SQL — ISNULL, COALESCE, NULLIF, plus the rule for picking COALESCE over ISNULL, the NULLIF division-by-zero idiom, and the difference between ISNULL the function and IS NULL the operator.

### SSJS
Server-Side JavaScript in Marketing Cloud — what works, what blows up at scale, and the patterns we reach for in CloudPages and Code Resources.

- [Basics — Marketing Cloud SSJS fundamentals](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/basics): Where SSJS runs in Marketing Cloud, what runtime you actually have (SpiderMonkey 1.7), and the two main contexts — CloudPage rendering vs Automation Script Activity — that decide the patterns you reach for.
- [Debugging stuck Script Activities](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/debugging-stuck-script-activities): When a Script Activity ran past its budget, finished without doing what it should, or reported 'Completed' while quietly skipping half the work, the diagnostic is the same. Six queries against the log DEs the script left behind that find where it died.
- [Marketing Cloud SSJS: Style Guide](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/style-guide): The opinionated rules Cleon applies to every Server-Side JavaScript block we ship in Marketing Cloud — naming, formatting, commenting, patterns to prefer, anti-patterns to refuse — distilled from the gotchas and reference pages into a single discipline document.
- [MC SSJS gotchas: what actually fires in production](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/mc-ssjs-gotchas): Server-Side JavaScript in Marketing Cloud is JavaScript the way it was in 2010 — SpiderMonkey 1.7, no modern syntax, single-threaded, with a Salesforce-specific Platform API on top. Ten gotchas Cleon hit at production scale, with the patterns that survive.
- [Debugging WSProxy auth issues](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/debugging-wsproxy-auth): The first 1,000 WSProxy calls work, then everything past minute 20 returns 'Token has expired'. Or auth fails on call one with no obvious reason. Five queries against your log DEs that separate the timeout pattern from the credentials pattern from the multi-BU pattern.
- [Platform.Function — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/platform-function): The core SSJS API namespace — Data Extension reads and writes (LookupRows, InsertData, UpdateData, UpsertData, DeleteData) plus the helpers you reach for in every script (GUID, Now, ParseJSON). What works as documented, what has silent traps, and the patterns we land on.
- [Debugging silent UpsertData duplicates](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/debugging-upsertdata-duplicates): A Script Activity ran cleanly but downstream counts are wrong. UpsertData inserted duplicates instead of updating because the destination DE's primary key is missing or misconfigured. Six queries that confirm the silent-insert pattern and walk through the recovery.
- [WSProxy — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/wsproxy): The SOAP API wrapper for SSJS — when Platform.Function isn't enough. Retrieve / Create / Update / Delete with full filter support, pagination past 2500 rows, and the auth-token refresh pattern that keeps long scripts alive.
- [String functions — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/string-functions): The string operations available in MC SSJS — native JavaScript methods (the ES5 subset SpiderMonkey 1.7 supports) plus the Platform.Function helpers for formatting and stringification. What's safe, what's missing, and what you have to polyfill.
- [Date functions — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/date-functions): Date and time handling in SSJS — Now / DateAdd / DateDiff / DatePart plus the native JavaScript Date object's ES5 methods. Same UTC trap as SQL, plus the date-part string codes you have to memorize.
- [Encoding functions — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/encoding-functions): Base64 and URL encoding in MC SSJS — the four Platform.Function helpers, when each is the right answer, and the round-trip pitfalls (whitespace, line wrapping, character set) that bite at scale.
- [Hashing functions — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/hashing-functions): SHA256, SHA1, MD5, HMAC — when each is the right answer in MC SSJS, the hex-vs-Base64 output trap, and why MD5 is still around for tracking pixels but not for anything that matters.
- [Util · Variable · Request — Marketing Cloud SSJS reference](https://www.wearecleon.com/en/docs/marketing-cloud/ssjs/util-variable-request): The bridges between SSJS and the surfaces around it — Variable for AMPscript interop, Request for CloudPage URL/form access, Platform.Function.RaiseError + GetSetting for control flow and config. The grab-bag page that ties the catalog to its neighbors.

### AMPscript
Personalization, lookups, and the AMPscript idioms that survive a hand-off. Anchored to the kinds of email logic that ship every day.

- [Basics — Marketing Cloud AMPscript fundamentals](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/basics): Where AMPscript runs in Marketing Cloud, the three syntax forms (block, inline function, field interpolation), the function categories at a glance, and the decision tree for when to reach for AMPscript vs SSJS vs SQL.
- [Debugging render-time blanks](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/debugging-render-time-blanks): An email went out, recipients see 'Hello, ' with a blank where the first name should be. The Send shows Completed. AMPscript Lookup returned NULL without throwing. Five queries against the audience DE and any log DEs that find which of the three usual culprits the bug actually is.
- [Marketing Cloud AMPscript: Style Guide](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/style-guide): The opinionated rules Cleon applies to every AMPscript block we ship in Marketing Cloud — naming, formatting, commenting, patterns to prefer, anti-patterns to refuse — distilled from the gotchas and reference pages into a single discipline document. Mirrors the SQL and SSJS Style Guides.
- [MC AMPscript gotchas: what survives a hand-off](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/mc-ampscript-gotchas): AMPscript looks like a simple template language. The reality at scale is three different variable syntaxes, three NULL checks that mean different things, a lookup API that fails silent, and a preview that doesn't render the same code path as the send. Ten gotchas anchored to the next person inheriting your email.
- [Debugging preview-vs-send mismatch](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/debugging-preview-vs-send-mismatch): The email rendered correctly in Email Studio's preview, went out, and the actual sent version is different. Six checkpoints that reproduce the divergence deterministically before the next send fires — context variables, _messagecontext gates, locale formatting, time-sensitive logic, Lookup data drift, and the only diagnostic that's truly conclusive: a real test send.
- [String functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/string-functions): The string operations available in AMPscript — every function with the inverted indexing (1-based, not 0-based), the replace-all-by-default behavior, and the small set of formatting helpers. Where it diverges from SSJS and SQL, plus the patterns Cleon ships.
- [Date functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/date-functions): AMPscript's date surface — Now / DateAdd / DateDiff / DatePart / FormatDate / DateParse. The timezone trap (MC system clock is CST regardless of where the tenant is), the month-math instability, and the patterns that survive at scale.
- [Debugging silent Cloud-write failures](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/debugging-cloud-write-failures): An AMPscript Cloud-write reported success at render time. The email shipped. Days later, the sales team notices the Salesforce records the email was supposed to update are stale. UpdateSingleSalesforceObject returned 0 silently — and 0 means seven different things. Five queries against de_log_sf_writes that separate the seven.
- [Math functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/math-functions): AMPscript's math surface — six functions, no operators, silent string-to-number coercion. Divide-by-zero behavior changes between tenants, money math has floating-point traps, and 'abc' becomes 0 without warning. The patterns that survive at scale.
- [Validation functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/validation-functions): AMPscript's validation surface — Empty / IsNull / IsEmailAddress / IsPhoneNumber / IsNumeric. Useful for render-time branching, dangerous as a substitute for upstream data quality. The patterns that survive at scale.
- [Data Extension functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/data-extension-functions): The DE read and write functions — Lookup, LookupRows, LookupOrderedRows, Row, Field, RowCount, InsertData, UpdateData, UpsertData, ClaimRow. The most safety-critical surface in the language: writes can fail silently, lookups can truncate at 2000, and a misaligned argument pair lands the wrong value in the wrong column.
- [Subscriber + Profile functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/subscriber-profile-functions): AttributeValue, _subscriberKey, _emailaddress, _jobid, _messagecontext, and the rest of the context AMPscript inherits from the surrounding send. What each returns, when it's available, and the difference between Subscriber Attributes, DE columns, and local variables.
- [Cloud-write functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/cloud-write-functions): AMPscript's bridge to Sales/Service Cloud — UpdateSingleSalesforceObject, CreateSalesforceObject, RetrieveSalesforceObjects. The highest-stakes surface in the language: writes are inline, return 1/0 without throwing, and can hit live production CRM records from a preview if you forget the messagecontext gate.
- [Encoding + Hashing functions — Marketing Cloud AMPscript reference](https://www.wearecleon.com/en/docs/marketing-cloud/ampscript/encoding-hashing-functions): URLEncode, Base64Encode/Decode, HTMLEncode, the RedirectTo tracking wrapper, plus SHA1/SHA256/SHA512/MD5 hashes and symmetric encryption. Each function pairs with a production failure shape — wrong URL escaping breaks tracking links, missing HTMLEncode opens XSS in CloudPages, MD5 used as security instead of as a tracking key.

### Configuration
Setup decisions you only get to make once: Business Units, Sender Authentication, Send Classifications, Data Extension architecture.

- [Business Unit architecture decisions](https://www.wearecleon.com/en/docs/marketing-cloud/config/business-unit-architecture): When to split a tenant into multiple Business Units, when to stay single-BU, the four common patterns (per-brand, per-region, per-product, parent+sandbox), what propagates from parent vs what's isolated, and the decision checklist before creating a new BU. Anchored to Cleon's multi-tenant rollouts and the migration costs of getting the architecture wrong.
- [MC Config gotchas: setup decisions you only get to make once](https://www.wearecleon.com/en/docs/marketing-cloud/config/mc-config-gotchas): Marketing Cloud configuration looks like a checklist — Business Units, Sender Authentication, Subscriber Key, Send Classifications, DE architecture. Setup once, never look back. The production reality is the opposite: every choice at bootstrap is something you live with for years because the surfaces depending on it make 'just change the config' a multi-week migration. Ten gotchas anchored to Cleon's multi-tenant rollouts.
- [Send Classifications — Commercial vs Transactional](https://www.wearecleon.com/en/docs/marketing-cloud/config/send-classifications): Send Classifications are how Marketing Cloud distinguishes Commercial mail (CAN-SPAM rules, unsubscribe, physical address footer) from Transactional mail (skips those). The three components — Sender Profile + Delivery Profile + CAN-SPAM Classification — bundled together. The default rules, the override rules, and the compliance cost of getting it wrong.
- [Sender Authentication Package: the setup playbook](https://www.wearecleon.com/en/docs/marketing-cloud/config/sender-authentication-package-setup): Sender Authentication Package (SAP) is the foundational MC setup that determines what a recipient sees: branded From name, custom sending domain, reply address, DKIM signature. Without it, every email comes from the generic tenant default. The setup sequence, the DNS records, the verification checks, and the failure modes that bite during a first rollout.
- [Data Extension architecture: the schema choices you live with](https://www.wearecleon.com/en/docs/marketing-cloud/config/data-extension-architecture): Every other Marketing Cloud system reads or writes Data Extensions. Get the schema right at bootstrap and the tenant operates cleanly for years; get it wrong and every SQL Activity, every AMPscript Lookup, every Journey decision-split inherits the mess. Ten production-note items on naming, primary keys, column types, retention, and the structural choices that compound.
- [Subscriber Key strategy](https://www.wearecleon.com/en/docs/marketing-cloud/config/subscriber-key-strategy): SubscriberKey is the column every other system in Marketing Cloud joins on — the identifier that defines who 'the same person' is across DEs, sends, Journeys, and CRM. The choice of what goes into it is one of the bootstrap decisions you live with for the tenant's lifetime. The decision tree, the candidate values, the patterns to prefer, the patterns to refuse, and the migration cost of getting it wrong.
- [Marketing Cloud Config: Style Guide](https://www.wearecleon.com/en/docs/marketing-cloud/config/style-guide): The opinionated rules Cleon applies to every Marketing Cloud config decision — naming, documentation, runbook discipline, patterns to prefer, anti-patterns to refuse — distilled from the Config catalog into a single discipline document. Mirrors the SQL, SSJS, and AMPscript Style Guides; closes the catalog at 7 page-pairs.

### AI
Einstein for Marketing Cloud, Agentforce, and calling external LLMs from CloudPages — what each AI surface is actually good for, where they bite in production, and the decision of when to reach for Agentforce versus an external model.

- [Marketing Cloud AI gotchas: where Einstein, Agentforce, and external models bite](https://www.wearecleon.com/en/docs/marketing-cloud/ai/mc-ai-gotchas): AI in Marketing Cloud arrives as three different things — Einstein features baked into the platform, Agentforce reaching in from the Salesforce side, and external LLMs you call yourself from CloudPages or SSJS. Each fails differently. Ten gotchas across the three, each with the question to answer before you ship and the cost of getting it wrong.
- [Einstein for Marketing Cloud — reference](https://www.wearecleon.com/en/docs/marketing-cloud/ai/einstein-for-marketing-cloud): The Einstein features baked into Marketing Cloud Engagement — Engagement Scoring, Send Time Optimization, Content Selection, Copy Insights — what each predicts, the data each needs to be trustworthy, and the production caveat for each. The AI that's already in the platform before you call anything external.
- [Agentforce and Marketing Cloud — reference](https://www.wearecleon.com/en/docs/marketing-cloud/ai/agentforce-and-marketing-cloud): What Agentforce is, how it relates to Marketing Cloud, and why its usefulness for marketing is decided by the Data Cloud model underneath it. The agent layer — what it can do, what it reads, and the guardrails an agent that can act needs.
- [Calling external AI from CloudPages and SSJS — how-to](https://www.wearecleon.com/en/docs/marketing-cloud/ai/external-ai-from-cloudpages): The pattern for calling an external LLM from Marketing Cloud — where the call belongs (ahead of time, not at render time), how to handle auth and failure, and the data, latency, and cost guardrails that keep it from breaking a page or a budget. The how-to, with the gotchas built in.
- [Marketing Cloud AI: Style Guide](https://www.wearecleon.com/en/docs/marketing-cloud/ai/style-guide): The opinionated rules Cleon applies to AI in Marketing Cloud — when to reach for Einstein, Agentforce, or an external model, the guardrails each one needs, and the 'Agentforce vs external AI' decision in full. The discipline document that ties the AI subcategory together.
- [Debugging AI personalization — how-to](https://www.wearecleon.com/en/docs/marketing-cloud/ai/debugging-ai-personalization): An Einstein score looks wrong, a generated copy field is blank, or an agent answers confidently and incorrectly. The diagnostic is always the same: figure out which surface produced the value, then walk down to the layer where it actually breaks. The AI-personalization debugging playbook.

## Data 360
The Salesforce Data 360 (formerly Data Cloud) lifecycle: ingest, model, resolve identity, query, segment, and activate.

- [Data 360: principles from production](https://www.wearecleon.com/en/docs/data-cloud/data-cloud-principles): The principles Cleon applies to every Data 360 build — model first, identity as a business decision, freshness as a feature, agent-ready as a property of the model. A synthesis of official guidance, community practice, and production experience.

### Data Architecture
The data model decisions you live with for years: DLOs, DMOs, mapping, data spaces, relationships, keys. The architecture every other Data 360 surface — and every agent grounded on it — depends on.

- [Data 360 architecture gotchas: the model decisions that outlast everything](https://www.wearecleon.com/en/docs/data-cloud/data-model/data-architecture-gotchas): The Data 360 data model looks like a setup wizard — connect a stream, map a few fields, done. The production reality is the opposite: the model is the one decision every segment, Calculated Insight, activation, and grounded agent inherits, and it's hardest to change after data is flowing. Ten model-architecture choices that bite, each with the question to answer first and the cost of getting it wrong.
- [Data Lake Objects (DLOs) — Data 360 reference](https://www.wearecleon.com/en/docs/data-cloud/data-model/data-lake-objects): The raw landing layer of Data 360: what a Data Lake Object is, how Data Streams create them, and why you map them to DMOs instead of building business logic against them directly.
- [Data Model Objects (DMOs) — Data 360 reference](https://www.wearecleon.com/en/docs/data-cloud/data-model/data-model-objects): The harmonized layer of Data 360: standard vs custom DMOs, the Customer 360 data model, and why mapping to standard objects buys you semantics that segmentation, identity resolution, and agents already understand.
- [Mapping DLOs to DMOs — Data 360 how-to](https://www.wearecleon.com/en/docs/data-cloud/data-model/mapping): How meaning gets assigned in Data 360: the flow from Data Lake Object fields to Data Model Object attributes, the transformations available on the way, and the mapping mistakes that produce silent wrong data downstream.
- [Data spaces — Data 360 reference](https://www.wearecleon.com/en/docs/data-cloud/data-model/data-spaces): Data spaces partition a Data 360 org for a real boundary — brand, region, regulatory regime. What's isolated, what's shared, and why the partition is a wall you build once.
- [Relationships & keys — Data 360 reference](https://www.wearecleon.com/en/docs/data-cloud/data-model/relationships-and-keys): Primary keys and relationships in the Data 360 model: what makes a row unique, how DMOs connect, and why an unmodeled relationship is a join your segments and insights silently can't make.
- [Data 360 Data Architecture: Style Guide](https://www.wearecleon.com/en/docs/data-cloud/data-model/style-guide): The opinionated rules Cleon applies to every Data 360 model decision — naming, modeling, documentation, the patterns to prefer and the ones to refuse — plus the agent-readiness check that decides whether the model can ground an agent. The discipline document that ties the Data Architecture subcategory together.
- [Debugging mapping failures — Data 360 how-to](https://www.wearecleon.com/en/docs/data-cloud/data-model/debugging-mapping): A DMO attribute lands blank, or wrong, or a record won't unify. The diagnostic flow is the same every time — walk from the DLO up to the DMO and find the layer where the value breaks. The mapping debugging playbook.

### Ingestion
Getting data in: Data Streams, connectors (CRM, Marketing Cloud, S3, web/mobile SDK), the Ingestion API, and refresh modes — full vs incremental and when each one bites.

- [Data streams: the unit of ingestion](https://www.wearecleon.com/en/docs/data-cloud/ingestion/data-streams): What a Data Stream is: the configured source-to-Data 360 connection that lands a DLO. The stream category — Profile, Engagement, or Other — and what it constrains downstream, the refresh schedule, and where ingestion ends and modeling begins.
- [Connectors: where Data 360 ingests from](https://www.wearecleon.com/en/docs/data-cloud/ingestion/connectors): The sources a Data Stream ingests from and what each is for — Salesforce CRM, Marketing Cloud, Amazon S3, Google Cloud Storage and Microsoft Azure Storage, the Web/Mobile SDK, the Ingestion API, MuleSoft, and zero-copy over Snowflake, BigQuery, and Databricks. Each one's batch-versus-streaming nature, and why the available set is something you verify in the org, not memorize from a page.
- [The Ingestion API: streaming vs bulk](https://www.wearecleon.com/en/docs/data-cloud/ingestion/ingestion-api): Programmatic ingestion for when no packaged connector fits: the Ingestion API's two patterns — Streaming (small near-real-time asynchronous payloads) and Bulk (large file/CSV uploads) — when each fits, when to reach for the API instead of a connector, and the up-front requirement that a source and schema be defined before you send a single record.
- [Refresh modes: full refresh vs upsert](https://www.wearecleon.com/en/docs/data-cloud/ingestion/refresh-modes): The refresh mode of a Data Stream decides how each run reconciles against what's already landed. Full refresh replaces the whole dataset every run and captures deletes by absence; upsert inserts-or-updates keyed on a primary key — lighter and incremental, but a wrong or non-unique key silently duplicates or overwrites, and it does not remove deleted source records unless you explicitly send deletes.
- [Ingestion and the lifecycle: what every downstream layer inherits](https://www.wearecleon.com/en/docs/data-cloud/ingestion/ingestion-and-the-lifecycle): Ingestion is the front of the Data 360 lifecycle, and every later layer inherits whatever you landed. The DLO-to-DMO handoff, and how ingestion freshness and correctness feed identity resolution, query, segmentation, and agent-readiness — a stale or wrongly-keyed ingest surfaces as a downstream bug three layers away.
- [Ingestion gotchas: the silent failures at the front of the pipeline](https://www.wearecleon.com/en/docs/data-cloud/ingestion/ingestion-gotchas): The ingestion failures that don't throw an error. An upsert keeps deleted source records because nothing told it they left; a full refresh on a huge source bills like a cost decision nobody made; a non-unique key overwrites a record; a daily cadence sits behind a real-time decision; event data lands as a Profile stream and the time series never exists; a DLO bloats because nobody reconciles ingest against use; a connector quietly loses auth and looks like a source with no data. Seven gotchas, each as the instinct, what actually happens in production, and the fix.
- [Debugging ingestion: when the data didn't land the way you expected](https://www.wearecleon.com/en/docs/data-cloud/ingestion/debugging-ingestion): A Data Stream landed wrong and nothing errored. The diagnostic is ordered — confirm the run even happened, then read what it did to the row counts, because almost every ingestion bug is a refresh that didn't run, a full-vs-upsert confusion, a primary-key problem, or the upsert-no-delete behavior. Check the schedule and connector auth, count the DLO before and after, and verify the refresh actually landed. The ingestion debugging playbook.
- [Data 360 Ingestion: Style Guide](https://www.wearecleon.com/en/docs/data-cloud/ingestion/style-guide): The opinionated rules Cleon applies to every Data 360 ingestion decision — the streaming-vs-scheduled-batch call decided by the freshest downstream decision, the full-refresh-vs-upsert call decided by a named key and an explicit delete story, the cadence and cost discipline, the patterns to prefer and the ones to refuse, plus a pre-ship checklist for any new Data Stream. The discipline document that ties the Ingestion subcategory together.

### Identity Resolution
Match and reconciliation rules, the unified individual, and the difference between a profile that resolves cleanly and one that silently merges two customers into one.

- [The unified individual: how Data 360 resolves many profiles into one](https://www.wearecleon.com/en/docs/data-cloud/identity/the-unified-individual): What identity resolution produces: the unified individual. UnifiedIndividual__dlm vs the source ssot__Individual__dlm, the IndividualIdentityLink__dlm bridge that maps source to unified, why source-to-unified traversal always goes through that link and never a direct join, and why counting the wrong object silently breaks every metric downstream.
- [Match rules: when Data 360 calls two records the same person](https://www.wearecleon.com/en/docs/data-cloud/identity/match-rules): How Data 360 decides two source records are the same person: match rulesets, individual match rules, exact match (email / phone / party ID) vs fuzzy match (name), and how criteria combine as an OR of AND-groups. What running matching reprocesses, and why loose rules and strict rules both fail silently.
- [Reconciliation rules: which value wins in the unified profile](https://www.wearecleon.com/en/docs/data-cloud/identity/reconciliation-rules): Once match rules have grouped source records into one person, reconciliation rules decide which attribute value wins in UnifiedIndividual__dlm — per attribute. Most Recent, Most Frequent, Source Priority, Last Updated: what each does, when to prefer a ranked source list over recency, and why this is the email and address activation actually sends to.
- [Match keys and normalization: what you resolve identity on](https://www.wearecleon.com/en/docs/data-cloud/identity/match-keys-and-normalization): What identity resolution actually compares: the DMOs and fields that serve as match keys — party identification, contact-point email and phone, individual name and date of birth — and the normalization that runs first. What makes a key strong and stable versus fragile, and why an unnormalized key fails silently.
- [Unified identity downstream: what every other surface inherits](https://www.wearecleon.com/en/docs/data-cloud/identity/unified-identity-downstream): How resolved identity feeds everything else — and why everything else silently depends on it. Counting UnifiedIndividual__dlm vs the source ssot__Individual__dlm in Query, identity as the grain under Calculated Insights and Segmentation membership, activation keyed on the unified individual, and why a coherent unified profile is the prerequisite for an agent to answer about a customer (principle 10).
- [Identity resolution gotchas: the silent failures](https://www.wearecleon.com/en/docs/data-cloud/identity/identity-resolution-gotchas): The identity resolution failures that don't throw an error. Over-merge leaks one customer's data to another; over-split fragments one person into many; a direct source-to-unified join returns a wrong mapping; the wrong reconciliation winner sends mail to a stale address; a rule change silently reprocesses the whole org and shifts every count. Seven gotchas, each as the instinct, what actually happens in production, and the fix.
- [Debugging identity resolution: is it over-merge or over-split?](https://www.wearecleon.com/en/docs/data-cloud/identity/debugging-identity-resolution): A profile resolved wrong and nothing errored. The first question is always the same — is it over-merge (two people fused into one unified individual) or over-split (one person fragmented across several)? Inspect IndividualIdentityLink__dlm to name the failure, find which match criterion fired, validate normalization on the suspect keys, then verify a rule-change reprocessing actually landed. The identity-resolution debugging playbook.
- [Data 360 Identity Resolution: Style Guide](https://www.wearecleon.com/en/docs/data-cloud/identity/style-guide): The opinionated rules Cleon applies to every identity resolution decision in Data 360 — one question at the center, how strict should the match be, framed by the asymmetric cost of a false merge versus a false split, the strength of the key you resolve on, and whether the business signed off against real data with reprocessing budgeted. Patterns to prefer, patterns to refuse, the agent-readiness check, and a pre-ship checklist before any ruleset change ships. The discipline document that ties the Identity Resolution subcategory together.

### Segmentation & Activation
Building segments that hold up, activating them where they do work — including back into Marketing Cloud Journeys — and the data actions that make activation real-time.

- [Segmentation & activation gotchas: where a segment stops being potential energy](https://www.wearecleon.com/en/docs/data-cloud/segmentation/segmentation-activation-gotchas): A Data 360 segment is potential energy until it activates — and the central decision is batch publish versus real-time data action. Ten segmentation and activation gotchas, each with the question to answer first and the cost of getting it wrong. Two threads run through all of them: consent at the activation boundary, and the bridge from a Data 360 segment to a Marketing Cloud Journey.
- [Building a segment: the membership rules before it activates anywhere](https://www.wearecleon.com/en/docs/data-cloud/segmentation/building-segments): How a Data 360 segment is built: the object you segment on (typically the unified individual), the container-based AND/OR rules that define membership, filtering on Calculated Insights and related-object attributes, and the refresh cadence that decides how fresh the membership is. Building the audience only — where it activates is a sibling page.
- [Activation targets: where a Data 360 segment goes, and what travels with it](https://www.wearecleon.com/en/docs/data-cloud/segmentation/activation-targets): A segment is potential energy until it activates somewhere it does work. This is the target decision: what an activation target is, the destination types Data 360 supports, and the activation object plus attributes that decide what data actually rides along to the channel.
- [Batch vs. real-time activation: scheduled segment publish or a real-time data action](https://www.wearecleon.com/en/docs/data-cloud/segmentation/batch-vs-realtime-activation): The decision the whole subcategory turns on: a scheduled segment publish recomputes a whole audience on a cadence and ships it to an activation target; a real-time data action fires off a single data change as it happens. One answers 'who, as of the last run'; the other answers 'react now to this one change'. The two mechanisms, their real limits, and how to tell which one a requirement actually needs — the exact parallel to the query layer's Calculated-Insight-vs-live-Query call.
- [Activating into Marketing Cloud: the bridge that connects the two platforms most clients run](https://www.wearecleon.com/en/docs/data-cloud/segmentation/activating-into-marketing-cloud): Cleon's signature bridge: a Data 360 segment activating into Marketing Cloud Engagement so a Journey can act on it. There is no direct segment-to-Journey pipe — the handoff is a shared, sendable Data Extension. The data flow, the two clocks that govern it, the contact point it keys on, and the attributes that ride along carrying their own freshness.
- [Consent and activation: making the opt-out physically un-activatable](https://www.wearecleon.com/en/docs/data-cloud/segmentation/consent-and-activation): Segment logic is consent-blind: a segment built on behavior will include a person who opted out, and the activation will send them — unless consent is enforced at the activation boundary. This is where it gets enforced: Contact Point Filtering, backed by the Contact Point Consent DMO, filtering on consent status and data-use purpose so a non-consenting person is excluded from what ships. Cleon's stance is compliance by design — model consent alongside the data and make the safe path the only path.
- [Debugging activation — Data 360 how-to](https://www.wearecleon.com/en/docs/data-cloud/segmentation/debugging-activation): The audience didn't arrive, arrived wrong, arrived stale, or included someone it shouldn't. The diagnostic is always the same shape — pick the layer the symptom points to, then walk down from membership to arrival and find the first one that's broken. The segmentation and activation debugging playbook.
- [Data 360 Segmentation & Activation: Style Guide](https://www.wearecleon.com/en/docs/data-cloud/segmentation/style-guide): The opinionated rules Cleon applies to every Data 360 activation decision — the batch publish vs. real-time data action call at the center, the target discipline, the cost and freshness discipline, consent enforced at the boundary, the patterns to prefer and the ones to refuse, plus a pre-ship checklist for any segment or activation. The discipline document that ties the Segmentation & Activation subcategory together.

### Query & Insights
Data 360's SQL dialect, Calculated Insights, and the Query API. The bridge from the SQL you already write in Marketing Cloud to the queries that run over the unified data model.

- [Data 360 query gotchas: where the SQL instinct misleads](https://www.wearecleon.com/en/docs/data-cloud/query/query-insights-gotchas): Data 360's query surfaces look like the SQL you already write in Marketing Cloud — and that resemblance is the trap. Ten gotchas across the dialect, Calculated Insights, and the Query API, each with the question to answer first and the cost of getting it wrong.
- [Data Cloud SQL: the dialect you query the unified profile with](https://www.wearecleon.com/en/docs/data-cloud/query/data-cloud-sql): What Data Cloud SQL is: an ANSI-compliant dialect you run in the Query Editor and the Query API over DMOs, DLOs, and Calculated Insight Objects — the unified profile, not flat Data Extensions. The naming rules, the clause behavior, and what carries over from Marketing Cloud SQL.
- [Bridging from Marketing Cloud SQL: a crosswalk to Data 360's query surfaces](https://www.wearecleon.com/en/docs/data-cloud/query/bridging-from-marketing-cloud-sql): A practitioner's crosswalk for the Marketing Cloud SQL veteran: each MC SQL pattern you already know, its Data 360 equivalent, and where the instinct quietly misleads. Assumes the dialect — links to it rather than re-documenting it.
- [Calculated Insights: the metric you compute once and retrieve everywhere](https://www.wearecleon.com/en/docs/data-cloud/query/calculated-insights): What a Calculated Insight is: an aggregation defined by dimensions and measures — not an arbitrary SELECT — pre-computed once and served everywhere as a queryable Calculated Insight Object. Batch vs streaming, the real limits of each, the freshness that makes the result trustworthy or silently wrong, and the separate SQL dialect you author it in.
- [The Data 360 Query API: running SQL over the model from code](https://www.wearecleon.com/en/docs/data-cloud/query/query-api): The programmatic side of Data Cloud SQL: run a live query over the unified model from code and get rows back. The two surfaces — the synchronous Query API v2 with its nextBatchId cursor, and the newer asynchronous Query Connect API with a queryId and offset paging — the auth flow at a high level, the time constraints Salesforce enforces, and when a live query beats a Calculated Insight.
- [Consuming query results: who reads a Calculated Insight, and why they all read the same one](https://www.wearecleon.com/en/docs/data-cloud/query/consuming-query-results): The retrieve-many half of compute-once-retrieve-many, made explicit. Where a Calculated Insight goes after it's computed — segments, activations, agents, analytics — and why every consumer inheriting the same grain and freshness is the point, not an accident.
- [Debugging query results — Data 360 how-to](https://www.wearecleon.com/en/docs/data-cloud/query/debugging-query-results): A number came back wrong, blank, or stale from a Data 360 query or Calculated Insight. The diagnostic is always the same — walk down the layers from the model to the query and find the first one that's broken. The query-results debugging playbook.
- [Data 360 Query & Insights: Style Guide](https://www.wearecleon.com/en/docs/data-cloud/query/style-guide): The opinionated rules Cleon applies to every Data 360 query decision — the Calculated Insight vs. live Query call at the center, the SQL conventions, the cost and freshness discipline, the patterns to prefer and the ones to refuse, plus the agent-readiness check and a pre-ship checklist. The discipline document that ties the Query & Insights subcategory together.

## AI Engineering
Engineering production-grade AI: agents, grounding, prompting, evaluation, and governance — across Agentforce and the off-platform stack.

- [AI Engineering: principles from production](https://www.wearecleon.com/en/docs/ai-automation/ai-automation-principles): The principles Cleon applies to every AI build — ground before you generate, evaluate before you ship, govern every action, and never confuse a demo with a product. The discipline that turns a capable model into a system that survives Monday morning.

### Agents & Orchestration
Building agents that ship, not demo: anatomy, orchestration patterns (single-loop to LangGraph graphs), tools and actions, and the production discipline — composed across Agentforce, LangGraph, Claude, and MCP.

- [Agent gotchas: how a demo dies in production](https://www.wearecleon.com/en/docs/ai-automation/agents/agents-gotchas): An AI agent demo is a magic trick: scripted inputs, a friendly path, an audience that wants to believe. A production agent is an engineering problem — reliable on inputs nobody wrote, bounded in cost, governed on every action, accountable to a human. Ten gotchas that kill agents after the demo, each with the question to answer first and the cost of getting it wrong.
- [What is an agent? The anatomy of a system that decides](https://www.wearecleon.com/en/docs/ai-automation/agents/what-is-an-agent): What an agent actually is, part by part: a model, instructions, tools, memory, and a control loop that runs perceive → reason → act → observe. How an agent differs from a workflow, a chain, and a single prompt — not as rivals, but as different shapes for different jobs — and the honest test for when you need an agent at all: only when the path can't be enumerated ahead of time. Establishes the vocabulary the rest of this subcategory uses.
- [Orchestration patterns: from a single loop to a graph](https://www.wearecleon.com/en/docs/ai-automation/agents/orchestration-patterns): The agent orchestration patterns that actually hold in production — the single-agent ReAct loop, supervisor/worker, multi-agent collaboration, graph-based state machines, and routing/handoff — each with where it fits and its cost, latency, and reliability trade-off. Plus the honest warning that every agent you add is failure surface you now own, and where Agentforce's Atlas Reasoning Engine sits as the managed-reasoning instrument.
- [Tools and actions: giving an agent the ability to act](https://www.wearecleon.com/en/docs/ai-automation/agents/tools-and-actions): How an agent acts: tool (function) calling, where the tool name, description, and typed schema are the interface the model reasons over. Designing safe tools — least privilege, argument validation, idempotency, and an approval gate plus kill switch on consequential actions. Agentforce Actions (Flow, Apex, Prompt Template) inside the platform security model, and MCP as the open protocol for connecting models to tools across systems. Composed, not ranked.
- [Agentforce agents: the platform-native path](https://www.wearecleon.com/en/docs/ai-automation/agents/agentforce-agents): The Salesforce-native path as one instrument in the kit — the right one when the work lives in the security model and needs governed, auditable actions on customer data (principle 7). How an Agentforce agent is assembled: Topics that scope the jobs, Instructions that steer behavior, the managed Atlas Reasoning Engine that plans over them, Actions that act, grounding through Data 360, and the Einstein Trust Layer doing the governance. What you own and what the platform owns — and where the work hands off to an external agent.
- [External agents: LangGraph, Claude, and the loop you own](https://www.wearecleon.com/en/docs/ai-automation/agents/external-agents): The off-platform path as one composable instrument — LangGraph for orchestration, the Claude API for the reasoning core, MCP for tool interop — and the thing that defines it: when you go external, you own the control loop, the state, the grounding, the security model, the governance, and the audit that Agentforce hands you for free. The right call when the work is off-platform, spans models, or needs a capability Salesforce does not reach — and complementary to the platform path, not a rival to it.
- [Agent Style Guide: the bar an agent clears before it ships](https://www.wearecleon.com/en/docs/ai-automation/agents/style-guide): The opinionated rules Cleon applies to every agent — the first decision (agent, workflow, or single prompt), the production checklist an agent clears before it ships, and how we compose Agentforce, LangGraph, Claude, and MCP to the job rather than pick a camp. The discipline document that turns the gotchas into a gate and the principles into practice.
- [Debugging agents: tracing a run when it goes wrong](https://www.wearecleon.com/en/docs/ai-automation/agents/debugging-agents): An agent failed in production and you have to fix it. The move that makes that possible is the one most teams skip: trace first, theorize second — you cannot fix what you cannot replay. The symptom-driven playbook for five ways an agent goes wrong — runaway loops, wrong-tool calls, confident-wrong answers, silent degrade, slow and expensive — each with what to read in the trace, the fix, and the eval case that stops it coming back.

### Grounding & Retrieval
Connecting models to your knowledge: RAG done right — chunking, embeddings, retrieval quality — across Agentforce retrievers over Data 360 and external vector stores. The foundation an agent’s answers stand on.

- [Grounding gotchas: how RAG fails in production](https://www.wearecleon.com/en/docs/ai-automation/grounding/grounding-gotchas): A RAG demo retrieves the one document you tested, on the one question you asked. Production retrieves from everything you have, on questions nobody scripted — and the wrong chunk is a confident wrong answer. Ten gotchas that kill grounding after the demo, each with the question to answer first and the cost of getting it wrong.
- [What is grounding? The retrieval pipeline an answer stands on](https://www.wearecleon.com/en/docs/ai-automation/grounding/what-is-grounding): Grounding is feeding the model real retrieved facts instead of letting it answer from training — and RAG, retrieval-augmented generation, is how it's built. The pipeline end to end: chunk → embed → store → retrieve → augment → generate, each stage in a sentence. The vocabulary the rest of this subcategory uses — chunk, embedding, vector store, semantic search, hybrid search, top-k, re-ranking — and the honest test for when you need retrieval at all: only when the answer lives in data the model wasn't trained on or that changes. Principle 2: ground before you generate.
- [Chunking and embeddings: the inputs retrieval quality depends on](https://www.wearecleon.com/en/docs/ai-automation/grounding/chunking-and-embeddings): The two upstream levers retrieval quality stands on: chunking and embeddings. How you split a document — fixed-size, structural, semantic — and the chunk-size and overlap trade-offs that either preserve or destroy meaning, including Anthropic's Contextual Retrieval. What an embedding is, why the embedding model is a real choice (dimension, cost, latency, domain fit), and why query and document must share one model. Anthropic ships no first-party embedding model — you pair Claude with a provider. Get these wrong and no retrieval tuning saves you.
- [Retrieval quality: measuring and improving what the model gets](https://www.wearecleon.com/en/docs/ai-automation/grounding/retrieval-quality): Retrieval quality is a separate thing from answer quality, and you have to measure it on its own. This page splits the two — how to score whether the right chunk came back at all and how high it ranked, with a small retrieval eval set built query-to-chunk — then walks the levers that improve it: hybrid search, re-ranking, metadata filtering, query rewriting, and chunk/k tuning, each with where it fits and what it costs. The throughline: a grounded system is only as good as its retrieval, and retrieval is only trustworthy once it's measured.
- [Agentforce retrievers: grounding inside the Salesforce platform](https://www.wearecleon.com/en/docs/ai-automation/grounding/agentforce-retrievers): The platform-native grounding path: a retriever wraps an Einstein Search operation and bridges a search index to your Prompt Templates and Flow, so an Agentforce agent answers over Data 360 instead of guessing. How it is assembled — Data 360's auto-created retriever per index versus a custom one in Einstein Studio, vector and hybrid search index types, no-code retrievers for admins versus custom for control, ensemble retrievers across sources — and the part that earns the platform its place: retrieval runs inside the Salesforce security model, honoring the running user's permissions by construction. The complementary line to an external RAG pipeline (principle 7), and the clean Data 360 model that has to come first.
- [External RAG: the grounding pipeline you own](https://www.wearecleon.com/en/docs/ai-automation/grounding/external-rag): The off-platform grounding path as a pipeline you build stage by stage — LangChain to orchestrate it, a vector store you run, an embeddings provider paired with Claude, and the Claude API for generation. The thing that defines it: when the corpus lives outside Salesforce, you own the chunking, the index, the retrieval tuning, the permission filter, the freshness contract, and the eval set that Agentforce retrievers hand you for free. The right call when the data and the work are off-platform — and complementary to the platform path, not a rival to it.
- [Debugging grounding: tracing a bad answer to its retrieval](https://www.wearecleon.com/en/docs/ai-automation/grounding/debugging-grounding): A grounded answer came back wrong and you have to fix it. The move that makes that possible is the one most teams skip: pull the chunks retrieval actually returned before you touch the prompt — you cannot fix what you cannot see. The symptom-driven playbook for five ways grounding goes wrong — confidently wrong, recall miss, ranked-low, stale, wrong-user chunk — each with what to inspect, the fix, and the retrieval eval case that stops it coming back.
- [Grounding Style Guide: the bar retrieval clears before it ships](https://www.wearecleon.com/en/docs/ai-automation/grounding/style-guide): The opinionated rules Cleon applies to every grounded system — the first decision (do you even need retrieval), the retrieval-quality bar a pipeline clears before it ships, and how we compose Agentforce retrievers and external RAG by where the data lives rather than pick a camp. The discipline document that turns the grounding gotchas into a gate and the principles into practice, scoring retrieval before anyone touches the prompt.

### Prompting & Context Engineering
Steering models reliably: system prompts, instructions, context windows, structured output, and prompt caching. The craft that turns a capable model into a dependable component.

- [Prompting gotchas: how a prompt breaks in production](https://www.wearecleon.com/en/docs/ai-automation/prompting/prompting-gotchas): A prompt that works in the playground works on the input you typed, on the model you typed it into, on a path you walked yourself. Production runs it on inputs nobody scripted, with untrusted text in the window, against a model version that shifts under you — and a prompt failure looks like a confident answer, not an error. Ten gotchas that break a prompt after the demo, each with the question to answer first and the cost of getting it wrong.
- [What is context engineering? Everything the model sees before it answers](https://www.wearecleon.com/en/docs/ai-automation/prompting/what-is-context-engineering): Context engineering is the shift from writing a prompt to deciding everything that fills the context window for a given call — the system prompt, instructions, examples, retrieved facts, history, tool definitions, and the user input, all competing for one finite budget. The reframe: a model only ever sees its window, so the window is the real unit of control. Why most 'the model got it wrong' problems are context problems, not model problems. And the vocabulary the rest of this subcategory uses. Principle 10: context is a budget, not a bucket.
- [System prompts and instructions: steering the model on purpose](https://www.wearecleon.com/en/docs/ai-automation/prompting/system-prompts-and-instructions): The steering part of the context, written on purpose: system-prompt anatomy — role, task, boundaries, output format — and why system content sets a stronger foundation than the user turn. The techniques that actually hold: be clear and direct, give the model the why behind a rule, show worked examples (few-shot), let it reason out loud for multi-step work, and decompose a too-big task into a chain. Stated honestly: a model cannot think privately, so reasoning only helps if it is allowed to output it. Every change scored against an eval set (principle 3) — structure and ordering beat volume.
- [Structured output: when you need JSON, not prose](https://www.wearecleon.com/en/docs/ai-automation/prompting/structured-output): When the model's output feeds a system instead of a human, the shape is a contract — and parsing prose for it is the fragile bet that breaks on the first input you didn't try. The reliable paths in order of strength: Structured Outputs for guaranteed schema compliance, tool calling for typed arguments, and a precise format spec in the system prompt for flexibility. Prefill is not the technique — it is unsupported on newer Claude models. Whatever the path, validate every output before you use it and have a deterministic fallback when validation fails.
- [Context windows: the token budget every call spends](https://www.wearecleon.com/en/docs/ai-automation/prompting/context-windows): The context window is every token the model can reference for a call — including its own response — and it is two things at once: finite and ordered. This is the operational depth under context engineering: the window is one budget that the system prompt, instructions, examples, retrieved facts, history, tool definitions, and user input all draw from, so more is not better; and it is ordered, so a key fact stranded in the middle gets under-weighted. How to manage a window that grows, why a million-token ceiling is still not a license to fill it, and the levers — summarize, drop, retrieve on demand, server-side compaction — that keep it honest. Principle 10: context is a budget, not a bucket.
- [Prompt caching: stop re-paying for the same prefix](https://www.wearecleon.com/en/docs/ai-automation/prompting/prompt-caching): The large static preamble — system prompt, tool defs, examples, a long grounding doc — re-sent on every call gets re-processed every time, and at production volume that is a bill nobody approved. Prompt caching fixes it: mark a stable prefix with cache_control and later calls reuse the model's processing instead of re-paying for it. The mechanic — caching runs in order over tools, then system, then messages, up to and including the marked block, with up to 4 breakpoints, automatic or explicit. The economics stated honestly: a cache read costs about 0.1x a base input token while a cache write costs more than one, so caching wins on a reused prefix and can lose on a one-shot call. And the design rule that makes it pay — stable content first, the variable input last.
- [Debugging prompts: isolate the variable, then fix](https://www.wearecleon.com/en/docs/ai-automation/prompting/debugging-prompts): A prompt misbehaved and you have to fix it. The move that makes that possible is the one most teams skip: change one thing at a time and score it against an eval set — do not rewrite the whole prompt and hope. A prompt is non-deterministic, so 'it looks better on one try' proves nothing. The symptom-driven playbook for five ways a prompt goes wrong — ignored instruction, broken format, run-to-run drift, model-change degrade, edge-case miss — each with what to inspect, the fix, and the eval case that stops it coming back.
- [Prompting Style Guide: the bar a prompt clears before it ships](https://www.wearecleon.com/en/docs/ai-automation/prompting/style-guide): The opinionated rules Cleon applies to every prompt — the first decision (prompt, ground, or fine-tune), the prompt-quality bar a prompt clears before it ships, and how we compose Agentforce Prompt Templates and the Claude API by where the prompt runs rather than pick a camp. The discipline document that turns the prompting gotchas into a gate and the principles into practice, treating the prompt as engineered context, not a string you tweak by feel.

### Evaluation & Observability
Knowing it works — and stays working: evals, test sets, LLM-as-judge, tracing, regression, and the monitoring that catches a silent degrade before a customer does.

- [Evaluation gotchas: how a measurement lies to you](https://www.wearecleon.com/en/docs/ai-automation/evaluation/evaluation-gotchas): An eval is supposed to be the one thing in an AI system you can trust — the number that tells you the prompt got better, the agent didn't regress, the new model is safe to ship. But an eval can lie: it can measure memorization instead of capability, optimize a number while losing the goal, score with a biased judge, or pass offline and fail live. Ten gotchas that make a measurement look like proof when it isn't, each with the question to answer first and the cost of trusting the wrong number.
- [What is evaluation? Measuring whether the system works, instead of hoping](https://www.wearecleon.com/en/docs/ai-automation/evaluation/what-is-evaluation): Evaluation is the discipline of measuring whether an AI system does its job — replacing 'it looked good in three tries' with a number you can score, compare, and defend. The eval loop: define success criteria, build an eval set, grade, iterate. Offline evaluation before you ship versus online evaluation on live traffic. The vocabulary the rest of this subcategory uses — eval set, golden dataset, ground truth, metric, judge, baseline, regression. And the three ways to grade — deterministic metric, LLM-as-judge, human — with when each fits. Principle 3: if you can't evaluate it, you can't ship it.
- [Eval datasets and metrics: the test set is the product spec](https://www.wearecleon.com/en/docs/ai-automation/evaluation/eval-datasets-and-metrics): An eval is two halves: a dataset of cases and a way to grade the output on each one. This page builds both. The dataset mirrors the real task distribution and deliberately includes the edge cases, because the cases you leave out are the ones that break in production — and Anthropic's guidance is blunt about size: more questions with slightly lower-signal automated grading beats a handful of hand-graded ones. The grading half is a method per case — exact match, code-graded, multiple-choice, similarity, or LLM-graded — each with what it's good for and where it bites. Ground truth is where the right answer comes from and what it costs; versioning the set is what keeps two runs comparable. The same set then feeds the Console Evaluation tool, a LangSmith dataset, and the regression net for everything already shipped.
- [LLM-as-judge: grading output that has no single right answer](https://www.wearecleon.com/en/docs/ai-automation/evaluation/llm-as-judge): Exact match grades a sentiment label in one line. It cannot grade a support reply, a summary, or a conversational answer — open-ended output where two different wordings are both correct and there is no golden string to compare against. LLM-as-judge is the move there: a second model reads the output against a rubric and returns a score. The mechanic — the rubric is the scoring criteria, you pass it input plus output plus an optional reference, and you ask the judge to reason before it scores (Anthropic — improves judging on complex tasks). The feedback shapes: Boolean, Categorical, Continuous. The biases that make a naive judge lie — position, verbosity, self-preference — and the mitigations, ending on the one that matters most: calibrate the judge against human labels before you trust it. And it runs both ways — offline over an eval set, or online over live production traces.
- [Agentforce testing and observability: evaluating the agent where it lives](https://www.wearecleon.com/en/docs/ai-automation/evaluation/agentforce-testing-and-observability): The platform-native half of the eval spine: how you test and observe an agent that runs on Agentforce inside the Salesforce security model. Before deploy — Testing Center, the low-code UI for running cases against the agent; the pro-code Agentforce DX path that generates a YAML test spec via the `agent generate test-spec` CLI; and the Testing API for programmatic batch runs. The three things a test case checks — the expected topic, the expected actions, and the expected outcome as a natural-language match. After deploy — Agentforce Observability: session traces exported in OpenTelemetry (OTLP) format, stored in Data 360, with quality scores and flags for low-performing topics. The in-platform instrument; the model layer and LangSmith are the off-platform half (principle 7).
- [Tracing and monitoring: catching the degrade an eval set can't see](https://www.wearecleon.com/en/docs/ai-automation/evaluation/tracing-and-monitoring): An offline eval is frozen by definition — it grades the cases you thought of, before you ship. Production sends traffic no eval set anticipated, and that is where systems quietly rot: a model upgrade, a distribution shift, an upstream change moves the output and every offline test still passes. This page is the production half. Tracing: a trace and spans per request, logging inputs, outputs, latency, cost and tokens, tool calls, retrieved context, the metric score, and user feedback — each shown as a real table with why it matters. Online evaluation: run a judge or metric over live traces for real-time feedback, filter which runs to score, set a sampling rate so you're not grading every call. Catching the silent degrade: alert on a metric drop, not on a crash. Composed across two surfaces by where the system runs — LangSmith online evaluators off-platform, Agentforce session tracing exported in OpenTelemetry into Data 360 in-platform.
- [Debugging evals: when the number lies, and how to confirm it](https://www.wearecleon.com/en/docs/ai-automation/evaluation/debugging-evals): The eval said green and production is worse. Or the judge scores high and your reviewers disagree. Or a model upgrade you couldn't see tanked quality. A misleading eval is worse than no eval — it's a green check you trusted. The symptom-driven playbook for three ways an eval lies: offline passes but production is worse (distribution shift, a stale set, leakage flattering the score), the LLM-judge disagrees with humans (a vague rubric, an un-calibrated judge, a position/verbosity/self-preference bias), and a model-or-prompt upgrade silently regressed quality with no gate to catch it. Each with the symptom, what's actually wrong, how to confirm it, and the fix. The throughline: every one of these is cheaper to debug when you already had the eval set and the traces — debugging an eval is mostly 'did you have the measurement before you needed it.'
- [Evaluation Style Guide: the bar a change clears before it ships](https://www.wearecleon.com/en/docs/ai-automation/evaluation/style-guide): The opinionated rules Cleon applies to every evaluation — the first decision (what to measure and where), offline versus online, how to grade (deterministic, LLM-as-judge, or human), and the 'eval every change' gate every other Style Guide in this catalog invokes. The discipline document that turns the evaluation gotchas into a checklist and principle 3 into practice: if you can't evaluate it, you can't ship it — and a measurement you can't defend is worse than none, because you act on it. The page that gives 'eval every change' its home, and composes Agentforce Testing Center, Anthropic eval tooling, and LangSmith by where the system runs rather than picks a camp.

### Production & Governance
Shipping and operating AI: cost, latency, guardrails, PII and safety, human-in-the-loop, accountability, and deployment. The gap between a demo and an AI that runs on Monday morning.

- [Production gotchas: what the demo never showed you](https://www.wearecleon.com/en/docs/ai-automation/production/production-gotchas): A demo proves an AI system can work once. Production proves it works on Monday morning, under load, on the inputs nobody scripted, when the token bill is real and the agent can delete things. The gap between the two is where AI systems break — not on capability, but on the cost ceiling nobody set, the latency nobody budgeted, the prompt injection nobody screened, the PII that walked to a third party, the irreversible action with no approval step, and the kill switch that didn't exist when it mattered. Ten gotchas that separate a demo from a system you can run, each with the trap, the fix, and the question to answer before you ship.
- [What is production readiness? The gap between a demo that works and an AI that runs on Monday](https://www.wearecleon.com/en/docs/ai-automation/production/what-is-production-readiness): Production readiness is the discipline of closing the gap between a demo that worked in the room and an AI that runs unattended on real traffic. Principle 1: a demo is not a product — the demo never sees the long tail, the adversarial input, the cost at a million calls, or the irreversible action. The six dimensions production demands, each as a what-it-means and a what-fails-if-you-skip-it: cost, latency, safety and guardrails, governance, reliability, accountability. The spine the rest of this subcategory composes by where the system runs — Agentforce plus the Einstein Trust Layer, where governance is built in, and the off-platform stack, where you build each dimension yourself — with the evaluation discipline as the deployment gate. This page is the map; each dimension gets its own page.
- [Cost and latency: the levers, in order of force](https://www.wearecleon.com/en/docs/ai-automation/production/cost-and-latency): A demo runs once and the bill is rounding error; the same system at production volume turns cost and latency into line items someone has to answer for. This page is the lever board, ordered by force. Model selection is the biggest single lever on both — Haiku, Sonnet, or Opus is the first decision, and a real table lays out what each fits. Then prompt caching (up to 90 percent off a reused prefix, up to 80 percent faster), batch processing (about 50 percent off, asynchronous, most batches under an hour), max_tokens as a hard output cap and runaway guard, and streaming — which doesn't lower cost but cuts perceived latency. Underneath it all: a token budget and the Usage and Cost API, because you can't hold a ceiling you don't measure. These are the off-platform Claude API levers; Agentforce abstracts some, but the discipline is identical.
- [Input and output guardrails: the safety layer around a shipped agent](https://www.wearecleon.com/en/docs/ai-automation/production/guardrails-and-safety): A model that can act is a model that can be attacked, and a model that answers freely is a model that can be wrong out loud. Guardrails are the two-sided safety layer you wrap around it: input guardrails screen what reaches the model, output guardrails screen what leaves it. The four threats and their mitigations as a matrix — direct jailbreak / prompt injection (the user is the adversary), indirect prompt injection (the adversary hides inside retrieved content), hallucination, and toxic output — each mapped to Anthropic's named defense. Claude is inherently resilient but you strengthen guardrails for Terms-of-Service compliance; the Haiku harmlessness pre-screen; treating retrieved content as data, not instructions; the I-don't-know permission and quote-first grounding for hallucination; output screening for toxicity. And the Einstein Trust Layer as the same job done by construction when the agent lives in Agentforce — toxicity detection and scoring on every response — with the off-platform equivalent you build yourself.
- [PII and data governance: masking, retention, and the audit trail](https://www.wearecleon.com/en/docs/ai-automation/production/pii-and-governance): The moment an AI system reaches a model, customer data leaves your boundary and lands inside a third-party provider. Governance is the discipline that bounds what that exposure costs you: data masking so the PII never reaches the provider in the clear, a zero-retention guarantee so what does reach it isn't kept, and an audit trail so you can prove after the fact what happened. The Einstein Trust Layer gives you all three by construction for an agent in Agentforce — named-entity masking, zero-retention agreements with the LLM providers, toxicity scoring, and a timestamped audit record of the original prompt, the safety scores, and the original response. Off-platform you assemble the same three controls yourself: mask before the call, sign a zero-retention provider agreement, write your own audit log. No 'vs' — the same governance job, by construction in Agentforce or assembled by hand off-platform. And a real per-feature nuance: not every API feature is zero-retention-eligible (Anthropic's Message Batches API is not), so the guarantee is checked per feature, not assumed for the provider. The audit trail is what an auditor reads, and it's the same runtime record observability captures.
- [Human-in-the-loop and accountability: who is on the hook when the agent acts](https://www.wearecleon.com/en/docs/ai-automation/production/human-in-the-loop-and-accountability): An autonomous agent will eventually take an action it shouldn't — the question production answers is whether a human was in the loop before it did, and who owns the outcome after. The rule that sizes the gate: the cost of a wrong autonomous action sets the bar for requiring approval. The five situations that demand a human in the loop as a real decision table — irreversible action, low model confidence, high blast radius, sensitive or compliance-bound decision, an action outside the verified scope — each mapped to why and to the gate it requires. Escalation: the agent hands the human the full conversation context and the human's decision is logged. Verification before sensitive actions: a verification step gates the act — verify the customer before the refund — tied to the tool discipline. And accountability as the through-line: a person owns the outcome, not the model; the trace is the record that proves what happened. Composed by where the system runs — Agentforce builds escalation and verification into the platform and logs the interaction; off-platform you build the approval step and the log yourself. Same discipline, decided by where the system lives.
- [Deploying to production: the safe path from a passing eval to live traffic](https://www.wearecleon.com/en/docs/ai-automation/production/deploying-to-production): The eval is green — now how do you actually ship it without learning the hard way that green offline is not green in production? Six steps that take a prompt, model, or agent change from a passing test to live traffic with a way back: build and test in an isolated environment (Agentforce DX moves agent metadata between scratch orgs, sandboxes, and prod; off-platform, a staging environment), pass the eval gate before merge, version the change so you know exactly what shipped, roll out gradually behind a canary instead of flipping 100 percent at once, keep a one-step rollback ready, and monitor on live traffic after — because the silent degrade a frozen set can't see is caught by online eval and tracing. The throughline: deployment is not the finish line. It's where evaluation and observability start doing their real work.
- [Production Style Guide: the gate an AI clears before it runs unattended](https://www.wearecleon.com/en/docs/ai-automation/production/style-guide): The opinionated rules Cleon applies before an AI system runs on real traffic — the pre-ship gate as a binary checklist (cost ceiling, latency fallback, input guardrail, PII masked, a human on irreversible actions, the audit trail, a rollback ready, the eval gate passed), and the in-platform-versus-build-it matrix that says what Agentforce and the Einstein Trust Layer give you by construction versus what you assemble off-platform, dimension by dimension. The discipline document that turns the production gotchas into rules and the production-readiness principles into a checklist: an unmet row blocks the ship. And because this is the last page of the AI Engineering catalog, it ties the five subcategories together — agents, grounding, prompting, evaluation, production — into the single arc the whole discipline traces.

## Company
- [Cleon — home](https://www.wearecleon.com/en): What Cleon does and who we help.
- [Agentforce](https://www.wearecleon.com/en/agentforce): Agentforce implementation and agent orchestration, grounded in Data 360 and governed before launch.
- [Marketing Cloud](https://www.wearecleon.com/en/marketing-cloud): Salesforce Marketing Cloud implementation, architecture, and rescue work.
- [Data 360](https://www.wearecleon.com/en/data-360): Customer Data Platform strategy, implementation, and activation on Salesforce Data 360 — a single source of customer truth, built to be used, not stored.
- [Salesforce CRM](https://www.wearecleon.com/en/salesforce-crm): Sales, Service, and Loyalty as one connected lifecycle, integrated with Agentforce and Data 360 instead of run as three separate products.
- [Company](https://www.wearecleon.com/en/company): Who Cleon is, how the team works — research first, measured action, agents in our own operation — and its Salesforce credentials.
- [Cleon — work](https://www.wearecleon.com/en/work): Case studies and the engineering notes behind them.
- [Case study: UTN Buenos Aires](https://www.wearecleon.com/en/work/utn-ba-marketing-cloud-ai): Marketing Cloud + AI work with Universidad Tecnologica Nacional, Buenos Aires.
- [Contact](https://www.wearecleon.com/en/contact): Get in touch with Cleon.

## Optional
- [Privacy](https://www.wearecleon.com/en/privacy): Privacy policy.