Dreamforce '26 · San Francisco, USA · September 2026

An Architect's Guide to Prompt Engineering

Most teams think prompting is about wording. It isn’t. It’s about the controls.

Build a promptCopy the protocol

The symptom

When AI disappoints, we blame the tool

The quality of AI-generated output is determined less by the wording of a prompt and more by the control mechanisms around it.

  • “The model hallucinated”
  • “The output was too generic”
  • “The agent ignored my instructions”
  • “The responses are inconsistent”

Architects ask a different question

  • What did we actually give the model to work with?
  • Was the necessary context provided?
  • Were the constraints explicitly stated?
  • Did it have access to the right tools for verification?
  • Did we define what a successful output looks like?

The pattern

Every prompt needs four control moves

Swapping vague for specific: in what the model knows, what it can’t do, what it can call, and what it must return. Together they turn a single prompt into a system - that is what “prompting as system design” means.

01

Context

What the model needs to know about the org, the org's metadata and the task.

02

Constraints

What the model must not do - and what to do instead, so guardrails redirect rather than just block.

03

Tools

What the model can call - describe calls, search, code execution, connected systems.

04

Output + Evaluation

The exact shape of the response, plus the self-check it must pass before it ships.

The take-home artifact

One protocol for every prompt

Package all four control moves into one prompt with this skeleton. Copy it, then replace each line with the specifics of your org - the builder below does exactly that, with the three worked examples as presets.

prompt-protocol.txt
CONTEXT:
Here is the org-specific evidence - metadata, code, business rules, prior decisions - attached or pasted, not assumed.

CONSTRAINTS:
Only use what is provided; flag anything inferred. Pair every guardrail with the fallback action, not just the prohibition.

TOOLS:
Name exactly what the model may call to verify itself - describe calls, code search, sandbox execution - before it answers.

OUTPUT + VALIDATION:
Define the exact artifact shape and the self-check it must pass first - table, diagram, schema - designed so it can be validated, diffed and reused.

Interactive

Build your own prompt

Fill the four control moves and the prompt assembles itself on the right. The readiness check applies the six rules of the field guide to what you wrote - it is the same self-check you would ask a model to run. Your draft stays in this browser.

Name the objects, classes and org - not the category.

Pair every prohibition with the fallback action.

Name the exact API or search the model may call to verify itself.

Define the artifact shape and the self-check it must pass.

your-prompt.txt
Readiness check
0 / 6
    Worked examples
    The same question, twice
    Three real architecture tasks, each asked the way most teams would ask it - and then packaged with the four control moves. The right-hand column is what produced the artifact underneath it.
    Assessing an org merger
    Org 1 (acquirer, ~12 years old) → Org 2 (acquired), ahead of the Q3 code freeze.
    Rule 1Rule 2
    Unstructured prompt
    I pulled the metadata export for Org 1 - objects are Store_Location__c, Product_Bundle__c, and a legacy Order__c that doesn't match our Retail_Order__c.

Can you look through this and tell me what's going on before we merge it into Org 2 ahead of the Q3 code freeze?

Flag anything risky.
    Structured protocol
    CONTEXT:
Object/field metadata for Store_Location__c, Product_Bundle__c and Order__c (Org 1) and Retail_Order__c, Warehouse_Transfer__c (Org 2), plus both orgs' automations.

CONSTRAINTS:
Flag objects where 2+ automation types share an event context or write the same field. Flag triggers with UsageIsBulk = false or DML in loops. Exclude managed-package components from remediation, but keep them in the totals.

TOOLS:
Tooling API for active automation (Flows, triggers, Process Builder, ValidationRule) + MetadataComponentDependency (Beta, 2,000-row cap) + schema diff on Order__c vs Retail_Order__c.

OUTPUT:
merge-readiness-scorecard.md - ERD + risk-scored table (Object, Risk Type, Severity, Merge Blocker, Remediation). Self-check: every Blocker = Yes row must cite the field or class it flags.
    merge-readiness-scorecard.mdWhat the structured prompt returns
    ObjectRisk TypeSeverityBlockerRemediation
    Order__c → Retail_Order__cField incompatibilityHighYesRemap Order__c.Status__c (5 values) to Retail_Order__c.Status__c (3 values) before merge
    Store_Location__cAutomation conflictMediumNo2 Flows + StoreLocationTrigger.cls both update Inventory_Count__c - consolidate before go-live
    Product_Bundle__cNon-bulkified DMLHighYesProductBundleHandler.cls performs DML inside a for-loop - refactor before merge
    This is the whole artifact - not a narrative summary. It drops straight into the merge steering-committee deck, and the same table format works for the next acquisition’s metadata too.
    The field guide
    Six rules, straight from the examples
    Each rule came out of one of the three demos above. Together they are the checklist behind the readiness check in the builder.
    1
    Name the artifact, not the category
    Vague names force a guess. Real API names don’t.
    Say “the order object” and the model has to guess which one you mean - and it will guess wrong. Actual API names leave nothing to guess.
    The prompt named the exact objects and class: Retail_Order__c, Warehouse_Transfer__c and ProductBundleHandler.cls.
    2
    Verify before assuming
    Same name, same purpose - not always the same structure.
    Two orgs can carry the same object name for two different designs. Verify current metadata and dependencies in each org before you map or merge.
    Before planning the merge it compared Order__c with Retail_Order__c, and checked each org’s automation instead of assuming they behaved alike.
    3
    Point at a verifiable tool
    Named APIs give the model an explicit path to verification.
    Ask the model to use “your Salesforce knowledge” and it answers from memory, not from your org. Naming the exact API or search forces it to go look.
    The prompt named the checks to run: search both Apex classes and inspect the org’s dependency data.
    4
    Make findings actionable
    Add an owner and a sequence. Turn every finding into a task.
    A paragraph explaining a risk is something someone has to re-read and translate into work. A sequence number and an owner is already the task.
    Each finding became a cutover step with a clear order and risk - not a paragraph describing the problem.
    5
    Forbid the model’s default shortcut
    Block the wrong path - not just state the right outcome.
    A model defaults to the most common pattern in its training data. Describing the right answer isn’t enough; you must rule out the tempting wrong one.
    The prompt blocked the shortcut: do not add a custom field to the managed Financial Account object - propose a custom object with a lookup instead.
    6
    Make the model show its discovery
    Require a discovery summary. If it isn’t shown, it wasn’t verified.
    If the output format has no slot for “what I found already exists”, you have no way to tell whether the model actually checked or simply guessed.
    Before proposing a design the model had to list what it discovered in the org - which surfaced existing Action Plan Templates the design had to account for.
    In the AI era, everyone will have access to the same models.
    The differentiator is no longer the model.
    It’s the architecture around it.