Context Engineering Series · Part 2
I asked two instances of the same AI model the same question about a Salesforce technology. One came back confident and completely wrong. The other had a full development knowledge base to draw on.
Both ran the same model, and the second one had been set up with context engineering.
THE QUESTION
"Does Claude fully know Salesforce AgentScript?"
Asked to Claude Opus 4.6, April 2026
Both were running Claude Opus 4.6 and got the exact same question, and the two answers could not have landed further apart.
"AgentScript is a guided scripting tool in Salesforce Service Cloud that walks contact center agents through structured conversation flows."
"Basic setup and configuration in the Salesforce console"
"Scripts built with questions, branching logic, and responses"
"Integration with CTI, OmniChannel, Service Cloud Voice"
Wrong Technology
This is Service Cloud Agent Scripts, a legacy contact center scripting feature, and it's a completely different thing from Agent Script, the programming language for Agentforce agents that Salesforce announced at TDX 2026. The names are close enough that the model mixed them up, and the answer it gave was confident, well-structured, and about the wrong product.
"Agent Script is a programming language purpose-built for AI agents. .agent files live in your repo... you version, diff, review, and deploy them like code."
Two instruction types: -> deterministic + | AI reasoning
11 official patterns, 3 variable types, 4 action targets
Full CLI: generate → validate → preview → publish → activate
FSM architecture, instruction resolution, production gotchas
14-point activation checklist, 100-point scoring rubric
Correct Technology + Development-Ready
It correctly identifies Agent Script as the Agentforce DSL, and it knows the syntax, patterns, CLI workflow, and gotchas well enough to author production .agent files. That's the level I actually need, because I'm the one who has to go build the agent afterward.
Agent Script was announced at TDX in April 2026, which is after Opus 4.6, the model I tested, had its training data frozen. So when someone asks about "AgentScript," the model reaches for the closest thing it already knows, the legacy Service Cloud Agent Scripts feature, a different technology that happens to wear a similar name.
The wrong answer was well-structured and detailed, delivered with real authority. It cited specific integration points like CTI and OmniChannel, along with setup steps and practical advice, all of it for the wrong technology. That's the failure mode that scares me most in an enterprise setting, where the AI sounds sure of itself and nothing in the tone tips you off that it's wrong.
Even with retrieval-augmented generation, a vector database of Salesforce docs would still need the right docs in it, chunked properly, with enough surrounding context to tell two similarly-named features apart. Context engineering goes further and hands the model a structured knowledge base with syntax references, patterns, validation rules, and production gotchas, so the answers come back sounding like they're from someone who has actually shipped with the language.
Here's the AgentScript knowledge base as it stood when I ran this in April 2026, three layers each doing a different job. Together they take the model past recognizing what Agent Script is and into building with it.
sf-ai-agentscript v2.9.0
A complete development skill built from 96 workshop screenshots, the official documentation, and community contributions, covering syntax, architecture, validation, debugging, deployment, and testing.
wiki/concepts/agent-script-language.md
A 239-line language reference that covers the full DSL, from instruction types and the variable system through action targets, control flow patterns, the symbol reference, block structure, CLI commands, and the official recipes.
memory/ + wiki/concepts/
Persistent memory that ties Agent Script to your actual Salesforce projects... the migration plans, architectural decisions, and strategic context that connect the reference knowledge to the work you're actually doing.
Ask the context-engineered Claude for an agent and it writes Agent Script, like the file below.
config:
developer_name: Verification_Gate
agent_type: AgentforceServiceAgent
variables:
verified: mutable boolean = False
customer_email: mutable string = ... # slot-fill: LLM extracts from conversation
start_agent:
instructions: -> # deterministic: runs before LLM
if @variables.verified == False:
transition to @subagent.Identity_Check
| Welcome back! How can I help today? # prompt: sent to LLM
topic Identity_Check:
instructions: ->
run @actions.verify_identity
with email=@variables.customer_email
set @variables.verified=@outputs.verified
actions:
verify_identity:
target: flow://Verify_Customer_Identity->
Deterministic
runs before LLM
|
Prompt
sent to LLM
...
Slot Fill
LLM extracts value
flow://
Action Target
runs Flow/Apex/API
0
Reference Documents
0
Working Pattern Files
0
Source Screenshots
0
Point Scoring Rubric
| Capability | Out of the Box | Context Engineered |
|---|---|---|
| Identifies correct technology | × | ✓ |
Knows -> vs | syntax |
× | ✓ |
Can author .agent files |
× | ✓ |
| CLI workflow knowledge | × | ✓ |
| Production failure patterns | × | ✓ |
| Syntax validation | × | ✓ |
| Knows your project context | × | ✓ |
The vanilla response didn't say "I'm not sure" or "this might be outdated." It presented the wrong technology with the same confidence it would present the right one. For an SE prepping for a customer conversation, this failure mode is worse than no answer at all, because it sends you into a meeting armed with wrong information you fully believe is right.
The context-engineered Claude runs the very same model, Opus 4.6, as the vanilla one, and nobody bought a special tool for it either. What it has around it is a growing set of wiki pages, memory files, skills, and validation hooks, built up over time while I used it for real work, and it keeps getting sharper because every correction it absorbs carries into the next session.
The AgentScript knowledge base took a while to build. It started as a single wiki page, then a skill got added, then memory files that captured corrections and decisions, and the whole thing grew alongside real work. You really don't have to build the entire architecture before it starts paying off... a single CLAUDE.md file carrying your org's patterns already beats the default by a wide margin.
You don't need a five-tier architecture on day one. Start with a CLAUDE.md that tells the model who you are, what you're working on, and which words to avoid, then build out from there as the work demands it.
Your identity, role, projects, and routing table
Deep reference for your domain, loaded on demand
Corrections and decisions that persist across sessions
Specialized capabilities for specific technologies
Everything so far lived inside Claude’s own context, its instructions, its memory, its skills. Part 3 is where it reaches out, and connects to the systems your work actually lives in.
Part 3: MCP Servers →