Overview
Deploying puts curated context in front of agents. Every surface calls the same invocable actions, so the same entities serve all of them at once.
The Deploy tab opens on the Deployment Overview — where ContextWorks is already deployed, read live from the org and verified by traffic. The pages after it set up each surface.
The actions
| Action | Purpose |
|---|---|
| Get Catalog | Discovery — what context exists, and per entity the full contract: fields, valid values, filterable and writable fields |
| Find Records | A filtered set with curated columns and totals |
| Get Records | One or more records in depth |
| Update Records | Change declared-writable fields on one or more records, with a user-confirmed diff — optional, and off at the org level until an admin enables write access |
Agents should call Get Catalog first — it stops them guessing object and field names. Register Update Records only where writes belong: a surface without the tool cannot write at all. Full inputs are in the invocable actions reference.
Choose a surface
| Surface | Use when |
|---|---|
| Agentforce | You’re building in Salesforce’s agent platform |
| MCP | Claude or another MCP client should reach your org |
| Prompt Builder | A prompt template should be grounded in curated context |
| Custom tools | You want purpose-named tools scoped to a domain |
| Apex API | Flow, scheduled jobs, your own code |
Surfaces aren’t exclusive. Adding a second one requires no configuration changes.
Generic actions or scoped tools?
Start with the generic actions. They cover every configured object, and the Deploy pages generate the registrations for you. Add scoped tools when a planner should route by intent, or when a tool should answer over one domain only. Both can coexist — a scoped tool is a thin class over the same API.
The Agentforce extension package
The core package ships the invocable actions; putting them in front of an agent is a per-org step. MCP and custom tools you register by hand, once. For Agentforce, a second package does it for you.
The extension package holds the Agentforce metadata the core package leaves out: the agent actions (including Update Records, marked confirmation-required) and a ready-made ContextWorks topic whose instructions tell an agent to discover first, then find, then get. Click Install Extension Package on Deploy → Agentforce and the actions exist, named exactly as the generated AgentScript expects.
It ships separately because that metadata requires Einstein generative AI — orgs without Agentforce install the core package clean. Registering by hand still works; the same page lists every class and the name to give it.
WARNING
Name each registered action or tool exactly as the Deploy page shows. Generated AgentScript references actions by name, and a mismatch fails at runtime — not at save.